FpML Issues Tracker
Could you please clarify the following questions about tag <rateCutOffDaysOffset> from fpml-ird-5-12 schema:
- 1. Is the tag <rateCutOffDaysOffset> used for OIS as equivalent of the tag <lockout>, when exists section <resetDates>, instead of section <calculationParameters>?
- Can the tag <rateCutOffDaysOffset> be applied for floating indexes for Cross Currency fixed/float and for IRS Fixed/Float instruments?
- How the floating indexes should be calculated in case the tag <rateCutOffDaysOffset> can be applied for floating indexes?
Thank you in advance.
With best regards
08/31/23 10:53 am
rateCutOffDaysOffset is a legacy ISDA term.
- Not intended to be used to represent lockout, which are as part of ISDA’s new definitions.
Lockout replaces the practice of rate lockout, for days rate is not observed at end of calculation period.
The language is part of new modular compounding averaging. New FpML structure created to faithfully represent it.
It’s still used on fed fund trades, which don’t use new conventions.
If using 2021 definitions don’t use rateCutOffDaysOffset.
2. Concept only applicable to floating rate, can be used in any context, in a fed fund rate wherever.
It’s not instrument level, but leg level concept. Market convention, applicable for certain rate indices.
3. Use it in the way it’s legally defined in the ISDA definitions.
It’s not the lock out, in the ISDA defs it’s the rate cut off dates. When we parameterise, we turn them into an offset, X number of days prior to period end date.
09/05/23 5:47 am
RE: [FpML-XAPWG] FpML Cross Asset Class Product WG Meeting 2023-08-31 Minutes – FpML Cross posted here with permission from Duncan Livingstone.
The following is my understanding of ‘Rate Cut-Off Days’:
A rate cut-off is similar to lockout, but applicable only to transaction events, and scheduled coupons are unaffected (because when referencing a self-compounding FRO, there is usually a payment delay at the end of a regular calculation period end date).
Whereas a lockout is applied to every calc period end date where there is no payment delay, whether a scheduled coupon, or early termination event.
A rate cut-off is necessary where the following are true:
- Accrued interest needs to be calculated and realised as a cashflow amount, agreed in a transaction event on trade date.
- The overnight rate is observed on spot (i.e., on the self-compounding FRO, or where there is zero lookback or shift days).
- The effective date offset is >1 business day.
E.g., an unwind (or offset) transaction on [USD-SOFR-OIS Compound] will agree the accrued interest element of the fee on trade date, but interest accrual will be calculated until the unwind effective date. This market has a T+2 offset, so the final 2 rate observations will be unknown on trade date, and SOFR is only available the day following the actual observation date. The rate cut-off is measured from the calculation period end date, so in this instance the final rate observation will need to be 3 business days preceding the unwind effective date, and will be weighted accordingly for compounding. A rate cut-off of 3 business days will ensure that both parties to the transaction can calculate the precise calc period rate with the rate observations that are available to them on trade date.
The default rate cut-off for daily rate observation is 1 business day, due to the ‘from inclusive, to exclusive principle’, so a 2 day effective date offset will require an additional 2 business days rate cut-off.
This is the default method already used by Bloomberg for calculating transaction fees, so parties will be employing a rate cut-off, even if they are unaware they are doing so. Including the rate cut-off days in FpML will likely only formalise what is already being done, but its inclusion will allow parties to bilaterally agree a discretionary number of days, and BBG do allow users to input their own cut-off days and override their default. I know from experience that buyside firms can experience timing issues with the internal availability of rate values obtained from the data feed from their redistribution agents, and while materially insignificant, it can still upset STP with minor breaks.
Leave an update
You must be logged in to post an update.