[alexnotalex]

Thanks! I think we agree – that’s the intuitive definition and the one I’ve used before. At my current place I’m seeing it framed as the current notional (i.e. the initial value for this version of the trade), with all schedules forward-looking, so the history drops off.

Alex

[alexnotalex]

if amortization frq > payment frq then you’ll have multiple calculation periods per payment period and should be indicating the compoundingMethod. This method applies to the whole payment period. If you want periods 1 2 4 and 5 None and 3 and 6 Flat then I think we can’t describe this with the parameters. cashflowsMatchParameters = false and lay it out in each cashflow period. Yuk. Alex

[alexnotalex]

I interpret compounding and amortization as two things that can happen together or apart. As soon as you have multiple calculationPeriods contributing to one paymentPeriod you should be using compoundingMethod to explain how the numbers should be put together. All my zero coupon swaps are flat compounded implicity, with or without amortization. The FpML grammar can describe all of this, it’s down to you to tell the right story. best, Alex

[alexnotalex]

yes, that’s it, thanks for laying it out. Usually for these trades all the fxfixing takes place on the fxlinked notional leg… to indicate it’s forward starting you spec it as an fxlinked notional without an initial value because the constant notional leg is known. Here the difference is that the fxlinked leg does have an initial value and it’s the constant notional leg which is fixed. best, Alex

[alexnotalex]

Hi Roma, This is my understanding: The integer multiple bit means that if the notional changes you need a new calculation period to describe the interest calculation based on the new notional. You can’t move the notional within a calculation period, the grammar can’t express that. You need to end the first period and start another. Set up your notionalStepSchedule as usual for both legs, amortizing each year stepFrequency = 1Y The fixed leg should have paymentFrequency = 1T and calculationPeriodFrequency = 1Y. Multiple calculationPeriods will contribute to one paymentCalculationPeriod, just specify the compoundingMethod for the leg and you’re half way done. 1y/1y = 1. The floating leg can pay every 6 months and step every year. Set up a paymentFrequency = 6M and calculationPeriodFrequency = 6M. each paymentCalculationPeriod will have a single calculationPeriod. The notional will change every year i.e. every second paymentCalculationPeriod. 1Y/6M = 2. For (2) you’d need 2 paymentCalculationPeriods, each with 6 calculationPeriods to handle the monthly amortization. The interest rate will reset every 3 months, which fits perfectly inside the schedule. Specify the compoundingMethod. The parameters and cashflow grammar should also support this level of detail for stubs. I hope this helps, I’m just a practitioner and do not represent fpml.org. Best, Alex

[alexnotalex]

Hi, One solution would be to use the book code as an alternate party identifier, just use a meaningful scheme in line with your data model. 12345-EU There are other more complicated ways, but the above one is simple and will work fine internally. Best, Alex

[Author]

Posts