[andrew]

Traditionally FpML has not modelled securties transactions although this will hopelfully change shortly – There are new working groups being formed to look into this. The instrumentTradeDetails product can be used to represent a position but I for one would like to see it replaced with a more comprehensive set of models for securities products.

[andrew]

For a standard cross currency swap there would be only initial and final exchanges of principal (unless you have an amortisation/accretion schedule in the notional amounts). If the principal on one leg is recalculated periodically then you should be using the fxLinkedNotionalSchedule and there may be intermediate exchanges of principal to reflect rate changes.

[andrew]

I’ve heard there is a way of using custom ClassLoader instances to support two conflicting Java type libraries in the same application at the same time. Although this would not help with having a common interface to both. The big question is should you be using JAXB at all? Do you really need to marshal the FpML into a set of objects for the processing you will apply to them or would it be easier to work with them at the XML level. The HandCoded Toolkit for FpML Processing supports all versions of FpML simultaneously using the same code because much of its processing is performed on the DOM structures. Worth considering.

[andrew]

It should be “The frequency specified in calculationPeriodFrequency must divide the regular period precisely”. The regular period of a swap this the time period which is not an initial or final stub period. So the regular period starts on the effectiveDate UNLESS there is an initial stub in which case it starts on the firstRegularPeriodStartDate. And the regular period ends on the terminationDate UNLESS there is a final stub in which case it ends on the lastRegularPeriodEndDate. This is one of the places in FpML where I think the language and structure of confirmations was allowed to impinge upon the data modelling too much. It would be useful to always know the start and end dates of the regular period.

[andrew]

In FpML 5.1 we have decided to removed shared-28 from the rule set because as stated the rule is not very practical. For example I might want to have time zones on ‘technical’ time values, like those in the message header but not on ‘business’ time values in the trade or product description. Thats why I have never implemented it in the HandCoded Toolkit — It was a poorly considered rule.

[andrew]

The Z suffix indicates that the time is UTC (e.g. +00:00). A time without any suffix or time zone offset has no time zone and can not be normally be ordered relative to a time with zone information. So 12:00:00 != 12:00:00Z

[andrew]

The current separation of the schema and the business rules allows implementors to both be selective in the rules they choose to adopt in thier service. Both Markit Wire and the DTCC implement a selection of standard FpML business rules and some of their own devising to validate that trades match the requirements of thier service. If the rules where embedded within the schema they would not have this flexability to mix and match rules to suit thier business needs. It’s also unclear how embedded rules would work in environments where banks have used FpML as the basis of an extended grammar for internal messaging. A strictly implemented constraint in the FpML grammar could prevent users from extending a definition as they can today. There are some rules that are so basic that it might be possible to get agreement for including them in the schema but that would leave a number of more complex rules that would still need to be checked post XML validation as they are today, and whatever technology you choose to build this in could equally well be used to the check the simple rules as well. Why validate using two different techniques when one will do everything? Constraints in schema is an interesting academic exercise but I’m personally not convinced that it will gain much practical implementation.

[andrew]

FpML 5.x currently has two defined views, confirmation and reporting. The confirmation view contains strictly defined product and business process like those in FpML 4.x and therefore it makes sense to support the full set of validation rules on this view. The case for rules on the reporting view is currently less clear. Most of our rules are product specific and intended to ensure that appropriate and consistent business data values have been defined. The product models in the reporting view are intended to express a summary of a trade and have very loose content models. We could add additional guards to the product model rules to allow them to be evaluated in the reporting view but as products in reporting messages are provided only for context the benefit of changes is limited. Business process rules are view specific and mostly dont apply in the reporting view. There is an argument for allowing some of the referential integrity rules to be applied in the reporting view. The choice of formal representation for the validation rules has been discussed many times within the working group. The XPath/XQuery style has both pros and cons. It is directly executable but as its an interpreted language I suspect its quite slow compared to other technologies (No one has ever published performance figures for an XQuery implementation). It can only implement a subset of the total number of rules as some require the coding of algorithms to manipulate dates according to common financial markets practice. These rules are in no sense ‘broken’. Probably the biggest issue with XPath/XQuery based rules however is that while the definition of the rule may be precise it is often utterly incomprehensible. For this reason the VWG favours structured English rule descriptions as these are more accessible to our user community. I doubt that FpML will ever move an XSD 1.1 Schema with embedded XQuery rules. Users of the big implementations based on FpML (e.g. MarkIt, DTCC, SWIFT) like rule checking to be separate from XML validation so that they can have looser rule sets and the ability to process syntactically correct but semantically incorrect documents if they want. The notion of a “Gold Standard” is subjective. Other implementations of the rules may implement the rule sets more completely, more efficiently and for more versions of FpML. They may also be more easly integrated into an enterprise messaging framework. They just don’t have thier source code linked into specification. – Andrew Jacobs (Validation Working Group co-chair)

[Author]

Posts