FpML Issues Tracker

942: CD Conditions

June 10, 2009




Validation Rules

FpML 6 (Build 1)





The Credit Derivatives "Conditions" are derived values added to new Nodes (elements and attributes) defined by the condition.

For example: " Condition: ISDA1999Credit (context: Trade) (context: Contract) At least one of documentation/contractualDefinition element and documentation/masterConfirmation/masterConfirmationType element exists and contains the string "ISDA1999Credit".

Formal description: some $document in (//element(*, Trade) | //element(*, Contract))/documentation/(contractualDefinitions | masterConfirmation/masterConfirmationType) satisfies contains($document, "ISDA1999Credit") "

This defines a new Node named "ISDA1999Credit" on every Trade and Contract type. It provides a derivation rule, which is included in the description.

We added a lot of clarity by adding the contexts to these definitions. Making this change was a very good thing.

There is a problem with the first two sentences: "The Validation Conditions only apply when specific rules reference them. The following conditions are always to be executed relative to the root of the FpML document being validated."

#1 The first issue is the second sentence contradicts the Context given in the definition of the Condition. I suggest it be corrected or struck out.

#2 The second issue is the first sentence is a nonsense as it seems to be trying to control the application of rules. When we validate with the validation rules, all the rules apply each time. It is the contexts which determine which rules 'fire', nothing else. I suggest this is struck out.

#3 The third issue is how do we refer to these conditions in the rules referencing them? So far we have used $ISDA1999Credit to refer to the first condition, as if it was an XPath variable. The problem with this approach is that it only works if each condition appears once. As each condition appears once per Context, and the context appears many times then we need a way to distinguish between all the different $ISDA1999Credit. I suggest that for each Conditions context we define a name, a datatype and treat it as a derived element or attribute on the context. That way when I have a Valuation with hundreds of trades the rules still work. At the moment the rules break when there is more than one trade in a message.

" Name: isda1999Credit Node: element

English Description: Context: Trade (complex type), Contract (complex type) Derivation rule: At least one of documentation/contractualDefinition element and documentation/masterConfirmation/masterConfirmationType element exists and contains the string "ISDA1999Credit".

XPath description: Context: //element(*, Trade), //element(*, Contract) Derivation rule: some $document in documentation/(contractualDefinitions | masterConfirmation/masterConfirmationType) satisfies contains($document, "ISDA1999Credit") "

#4 They are currently named conditions. I suggest they are named "Definitions" and placed in the rules-functions.xml file, as they are not defined to be specific to CDS.

In summary, these conditions need to be changed so they work when there is more than one Trade or Contract in a message.


  • cnentwich2

    06/12/09 7:40 am

    I agree that the formulation of the preconditions is a bit weak. It’s probably one of the oldest surviving parts of these documents.

    I have no opinion on how to reference the conditions in XPath statements. XPath does not have a sophisticated enough execution model to deal with preconditions efficiently, adoption of some convention would be helpful.

    If you are really after definable semantics of how preconditions can work, and want to avoid cases that cause problems when multiple trades are present in an FpML document, the following behaviour adopted by NRL may be of interest.

    NRL defines “rules”, which are constraints, and “rule sets”, which are a set of constraints. A rule set comes with an optional pre-condition. If the rule set is violated, the constraints do not execute. Like a rule, a rule set has a “context ” where it applies.

    So much for the static definition, now for an operational semantics: it is expected that the rule set pre-conditions are validated first. To do this, a context in the document is found for every rule set – there may be many. If the rule set precondition passes, rules in the rule set are only applied to descendant of the rule set context match location.

    In other words: if a rule set applies to a Trade with ISDA1999 rules, the rules in the set would only apply under the element with type Trade. This behaviour will be what you are looking for, unless you have recursive types (which does not happen in FpML).

    I have relatively little opinion on how FpML should a) specify operational semantics like this b) express it in the rule documents. Hopefully it will be useful for a discussion! One thing I do suspect is that treating rule sets just like functions will make your life harder.

  • matthewdr

    07/21/09 1:58 pm

    Discussed at the VWG. It seemed reasonable but agreed to come back to it after more thoughts from the members.

  • matthewdr

    07/28/09 1:20 pm

    Discussed at the VWG. We agreed to wait for Daniel’s thoughts.

  • matthewdr

    07/28/09 1:20 pm

    Daniel was at the meeting in the background. We agreed to make a final decision next week.

  • danieldui

    07/29/09 12:19 pm

    I agree with Matthew’s points #1 and #2.

  • danieldui

    07/29/09 2:28 pm

    I agree also on point #3: The rule should work also when there are multiple trades in one message.

    We discussed in relation to another issue that perhaps a rule should
    have only one context. For consistency, I think that if a rule can have only one context, so should a condition.

    In this case the context is “Trade and Contract”. Perhaps Trade and
    Contract should have a common abstract base type. I quickly checked the conditions in the various asset classes and I think that all
    conditions that use more than one context use Trade and Contract.

    About moving the definitions to rules-functions.xml: It’s true that
    these conditions are not defined as specifc to CDS products,
    but, I’d keep them with the other CDS rules, if they are referenced only by CDS rules. I’d move them to a shared, product-independent
    resource file if and when rules for other asset classes need to
    reference them.

  • mgratacos

    08/11/09 1:54 pm

    Val WG: ageement to implement Daniel’s note.

  • iyermakova

    03/16/10 6:50 pm

  • danieldui

    03/29/10 3:19 pm

    Update from meeting on 2010-03-23: AJ not present. The task is rolled forward.

  • danieldui

    04/19/10 4:23 pm

    Meeting on 2010-04-13: Action still pending.

  • danieldui

    08/18/10 11:22 am

    Meeting on 2010-08-03: Action still pending.

  • lyteck

    10/18/10 6:45 pm

    Deleted the first two sentences of the “Conditions” section as agreed in # 1 and # 2 (change will be reflected in the next drafts of FpML 4.9 and 5.1)

    The Conditions section now starts as:

    The context of the rule is NOT carried through to the condition.”

  • lyteck

    10/18/10 8:11 pm

    on #3 need clarification: Let’s take the example of a rule, CD-3b, which uses condition ISDA1999Credit.

    the condition ISDA1999Credit is currently defined as:
    (context: Trade) (context: Contract) At least one of documentation/contractualDefinition element and documentation/masterConfirmation/masterConfirmationType element exists and contains the string “ISDA1999Credit”.

    –English Description:
    Context: ContractualTermsSupplement (complex type)
    If condition ISDA1999Credit is true, then the content of type must not begin with the string “ISDA2003Credit”.
    –XPath Description:
    Context: ContractualTermsSupplement
    not(start-with(type, “ISDA2003Credit”))

    So if I understand the problem correctly, if an FpML document contained 2 , and if the condition ISDA1999Credit is true for one , then, as it stands, rule CD-3b would still (incorrectly) fire for the second because the ISDA1999Credit condition is evaluated to be true for the entire FpML document? In other words, the contractualDefinition or masterConfirmationType (containing “ISDA1999Credit”) must have the SAME unique ancestor as the under evaluation??

  • danieldui

    06/25/13 3:51 pm

    Try to reformulate rule. Remove formal description. We need to find a way to make it trade-specific. We may need to keep it informal.

    ACTION: DD look at the schema and at how the rule could be formulated.

  • danieldui

    07/15/13 2:49 pm

  • mgratacos

    07/15/13 3:00 pm

    I think ISDA1999 and ISDA2003 may be ambiguous. I’d prefer ISDA1999Credit and ISDA2003Credit.

  • danieldui

    07/16/13 1:57 pm

    Marc, I don’t mind. Either is OK for me.

  • danieldui

    07/16/13 1:58 pm

    Needs to be reviewed when more VWG members are present.

  • danieldui

    07/30/13 2:17 pm

    Action for DD: The VWG reviewed DD’s proposal. DD will propose a new formulation referencing ancestor the element of product.

  • danieldui

    08/19/13 1:30 pm

    I uploaded a new file 2013_08_19_CDS_conditions.docx .

    The formulation is now OK. Since the validation rules syntax does not support quantifiers, I was able to come up only with the informal rule description.

  • danieldui

    08/20/13 1:39 pm

    We discussed in meeting. The group had no additional feedback.

    – DD: seek feedback from AJ.

  • danieldui

    08/20/13 1:55 pm

    Looking at the rule again the xpath formulation can be done with the count() from XPath.

    I updated the Word document.

  • mgratacos

    01/24/20 6:44 am

    AWG 2020-01-23

    We would need to include the documentation fields as part of the product models. Then we could validate the products with information available within the products.
    This is an FpML 6.0 issue.
  • Leave an update

    You must be logged in to post an update.