FpML Issues Tracker
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.