Source: http://forums.opengamma.com/t/zc-trade-calculated-differently/617
Timestamp: 2017-12-13 05:26:52
Document Index: 186477387

Matched Legal Cases: ['arty1', 'arty2', 'arty2', 'arty1', 'arty2', 'arty2', 'arty1']

ZC trade calculated differently - Strata - OpenGamma Forums
ZC trade calculated differently
karin 2016-10-20 03:35:49 UTC #1
We have a ZC trade and got different results then expected.
This is what we got using the fpml parser : PV01CalibratedSum :-101759.454362
And this is what expected (using bloomberg terminal) : 192308.86
blob.jpg1143x549 261 KB
FPML:
<executionNotification xmlns="http://www.fpml.org/FpML-5/confirmation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.fpml.org/FpML-5/confirmation d:\_TRAIANA\_PM\FpML\5.8\confirmation\fpml-main-5-8.xsd" fpmlVersion="5-8">
<messageId messageIdScheme="http://www.traiana.com/fpml">20000010000107-03_706</messageId>
<sentBy>Ilan_ECN1</sentBy>
<sendTo>Traiana</sendTo>
<creationTimestamp>2017-07-08T08:57:00Z</creationTimestamp>
<isCorrection>false</isCorrection>
<partyReference href="ExecutionFacility"/>
<tradeId tradeIdScheme="http://www.traiana.com/fpml">SEF_TRADE-20000010000107-03_706</tradeId>
<originatingTradeId>
<tradeId tradeIdScheme="http://www.traiana.com/party/orderId">alloc-20000010000107-01_706</tradeId>
</originatingTradeId>
<partyReference href="party1"/>
<tradeId tradeIdScheme="http://www.traiana.com/fpml">CLIENT1_TRADE-20000010000107-03_706</tradeId>
<!-- Optional  - trade Id at party2 -->
<partyReference href="party2"/>
<tradeId tradeIdScheme="http://www.traiana.com/fpml">EB_TRADE_ID-20000010000107-03_706</tradeId>
<!-- Optional element -->
<partyTradeInformation>
<executionType>Electronic</executionType>
</partyTradeInformation>
<tradeDate>2014-01-02</tradeDate>
<productId productIdScheme="http://www.bloomberg.com/bbml/coding-scheme/productIdScheme">SL1T3QI1</productId>
<swapStream id="floatingLeg">
<payerPartyReference href="party1"/>
<receiverPartyReference href="party2"/>
<calculationPeriodDates id="payCalcDates">
<unadjustedDate>2016-10-19</unadjustedDate>
<unadjustedDate>2046-10-19</unadjustedDate>
<businessCenter businessCenterScheme="http://www.fpml.org/coding-scheme/business-center">NYFD</businessCenter>
<businessCenter businessCenterScheme="http://www.fpml.org/coding-scheme/business-center">GBLO</businessCenter>
<periodMultiplier>3</periodMultiplier>
<rollConvention>19</rollConvention>
<calculationPeriodDatesReference href="payCalcDates"/>
<period>T</period>
<resetDates id="payResetDates">
<dateRelativeTo href="payResetDates"/>
<notionalSchedule id="payNotionalSchedule">
<initialValue>47456760.2599999979</initialValue>
<currency currencyScheme="http://www.fpml.org/coding-scheme/external/iso4217-2001-08-15">USD</currency>
<floatingRateIndex floatingRateIndexScheme="http://www.fpml.org/coding-scheme/floating-rate-index">USD-LIBOR-BBA</floatingRateIndex>
<dayCountFraction dayCountFractionScheme="http://www.fpml.org/coding-scheme/day-count-fraction">ACT/360</dayCountFraction>
<swapStream id="fixedLeg">
<payerPartyReference href="party2"/>
<receiverPartyReference href="party1"/>
<calculationPeriodDates id="recCalcDates">
<calculationPeriodDatesReference href="recCalcDates"/>
<notionalSchedule id="receiveNotionalSchedule">
<initialValue>0.025</initialValue>
<dayCountFraction dayCountFractionScheme="http://www.fpml.org/coding-scheme/day-count-fraction">30/360</dayCountFraction>
<partyId>Ilan_Client1</partyId>
<partyId>Anonymous</partyId>
<party id="clearingBroker1">
<partyId>Ilan_CM1</partyId>
<party id="DCO">
<partyId>Ilan_CCP1</partyId>
<party id="LimitsHub">
<partyId>Traiana</partyId>
<party id="ExecutionFacility">
<partyId>Ilan_ECN1</partyId>
</executionNotification>
tom 2016-10-20 03:55:34 UTC #2
Can you please tell me if your leg level NPVs are also far off from Bloomberg?
Especially on the fixed leg, it maybe helpful to see how well that lines up, in order to get an idea if the discrepancies are coming from mismatched trade params or mismatching generated cashflows.
Assuming the problem is not there, then specifics of curve construction and the market data used in the curve would be worth investigating.
karin 2016-10-20 04:57:50 UTC #3
PresentValue : 4692940.481426675
Fixed leg : USD 8.836089202175215E7
yanivh 2016-10-21 11:27:27 UTC #4
Under the assumption that the MD is equal or negligible difference.
can you tell us what exactly the ZR coupon calculation does ? we find big difference agints BBG terminal , we don't see this difference in other IRD product types (FRA, fixed-fload, OIS..etc)
do you need more details from us ?
stephen 2016-10-21 15:16:58 UTC #5
As per our community support policy, we can't really get into the details of trying to match our numbers to an external system. The code is open source, so if you feel there is a problem, you are able to debug through to identify where the numbers diverge.
erezc 2016-10-31 11:49:03 UTC #6
We totally understand you can't try to match numbers with any external system.
As we understand, ZC swaps may contain either notional and interest rate or a know amount (Future Value Notional).
When processing the trades in OpenGamma we are getting a high variance between resulting DV01 figures although the financial are the same.
Could you identify the reason for the variance?
stephen 2016-10-31 20:04:44 UTC #7
I've had a brief look at the FpML and Bloomberg capture above. The two seem to match, although I can't confirm if Bloomberg day count 30I/360 is the same as 30/360 ISDA. Perhaps this is something to check.
We are aware that our PV01 measure may not exactly match how Bloomberg defines DV01. But we would expect the two to be reasonably close. To determine an exact difference requires checking that the curves match in each system, and that the trades match at each payment date. With ZC trades that is of course trickier as there are no intermediate payments.
Internally, we have no special logic for zero coupon trades - the discounting swap payment pricer calculates the payment period in the same way however long it is.
Are you sure that the trade has no intermediate payments on both the fixed and floating leg?
erezc 2016-11-01 07:46:56 UTC #8
Both legs paymentFrequency =1T
erezc 2016-11-01 08:07:47 UTC #9
In your code there is a comment:
Does that mean you are referring to the known amount as the initial amount?
Shouldn't it refer to the future value notional?
stephen 2016-11-01 11:04:29 UTC #10
When Strata sees a knownAmountSchedule in FpML it creates a KnownAmountSwapLeg instead of a RateCalculationSwapLeg. The known amount represents the actual monetary amount to be exchanged for that leg - ie. there is no notional, day count or fixed rate. The code above is from KnownAmountSwapLeg.
For any value that can change during the life of a swap (notional, interest rate, spread, gearing, known amount), we use ValueSchedule. The "initial amount" is the amount of the value at the start of the swap, and the "steps" define how the amount changes over time.
Strata does not support the futureValueNotional field in FpML.
The FpML at the top of the page does not define futureValueNotional.
karin 2016-11-01 12:19:50 UTC #11
We have two identical trades - one with known amount, and one with initial value + rate.
The two trades should recieve the same DV01 using the parser, but the numbers are not close.
10Y 3M Libor:
with Initial value: 76324
with Known amount: 150416
IRS.dcm280164073367195840650
UBSLTD
2016-10-26T12:25:13.918
e3d9705a-e484-43a0-8cbc-7150f0f33172
0000452A
MARKITWIRE31145803
ClearingOrganization
InterestRate:IRSwap:FixedFloat
2026-10-26
MODFOLLOWING
CalculationPeriodEndDate
CalculationPeriodStartDate
81954447.03
ISDA2006
B64400
erezc 2016-11-01 20:14:12 UTC #12
Let me rephrase my question. We expect the following two trades to result we the same sensitivity. However, we are getting two different figures.
Trade 1 sensitivity with known amount: 150416
<productType productTypeScheme="http://www.fpml.org/coding-scheme/product-taxonomy">InterestRate:IRSwap:FixedFloat</productType>
<swapStream id="floatLeg">
<calculationPeriodDates id="floatingLegCalcPeriodDates_2244828">
<unadjustedDate>2016-10-26</unadjustedDate>
<unadjustedDate>2026-10-26</unadjustedDate>
<rollConvention>26</rollConvention>
<calculationPeriodDatesReference href="floatingLegCalcPeriodDates_2244828"/>
<resetDates id="floatingLegresetDates_2244828">
<dateRelativeTo href="floatingLegresetDates_2244828"/>
<initialValue>81954447.03</initialValue>
<floatingRateIndex>USD-LIBOR-BBA</floatingRateIndex>
<compoundingMethod>Straight</compoundingMethod>
<calculationPeriodDates id="fixedLegCalcPeriodDates_2244828">
<calculationPeriodDatesReference href="fixedLegCalcPeriodDates_2244828"/>
<knownAmountSchedule>
<initialValue>100000000</initialValue>
</knownAmountSchedule>
Trade 2 sensitivity with Initial value: 76324
<initialValue>0.02000000</initialValue>
<dayCountFraction>30/360</dayCountFraction>
stephen 2016-11-07 20:05:23 UTC #13
These trades differ only in the definition of the fixed leg payments. The first says:
This is a single payment of 100 million at the end. The accrual frequency is not relevant. If working correctly, I'd expect one instance of KnownAmountSwapPaymentPeriod within the ResolvedSwapLeg. This period would only be sensitive to the discount curve, not the Ibor forward curve.
This is 2% interest on 81.954447 million, which accrues every 6 months for 10 years and pays once at the end. Since the FpML trade does not specify the compoundingMethod, it is in fact an invalid FpML trade, see here and here. When not specified, Strata defaults to no compounding. Does 2% interest calculated every six months over 10 years with no compounding result in a total payment of 100M? I suspect not.
erezc 2016-11-10 13:03:12 UTC #14
When processing fixed leg having a compoundingMethod, sensitivity figures seems accurate. However, when processing the trade with the knownAmount the figures are still different.
Are you expecting interest rates for the floating leg and discount rates for the fixed leg?
stephen 2016-11-10 18:35:11 UTC #15
Not sure what you mean. A vanilla fixed-Ibor swap will typically price against two curves, one providing a discount factors (the discounting curve) and one providing a prediction of the future of the Ibor index (the forward curve). A fixed leg, by definition, has no reference to an Ibor index. As such, it is only sensitive to the discounting curve. Whereas, the floating leg will be sensitive to both the discounting and forward curve.
yanivh 2016-11-14 14:08:24 UTC #16
We use code version 1.1. While we debug your code, the swap above (fpml msg with knownAmount element) is parsed as "KnownAmountSwapLeg" , there is no clue for "ResolvedSwapLeg" you mentioned in your previous answer.
Maybe your FPML parser is out of sync with this new addition, if so, do we need to create another parser with the new leg type "ResolvedSwapLeg" within the new element "KnownAmountSwapPaymentPeriod" (v1.1) ?
If not, I probably miss something....
stephen 2016-11-14 14:51:34 UTC #17
The FpML parser creates an instanceof KnownAmountSwapLeg. However, in order to be priced, the leg has to be "resolved". This involves a call to resolve(ReferenceData). The result of that method call is an instance of ResolvedSwapLeg that holds one or more KnownAmountSwapPaymentPeriod instances. It is this resolved swap leg that is used in pricing.