[h_mcallister]

Hi Arty,

I agree that in this case the calculation (and payment) period is best expressed as “1T”. I’m not aware of an “unwritten convention” to encode such swaps with a 1Y period – although I have seen trade bookings done this way (i.e. with a period longer than the actual term, to avoid the term being sub-divided into shorter periods).

OIS swaps are typically transacted for a single, possibly irregular, period of up to 1Y duration. By common convention these are represented with calculation-, payment- and reset- Period all = 1T, with reset relative to the calculation period end date. This pattern is indicative of a single-period OIS – but does not imply that the “1T” idiom is reserved to OIS swaps (it is not).

Zero coupon swap streams should be booked with paymentFrequency=1T, to signify that the (single) payment period spans the term of the trade.

Best regards,
Harry

• This reply was modified 7 years, 7 months ago by h_mcallister.
• This reply was modified 7 years, 7 months ago by h_mcallister.
• This reply was modified 7 years, 7 months ago by h_mcallister.

[h_mcallister]

Hi Gary,

To your question about productType : as a general principle it should not be necessary to refer to the (optional) productType to determine the applicable payoff calculation. Although FpML does not specify the calculation method explicitly in the message, this should always be inferrable from the product characteristics.

In the case of zero-coupon fixed leg on an inflation swap, one widely adopted convention is to specify the payment period as a number of years equal to the term of the contract. Taken together with the calculation period (usually annual), this implies a zero-coupon calculation delivering a single payment at term; the numeric value of the paymentFrequency/periodMultiplier can be substituted directly for the “term” expression in the equation above.

An alternative would be to express the payment frequency as “1T” (one term). This is arguably a clearer signal that a zero coupon arrangement exists (the message consumer does not have to verify that the payment frequency precisely spans the term of the contract), but obliges the consumer to derive the exponent term of the payoff calculation (i.e. calculate the number of calculation periods which comprise the payment term).

Lastly, as the zero-coupon fixed payment is deterministic, the knownAmountSchedule could be used to express the payment amount, omitting the calculaton parameters altogether (this approach is commonly used for zero-coupon interest rate swaps).

The current inflation swap samples should not be regarded as normative – it is likely that they did not receive the appropriate level of scrutiny prior to publication. This is unfortunate, as the purpose of the samples is to serve as an authoritative reference for implmentation. The FpML Interest Rate Working Group has been re-constitued for FpML 5-10, revision/correction of the Inflation samples is one of the first items in its book of work: please refer to the minutes of the recent meetings. The intention is to re-publish the inflation swap samples with FpML 5-10 – I think there is also a case for correcting the existing samples at earlier versions retrospectively.

Apologies for the delayed response to your query – please let me know if you have further questions.

Harry McAllister
Chair, FpML IRD-WG

• This reply was modified 8 years ago by h_mcallister.
• This reply was modified 8 years ago by h_mcallister. Reason: typo

[h_mcallister]

Hi YC,

Taking your points in order:

(1) Agreed, it is best practice to produce a (user specified) scheme declaration for each of messageId, inReplyTo, sentBy, sentTo

(2) Elements sentBy, sentTo, copyTo are instances of type MessageAddress, having scheme attribute messageAddressScheme whose type is xsd:anyURI, in common with other coding schemes.

(3) In general, it is good practice to validate messages from external sources, to ensure that they meet the base requirements with respect to structure & data content.

(4) Not sure if I understood your question about validating “to check if any changes have been made” – can you elaborate, please?

Coding scheme declarations are not schema-validated by design, allowing users the ability to produce their own scheme declarations. Where it is necessary to distinguish between different coding schemes, this should be performed by application logic as a supplementary phase to schema validation. In some interfaces, the message address coding scheme(s) can be understood implicity from context – although this is by no means universal.

A more detailed explanation of the distinction between coding schemes and schema enumerations and their use cases can be found in the FpML Architecture Specification.

Best regards,
Harry

• This reply was modified 8 years, 1 month ago by h_mcallister. Reason: typo
• This reply was modified 8 years, 1 month ago by h_mcallister.

[h_mcallister]

The implementation looks reasonable, thanks.

I noticed this at line 774 in the comments:

// applies rule to handle misuse of EOM to mean last business day for startDate

I’m not sure why this is characterised as “misuse” (e.g. EOM + MODFOLLOWING would always imply an adjusted date falling on the last business day of the month)?

• This reply was modified 8 years, 1 month ago by h_mcallister.

[h_mcallister]

In fact it is common practice to confirm the effective date of a IR Swap as an *adjusted* value; being close to the trade date, the adjusted effective date can be specified with a high degree of confidence. Then conventional usage is to specify effectiveDate/dateAdjustments/businessDayConvention=”NONE”, signalling that no further adjustment is required (note, this usage pre-dates the availability of adjustedDate in the AdjustableDate type).

To determine whether the (implicitly adjusted) effective date implies a stub, it is necessary to consider whether the effective date value is consistent with the *unadjusted* date implied by calculationPeriodDatesAdjustments/businessDayConvention in conjunction with calculationPeriodFrequency. This in turn requires access to reference data (holiday calendar(s) for the relevant business centers), so cannot be determined from the content of the FpML document alone.

Provided the implicity adjusted effective date is derivable from the regular calculation period parameters, together with any applicable date adjustments, no stub exists. Where the effective date is not consistent with the regular period parameters plus adjustments, a stub exists and firstRegularPeriodStartDate must be specified.

So in answer to your final question: yes, this is de facto usage, consistent with the FpML specification.

With apologies for the delayed response.
Harry McAllister

• This reply was modified 8 years, 2 months ago by h_mcallister. Reason: changes to emphasis
• This reply was modified 8 years, 2 months ago by h_mcallister.
• This reply was modified 8 years, 2 months ago by h_mcallister.

[h_mcallister]

I note that the text description of ird-10 does not match the XPath definition (no mention of last-day-of-month in the English language description). This rule can fail in the legitimate edge case described above (pre-adjusted effectiveDate with businessDayConvention=”NONE”).

• This reply was modified 8 years, 2 months ago by h_mcallister.

[h_mcallister]

I agree, a valid FpML swap has no implied stubs. By definition, the regular part of the calculation period schedule is the portion where (unadjusted) period start|end dates conform to the roll convention. This comprises (at a minimum) the period defined by the “internal” roll dates (i.e. between the first period end date and last period start date) – and also the effective|termination dates in the absence of initial|final stubs.

There is one way in which the example in question could constitute valid FpML: I don’t know which business centers are referenced, but if we allow that 2016-04-29 (Friday) is a holiday, then effectiveDate/unadjustedDate could be declared as 2016-04-28 (Thursday) with dateAdjustments/businessDayConvention=NONE, signifying that applicable adjustments have already been applied. Then the unadjusted effective date *implied* by the roll convention is 2016-04-30 (Sunday), which adjusts to 2016-04-28 under the MODFOLLOWING rule. Given these particular circumstances, the FpML would be valid.

[h_mcallister]

This looks good – though I think references in the text to “notionalAmountSchedule” should (of course) read “knownAmountSchedule” (?)

Thanks,
Harry

[h_mcallister]

Hi,

Thanks for your very clear explanation. Interpreting the schedule as setting the amount for each period is consistent with the behaviour of schedules for other properties of the InterestRateStream, and also works in the case of the zero coupon fixed leg (represented as a single period spanning the term between effective- and termination- dates).

I agree that knownAmountSchedule/stepDates should be constrained to the (unadjusted) period dates corresponding to the boundaries of payment periods, as implied by the paymentDates block.

If there is a problem with knownAmountSchedule, it is that the expected usage not clearly documented, either in schema annotations or (at all) in the online documentation – we should fix this. We don’t see knownAmountSchedule used in the public domain (industry utilities, service providers etc.) for cases other than the zero coupon bullet payment – however that does not preclude other usages e.g. for internal processing with firms.

Best regards,
Harry

• This reply was modified 8 years, 3 months ago by h_mcallister.
• This reply was modified 8 years, 3 months ago by h_mcallister.

[h_mcallister]

Hi, I’d be interested to understand how you interpret the components of the knownAmountSchedule …

Presumably the values within the schedule are interpreted as payment amounts exchanged between the payer- and receiver- parties in the containing swapStream. In that case, the stepDates of the schedule would correspond to the (unadjusted) payment dates implied by paymentDates.

However the initialValue of the schedule does not have an associated date. In other contexts (e.g. notionalStepSchedule), the initialValue is assumed to apply as at the effectiveDate. However in a conventional vanilla swap with payment in arrears, the first payment date falls on the first period end date. Is this date assumed for the initialValue when processing the knownAmountSchedule (then the first step/stepDate would correspond to the second payment date)?

Please confirm if my understanding is correct ..

Best regards,
Harry

[h_mcallister]

Hi roma, scolebourne,

I suspect that ird-54 is redundant: knownAmountSchedule is used by convention to specify the single bullet payment at term on a zero coupon fixed leg – this is the only use case for the structure. The scenario considered by scolebourne (validation on the content of stubCalculationPeriodAmount) does not apply in this context, by definition.

Best regards,
Harry

• This reply was modified 8 years, 3 months ago by h_mcallister.

[h_mcallister]

Hi andyjm,

COP-IBR-OIS-COMPOUND has been added to floating rate index scheme version 2.16, issued with version 1.78 of the FpML Coding Schemes published 02 August 2016.

Best regards,
Harry

[h_mcallister]

Hi Alex,

I think the intended usage of party/creditRating is indeed simple e.g.:

<party id=”partyA”>
<!– content omitted –>
<creditRating creditRatingScheme=”http://www.fpml.org/coding-scheme/external/moodys”>B3</creditRating&gt;
<creditRating creditRatingScheme=”http://www.fpml.org/coding-scheme/external/standard-and-poors”>B</creditRating&gt;
<creditRating creditRatingScheme=”http://www.fpml.org/coding-scheme/external/fitch”>CC</creditRating&gt;
</party>

The external schemes which you referenced above were introduced to support the more detailed credit rating model used by the SCSA under the FpML legal view (complexType CreditNotation). I don’t think it was intended that these should be deployed within party/creditRating in the way you have attempted above.

I guess there could be a case for supporting a collection of CreditNotation instances within Party, as an alternative to the existing simple creditRating. I agree that the absence of use cases for party/creditRating in the examples if frustrating.

There are illustrations of the use of CreditNotation under the legal view – please refer to legal-ex-03 & -04 (I would argue that the schemes are redundant here, being implied by the agency).

Cheers,
Harry

• This reply was modified 8 years, 6 months ago by h_mcallister.
• This reply was modified 8 years, 6 months ago by h_mcallister.

[h_mcallister]

Conversely, fixed leg swapStream contains a fixedRateSchedule (swapStream/calculationPeriodAmount/calculation/fixedRateSchedule).

Also, be aware of the alternate representation for a zero coupon fixed leg, which uses swapStream/calculationPeriodAmount/knownAmountSchedule to represent the bullet payment at term (no fixedRateSchedule).

Finally, note that the recordkeeping view schema permits the choice of rate calculation (fixedRateSchedule|floatingRateCalculation|inflationRateCalculation) to be omitted altogether – although this should happen in any meaningful report.

[h_mcallister]

Hi JCP,

Removal of the additionalEvent extension point has been recognised as an inadvertent error resulting from refactoring of the Events models in FpML 5-8. The Architecture working group is working on reinstating the element in FpML 5-9, and the intention is to issue an erratum for 5-8.

In general, schema components should not be withdrawn in a minor verion (FpML guarantees backward compatibility within a major version series, unless for exceptional reasons which must be endorsed by the Standards committee).

You can follow the recent discussions on additionalEvent on the AWG mailing list at: http://www.fpml.org/mg_groups/fpml-awg/

Best regards,
Harry McAllister

• This reply was modified 8 years, 8 months ago by h_mcallister.

[Author]

Posts