623: cd-4 does not state what to do with multiple contractuals supplements

The rule today is: ” cd-4 (Mandatory) Preconditions: ISDA2003 documentation/contractualSupplement must not begin with the substring ISDA1999Credit. ” There are many possible interpretations. Here are two possibilities: 1. Every documentation/contractualSupplement must not begin with the substring ISDA1999Creditor. 2. At least one documentation/contractualSupplement must not begin with the substring ISDA1999Credit. If the intent was the first … Continued

622: Manual 4.8 limits us to trades only

Section 4.8 of the manual limits us to trades: “Applications that receive FpML for processing may want to check the validation rules to ensure that the data they are receiving represent a valid FpML trade.” These days FpML does a lot more than send trades around. I propose this is changed to: “Applications that receive … Continued

621: shortForm ‘precondition’ needs to keep up with contractualTermsSupplement changes

//contractualTermsSupplement has changed in structure. The shortForm precondition needs to change in structure to keep up with changes in the things it references. NB There are problems with the ambiguity of the shortForm ‘precondition’ that also need resolving. See issue #620. Today’s text: ” Precondition: ShortForm (context: Trade) (context: Contract) documentation/masterConfirmation exists or documentation/contractualMatrix exists … Continued

620: CD PreCondition ShortForm is ambiguous

The CD ‘Pre-Condition’ in the Validation Rules is ambiguous. Today’s text: ” Precondition: ShortForm (context: Trade) (context: Contract) documentation/masterConfirmation exists or documentation/contractualMatrix exists or documentation/contractualTermsSupplement exists and begins with substring iTraxx or CDX. ” The two most sensible interpretations of this are: Interepretation 1: exists(matches(//documentation/(masterConfirmation|contractualMatrix|contractualTermsSupplement), “^(iTraxx|CDX)”)) Interepretation 2: exists(//documentation[masterConfirmation|contractualMatrix|contractualTermsSupplement[matches (., “^(iTraxx|CDX)”)]]) I believe the intended … Continued

619: cd-5 has an incomplete scenario and unnecessary condition

Problem 1: Validation rule cd-5 does not cater for the scenario where either or both of //element(*, GeneralTerms)/(effectiveDate|scheduledTerminationDate) do not exist. Problem 2: The existence of //element(*, GeneralTerms)/scheduledTerminationDate is sufficient for the existence of //element(*, GeneralTerms)/scheduledTerminationDate/adjustableDate. Or informally: if you have a scheduledTermination then you always have a adjustableDate because it makes adjustableDate’s existence mandatory. … Continued

618: cd-4 Incorrect use of “substring”

Rule cd-4 use the term “substring” incorrectly: cd-3 (Mandatory) Preconditions: ISDA1999 documentation/contractualSupplement must not begin with the substring ISDA2003Credit. “ISDA2003Credit” is a type of String. It is not a type of Substring. In popular usage by IT people Substring is a function or comparator. In plain English a substring is something that isn’t quite a … Continued

617: cd-3 refers to deprecated element

cd-3 refers to the element //element(*, Trade)/documentation/contractualSupplement which is DEPRECATED. ” cd-3 (Mandatory) Preconditions: ISDA1999 documentation/contractualSupplement must not begin with the substring ISDA2003Credit. ” Two fixes are required: 1. cd-3 should itself be marked as deprecated. 2. cd-3b should be created for the rule on the new element. cd-3 should now refer to cd-3b.

616: cd-1 wrong context

cd-1 today is: ” Context: Trade (complex type) cd-1 (Mandatory) Preconditions: SingleName tradeHeader/tradeDate must be before creditDefaultSwap/generalTerms/effectiveDate/unadjustedDate. ” The context changed to header to come into line with the Architecture. This is good. However the new Context isn’t corrtect. The context should be (in XPath): ” Context: //element(*, Trade)[creditDefaultSwap] cd-1 (Mandatory) Preconditions: SingleName tradeHeader/tradeDate must … Continued

615: ird-6 and relativeEffectiveDate

” (Mandatory) Preconditions: isParametric paymentDates/firstPaymentDate > calculationPeriodDates/effectiveDate/unadjustedDate. ” The problem is that some swapStreams had calculationPeriodDates/relativeEffectiveDate. How do I interpret this rule under that scenarios? Should the rule be refined to cope with relativeEffectiveDate, or is this an additional precondition and a new rule?

614: ird-6 requires a precondition of hasInitialStub

” (Mandatory) Preconditions: isParametric paymentDates/firstPaymentDate > calculationPeriodDates/effectiveDate/unadjustedDate. ” The problem is that firstPaymentDate is an optional element. The firstPaymentDates only apply for legs with an initial stub. I suggest either we add a ‘precondition’ for ird-6 that the swapStream “hasInitialStub”.