[h_mcallister]

Hi Gagan, I’ve asked this question in the past … I can’t think of a case – I suspect that this aspect of the model is over-engineered, and that it is unlikely that this degree of flexibility will ever be required. I’m not convinced that the reset dates business day convention actually ever means something different from that defined for the calculation periods – but I’m willing to be proved wrong, if I’ve overlooked a use case (!) Best regards, Harry McAllister Chair, IRD-WG

[h_mcallister]

Hi Ludovic, Andres, That is useful information: multiple exercise properties for Cancelable Provision, including minimum/maximum exercise amounts, do not appear to be supported by the GTR, according to the DTCC/GTR Rates Upload Spreadsheet v27.2 (“Confirmation” tab, Category = “Cancelable Provision”). This suggests that these properties do not require to be provided when reporting cancelable (callable) swaps to the GTR – although *please note* that the equivalent properties *are* supported for Confirmation reporting of Swaptions. Best regards, Harry

[h_mcallister]

Hi Andres, Thanks, now I understand … Unfortunately, this particular case is not supported. This could be implemented readily, e.g. by adding a choice of maximumFractionOfNotional (decimal value between 0 and 1) – but I appreciate that doesn’t help you right now. * What is the context in which you are producing this message (e.g. STP between internal systems)? * What version of FpML are you using (looks like 5-3, from your original post)? Best regards, Harry

[h_mcallister]

Hi Andres, In answer to your questions: Q1.1 What should be set in the minimumNotionalAmount and maximumNotionalAmount? A: The amount specified as the minimum exercise amount in the contract terms. Where multiple partial exercise is available, it is common practice to specify a minimum exercise amount – usually small in relation to the exercisable notional amount (e.g. 100K against a notional of 1M), and certainly no greater than any residual notional in the last phase of an amortising schedule. If you don’t have this information, or a minimum exercise amount is not specified in the contract terms, then I suggest you produce minimumNotionalAmount = 0. Q1.2 It looks like the FPML standard just supports minimumNotionalAmount and maximumNotionalAmount as constant values for the full contract. A: I’m not aware of any case where minimum/maximum exercise amount varies over the term of the contract. Q2: How can we represent that requirement in the FPML standard? A: As per 1.2 above, I’m not sure that the case arises. Do you have an example of a trade where the confirmation terms specify a *varying* minimum exercise amount? Harry McAllister irdchair@fpml.org

[h_mcallister]

Hi Andres, * You are correct in using the cancelableProvision component to represent the features of a callable swap * Please note that multipleExercise is optional in the schema – so you would only produce this element where the option permits partial exercise i.e. a portion of the notional may be exercised, potentially on multiple occasions (not usually the case for a callable swap). * The BermudaExercise and MultipleExercise complex types were originally designed to be used in multiple product contexts (not only Interest Rate). Note that the elements minimum- and maximum-NumberOfOptions exist in *choice* groups with minimum- and maximum-NotionalAmount respectively. Under an InterestRate product you would produce the -NotionalAmount element, so the -NumberOfOptions element becomes irrelevant.

[h_mcallister]

Hi Gagan, Yes, this is entirely possible e.g. calculation period dates based on USNY business days, with payment based on USNY + GBLO. This is why the InterestRateStream model allows (although does not require) the business centres to be specified independently in each case. Best regards, Harry

[h_mcallister]

Hi Inga, Yes: as an instance of shared type Offset, paymentDaysOffset contains dayType (strictly an element, not an attribute) at FpML 4-6. In general, the core features of the Interest Rate product models have been stable since FpML 2-0. Version-on-version changes are documented with the Specification – look in the online documentation, section 1 Introduction & Overview, sub-section 1.6(?) Changes in this version. Tracking the introduction of elements across major versions is harder, and may depend on comparing the content of schema modules (not always straightforward, as schema content may have been merged/split/re-located over time). With apologies for the delayed response. Harry McAllister Chair, IRD-WG

[h_mcallister]

Hi Andy, PartyTradeInformation/isAccountingHedge pre-dates the surveillance elements added in FpML-5-3, having been added in 5-0. There is no necessary connection between [i]isAccountingHedge[/i] and [i]endUserExceptionDeclaration[/i], and no requirement to produce [i]isAccountingHedge[/i] e.g. for the DTCC GTR (I am not aware of any public implementation of FpML using [i]isAccountingHedge[/i]). Hope that helps. Best regards, Harry

[h_mcallister]

Hi mscastro, The recommended extension method for FpML is runtime type substitution – see the FpML Architecture specification, section 6 Extending FpML (http://www.fpml.org/spec/fpml-arch-3-0-tr-1/). You mention NDF – just out of interest, are you extending the existing nonDeliverableSettlement component under FxSingleLeg? Best regards, Harry McAllister Chair, IRD-WG

[h_mcallister]

Hi Nikhil, To be clear, the type of element hourMinuteTime is HourMinuteTime, which is defined as a restriction on type xsd:time such that the “seconds” component of the time is zero (“hh:mm:00”). Can you expand on what you meant by “We have to get a value 12:00:00 for this field…”? Do you mean, you need to produce the hourMinuteTime element containing this value? “12:00:00” is perfectly valid as a value of hourMinuteTime, so I’m not sure where the problem lies. Best regards, Harry McAllister Chair, IRD-WG

[h_mcallister]

Marc’s response requires further clarification. acollist asked: “if I want the same spread to apply to the stub as to the regular periods in the leg, do I need to explicitly specify a spreadSchedule in the stubCalculationPeriod’s floatingRateCalculation”. The answer to this is “yes, the applicable [i]spreadSchedule[/i] must be explicitly specified within [i]stubCalculationPeriodAmount[/i], where it exists”. First, note that [i]stubCalculationPeriodAmount[/i] is required only where an initial- or final- stub period exists, and even then only where the applicable rate calculation differs from the rate calculation specified for the regular periods(*). Where the stub rate calculation is the same for the regular periods, then there is no need to produce [i]stubCalculationPeriodAmount[/i] (or, to put it another way, in the absence of [i]stubCalculationPeriodAmount[/i], any stub rate is calculated in the same way as for the regular periods). Once [i]stubCalculationPeriodAmount[/i] is present, the rate calculation must be specified in its entirety within [[i]initial[/i]|[i]final[/i]][i]Stub[/i], including the [i]spreadSchedule[/i] where applicable. This has to be the case: otherwise, it would not be possible to distinguish between (1) a stub where no spread applies and (2) a stub where the spread is not specified, but is inherited from the rate calculation for the regular periods. I hope that makes sense – please let me know if you have further queries. Harry McAllister irdchair@fpml.org (*) Please note that some implementations (e.g. MarkitWire) always produce [i]stubCalculationPeriodAmount[/i] where a stub exists, irrespective of whether the rate calculation differs from the regular periods.

[h_mcallister]

Hi edchase1, First, apologies that you didn’t get a response in the last year (!) – for some reason, I haven’t been getting automatic notifications of forum posts, but still no excuse. I think the answer to your question has to be “no”, for the reasons that (i) (as far as I am aware) these are not commonly recognised code values across the industry (ii) the proposal doesn’t extend the existing functionality of FpML, and could potentially introduce inconsistency. Period roll dates for an InterestRateStream are defined by the content of the CalculationPeriodDates component. Periodicity and roll day are specified by calculationPeriodFrequency, comprising [i]periodMultiplier[/i] & [i]period[/i] (e.g. 3, ‘M’) and [i]rollConvention[/i]. The [i]rollConvention[/i] element is an enumerated value, which can be an integer (day number of the month) or a code value (e.g. ‘EOM’ for end-of-month rolls). The enumeration already contains value ‘IMM’ for standard IMM dates (i.e. third Wednesdays), together with ‘IMMAUD’, ‘IMMCAD’ & ‘IMMNZD’ for currency-specific conventions defined by the relevant local exchanges. Then for a given trade having rollConvention=’IMM’, the roll date schedule is completely defined by the calculation period dates (effective & termination dates + any regular period dates for stubs), together with the period frequency (typically but not necessarily 3M). A more specific roll convention intended to specify a particular cycle of IMM roll dates (e.g. ‘IMMJAN’) would not add any precision to the existing definitions, and could be problematic if inconsistent with any of the other terms. I hope this reply may still be of some use, even after such a long elapsed time. Best regards, Harry McAllister Chair, FpML IRD-WG

[h_mcallister]

Hi neohshar, The initial implementation of a “generic” product description was (poorly) named [i]nonSchemaProduct[/i] (instance of type “NonSchemaProduct”), and first appeared in the FpML 5-1 Reporting view. The [i]genericProduct[/i] name (same underlying type) was introduced in version 5-2, but please note that the first public implementations will be based on the RecordKeeping and Transparency views at FpML [b]5-3[/b]. (Please note that [i]nonSchemaProduct[/i] is retained in the Standard for backward compatibility reasons, but should be regarded as deprecated in favour of [i]genericProduct[/i]). This area is still evolving, and the [i]genericProduct[/i] definition is likely to develop further before publication of the 5-3 Recommendation. Hope that helps, Best regards, Harry McAllister

[h_mcallister]

Hi Sunesh, I’ll discuss your questions in the context of the (more complex) case of swaps, but the principles can be generalised to FRAs also. Please bear with me where I state the obvious … The scenarios you describe can be re-phrased in slightly different terms: 1. Interest calculation period dates are adjusted in the same way as payment dates 2. Payment dates are adjusted, but interest calculation period dates are not 3. Interest calculation period (and payment) dates are adjusted, but the termination date is not The FpML InterestRateStream contains three mandatory components: [i]calculationPeriodDates, paymentDates[/i] and [i]calculationPeriodAmount[/i]. The first of these, [i]calculationPeriodDates[/i], is concerned with how the interest calculation period dates are defined; the second, [i]paymentDates[/i], is concerned with payment date definitions. Each of these contains a section devoted to definition of the relevant date adjustment rules ([i]calculationPeriodDatesAdjustments[/i] and [i]paymentDatesAdjustments[/i], respectively). So calculation-period- and payment- date adjustments are defined independently of each other, and can be configured to yield the required behaviour. Moreover, specific adjustment rules are defined for the [i]effective-[/i] and [i]termination-Dates[/i], allowing these to be adjusted independently of the calculation period roll dates, which allows scenarios like (3) to be modelled. Then the three scenarios are implemented in FpML as follows: 1. [i]calculationPeriodDatesAdjustments[/i] and [i]paymentDatesAdjustments[/i] share the same business day convention (e.g. MODFOLLOWING) and holiday calendars ([i]businessCenters[/i]) 2. [i]paymentDatesAdjustments/businessDayConvention[/i] = MODFOLLOWING (for example); [i]calculationPeriodDatesAdjustments/businessDayConvention[/i] = NONE (no adjustment applies) 3. Interest & payment date adjustments per scenario 1, but with [i]calculationPeriodDates/terminationDate/dateAdjustments/businessDayConvention[/i] = NONE (no adjustment applies to the termination date) Please let me know if this answers your question. Best regards, Harry McAllister Chair, IRD-WG

[h_mcallister]

Raised issue at: http://www.fpml.org/issues/view.php?id=1057

[Author]

Posts