FpML Issues Tracker

1020: The dates relating to valuation – holiday calendars adjustments

September 21, 2010

closed

Minor

Always

Validation Rules

Admin

danieldui

Summary

The dates relating to valuation are adjusted by exchange holiday calendars, rather than currency holiday calendars, so in some examples (e.g. eqs-ex16-forward-starting-post-european-interdealer-share-swap-short-form.xml) we use those values (GER - corresponds to the German XETRA) instead of the values defined in the businessCenterScheme, but using businessCenters container.

The question is - should the businessCenterScheme codes contain exchanges if they point to a relevant calendar for a calculation as in this case? It already contains NYEX and we have other codes that are not used in cities (TARGET, NY FED, ESAS, etc). - or should a separate scheme for exchange holiday center codes be created, not only because it is a different type but also this does not have an industry standard to the same degree as the currency codes?

Notes:

  • andrew

    09/22/10 2:57 pm

    Some options:

    1) Allow the businessCenters scheme to contain codes for things that aren’t business centres (like exchanges – NYEMX, economic areas – TARGET, NERC, etc).
    Pros: No schema changes, no additional document verboseness
    Cons: The values don’t semantically match the name of the containing element

    2) Add more schemes to represent different types of holiday calenders
    Pros: No schema changes
    Cons: Schema can only have one default scheme URL value. Some additional verbage required when using a name in the non-default scheme. Doesn’t address the discripency between the value and the containing element name.

    3) Change the model to allow for a more general defintion of holiday calendars, by adding a (or – depending on your perspective) element as an alternative or in addition to .
    Pros: Could designed to be backwards compatible. New element clearly identifies the idea of a reference to a calendar rather than a location. Multiple elements allow different schema URL defaults – less document verboseness.
    Cons: Schema change. Alternatives make rules more complex.

    4) Replace with (or )
    Pros: Clearer and simple model than (3) – No alternatives to process – easier to define rules etc. Could have one scheme for all calendars
    Pros: Completely solves the semantic issues – calendars not locations.
    Cons: Would affect implementations.

    Personally I like (3) for 4.x and (4) for 5.x. Date adjustments should reference the calendars for a business location and not the business location itself.

  • danieldui

    10/02/10 9:04 pm

    I agree with Andrew.

    With hindsight the element businessCenter maybe should have been called businessDayCalendar .

    Option 4 is probably what we want for 5.x .

    I don’t have a very strong opinion about 4.x . In order of preference I’d adopt option 1, 2, or 3 – from least to most disruptive.

  • h_mcallister

    10/05/10 11:38 am

    As Irina points out in the Description section, businessCenterScheme already contains values BRBD, ESAS, EUTA, NYFD, NYSE, USGS, none of which are business centers per se – so option (1) has already been adopted in 4.x, suggesting that the relevant “cons” are not insurmountable. In fact, values such as ‘EUTA’ are typically treated as de facto business centers by trade processing systems, so insisting on a separate scheme for these values would impose implementation costs for no practical benefit.

    If we believe that exchanges are a sufficiently different category of entity from business centers, then we can define an exchange-calendar-scheme or similar, as per the equity-swaps samples (I don’t think we have a scheme like this at present). Arguably, an exchange is no less a type of business center in this context than ‘EUTA’ or ‘NYSE’, so a hybrid business-center scheme comprising city and exchange codes could also be acceptable.

    Regarding options 3 & 4, I think we should be cautious about the impact on the installed base here. It is already well understood that “business centers” really means “business day calendars” in practice. The solution may simply be better documentation, rather than disruptive changes to established element names.

  • mgratacos

    01/31/11 1:59 pm

    Coordination Committee 2011-01-24
    Participants agreed to keep the list as it is. Agreed to update the documentation in order to clarify that business centers may include any place where business takes place, including exchanges. There are codes for some exchanges and TARGET in the list.
    Action: ISDA to update documentation of business center.

  • iyermakova

    02/17/11 8:03 pm

    As per the Coordination Committee decision, updated the Spec documentation in FpML 4.9 REC and 5.1 REC.

  • Leave an update

    You must be logged in to post an update.