ࡱ > bjbjVV p < < X f f 8 6 p T : 26 46 46 46 46 46 46 $ 8 K; X6 J @ J J X6 o m6 + + + J 26 + J 26 + + r 5 T 5 COt 5 6 6 0 6 5 ; * ; 5 ; 5 J J + J J J J J X6 X6 + J J J 6 J J J J ; J J J J J J J J J f o :
Technical Note:
Messaging Infrastructure Support for Validation
Abstract
This document presents a number of changes to the messaging framework described in FpML 4.0 Working Draft #1. These changes are being proposed by the Validation Working Group in order to incorporate the validation of FpML documents within the workflows proposed by the messaging architecture. These proposed changes have been approved by the Messaging Working Group to be included in FpML 4.0 Working Draft #2.
This version:
HYPERLINK "http://www.fpml.org/spec/ValidationInfrastructure2003-06-10" http://www.fpml.org/spec/ValidationInfrastructure2003-06-10
Copyright 2003. All rights reserved.
Financial Products Markup Language is subject to the FpML public license.
A copy of this license is available at HYPERLINK "http://www.fpml.org/license/license.html" http://www.fpml.org/license/license.html.
Status of this Document:
The Validation Working Group issued this document to propose changes to the messaging architecture being proposed by the Messaging Working Group.
It has been approved by the Messaging Working Group to be included in FpML 4.0 Working Draft #2. Changes to the schemes presented in this document will be made to reflect the anticipated removal of default schemes from FpML 4.0. Please see the Note section at the end of this document.
Editor
Robert Stowsky- Brook Path PartnersAuthors
Daniel Dui- University College LondonSteven Lord- UBS WarburgBrian Lynn- Gem SoupChristian Nentwich- SystemwireGareth Reakes- Decisionsoft
1. Introduction
The following changes are being proposed to the FpML schema to accommodate the use of validation rules.
The attribute validationSchemeDefault has been added to the FpML root element. This attribute would point to a master FpML validation scheme. The scheme would either contain all FpML validation rules or point to other schemes containing those rules. The naming convention for the validation scheme default URI would include the FpML home, followed by the year, followed by the FpML release, followed by the literal validation, followed by a date in yyyy-mm-dd format referencing the release date of the validation scheme being used.
Example validation scheme URI:
HYPERLINK "http://www.fpml.org/2003/FpML-4-0/validation/2003-06-03" http://www.fpml.org/2003/FpML-4-0/validation/2003-06-03
The validationSchemeDefault attribute only has meaning when it is part of a request or notification message such as RequestTradeConfirmation, or TradeConfirmed. Validation rules are not applied to response messages such as TradeNotFound or MessageRejected.
The optional element validationScheme has been added to the RequestMessageHeader and NotificationMessageHeader types. The element would point to a validation scheme that has been agreed upon between the parties involved in the trade.
A reference identifying a validation scheme.
The naming convention for this schemes URI is left to the parties implementing the scheme.
The element validationScheme is not part of type ResponseMessageHeader because validation rules are not applied to response messages such as TradeNotFound or MessageRejected.
The optional element validationRuleId has been added to type Reason in order to reference a specific rule and validation scheme as part of the Reason in a MessageRejected message.
A reference identifying a rule within a validation scheme
A data type used for validation rule identifiers
The optional element errorDescription has replaced the description element in type Reason. The description element occurs in the schema fpml-eqd-4-0.xsd and while being a simple text field, it is defined as The long name of a security. The element errorDescription has been introduced for clarity.
Plain english text describing the associated error condition
An optional additionalData element has also been added to type Reason. This element has optional attributes dataDescription to annotate the elements contents and addDataType to state if the content is an XPath, text, value, etc.
Element location also has an attribute locationType to state if the content is an XPath or a character position.
2. Error Codes
The following error codes are being proposed to populate the reasonCode element used in the messageRejected message. The error codes are categorized into four levels with the top level representing abstract, business-oriented errors and the bottom level representing detailed, technically-oriented problems.
Level 400: Business Process/Workflow Problems
401: Dont know unrecognized trade
402: Suitability trade cant be done for client or dealer suitability reasons
403: Credit trade cant be done for credit reasons
404: Not interested recipient chooses not to respond
405: Other business process issue
Timing issues:
410: Message arrived too late e.g. trade no longer exists
411: Message expired message arrived on time, but a response was not generated in time
Level 300: Message Validation Problems
Message was processed but failed validation
301: Unknown or unsupported DTD/Schema (should this be at level 200?)
302: Unsupported FpML version (should this be at level 200?)
303: Invalid FpML message message doesnt validate w.r.t. specified DTD/schema
304: Validation failure unsupported message type
305: Validation failure mandatory FpML rule (a rule we say must always be followed)
306: Validation failure master agreement rule (a rule 2 parties agree to follow)
307: Validation failure business policy (a rule that only the recipient has)
308: Validation failure unsupported product/asset
309: Other validation problem
Signing problems:
310: Signature required message content must be signed
311: Signature not accepted problem with message signer (cert revoked, unacceptable principal, etc.)
Level 200: Message Integrity and Processing problems
Message couldnt be processed by recipient due to message problems
201: Lexical problem not well-formed XML
202: Unsupported character set
203: Empty or missing content
204: Content too large
Message couldnt be processed due to recipient problems
210: System unavailable
211: Message component text doesnt match digital signature hash
212: Other processing problems
Level 100: Message transport & delivery problems
Message couldnt be delivered to recipient
101: transport unavailable
102: unknown recipient/destination
103: delivered to wrong recipient
104: timeout message delivered past expiration
105: this type of message not accepted on this transport
106: message generation problem (e.g. data conversion)
109: other message delivery problems
Message damaged in transit:
110: Message corrupted (e.g. CRC failure)
111: Message text doesnt match digital signature hash
3. Examples
New message example:
Sample Trade based on example td_example_1.xml from the FpML 4.0 draft.
M#101
IBM
ISDA
2002-09-24T08:57:00-00:00
MB87623
AA9876
2002-02-14
Overnight Term Deposit
2002-02-14
2002-02-15
ACT/360
CHF
25000000.00
0.04
MIDLGB22
ABNANL2A
Message Reject example:
The first MessageReject example uses the following scenario:
1) Party A sends message to PartyB
Party A includes validation scheme references:
http://www.mybank.com/schemes/partyB/12032003
http://www.fpml.org/schemes/4.0/defaultIRD
By including these schemes, PartyA indicates that their trade follows
the default IRD rules, the IDs of which are defined by the scheme. They
also indicate that they follow the rules that were agreed bilaterally
with party B.
2) Party B receives message and validates.
We will assume that attribute validationSchemeDefault references HYPERLINK "http://www.fpml.org/2003/FpML-4-0/validation/2003-06-03" http://www.fpml.org/2003/FpML-4-0/validation/2003-06-03. The trade message sent by PartyA would have validationScheme set to HYPERLINK "http://www.mybank.com/schemes/partyB/12032003" http://www.mybank.com/schemes/partyB/12032003.
The first error scenario chosen is a failure against the rule that says the calculation period frequency in the calculation dates must divide the regular period precisely. The rule processor picks out the following elements that are associated with the
error:
/..../calculationPeriodDates (the "normative" error reference)
/..../calculationPeriodDates/effectiveDate/firstRegularPeriodStartDate
/..../calculationPeriodDates/terminationDate/lastRegularPeriodEndDate
/..../calculationPeriodDates/calculationPeriodFrequency
The Reason block of the MessageRejected message should contain the following information:
- "Semantic validation failed"
- The trade has failed a rule in scheme
http://www.fpml.org/schemes/4.0/defaultIRD
- The ID of the rule is ird-7 (stored separately from the scheme to make
routing classification easier)
- The XPath to calculationPeriodDates in the first swapstream of the
document
- Optionally: the other three paths
- A plain-text message stating the error
Using the proposed reason codes, this would use 306: Validation failure - master agreement rule (a rule 2 parties agree to follow)
In the second scenario the message from PartyA is rejected by PartyB because it did not pass a validation that is known only to PartyB resulting in PartyB sending an errorDescription value of Counter-party internal validation failed and assigning a reason code of 307: Validation failure - business policy (a rule that only the recipient has). In this scenario only the reasonCode and errorDescription element are populated. Both scenarios are addressed in the sample below. The additionalData element outside of the reason block contains the original message that is being rejected. (For demonstration purposes the xml document ird-example-04.xml from the FpML 4.0 draft is used.)
The validationScheme element is not included in the message header for response messages which include the MessageReject message.
PartyB-101
PartyA-200
PartyB
PartyA
2002-09-24T08:57:00-00:00
306
/FpML/trade/product/swap/swapStream/calculationPeriodDates
calculation period frequency in the calculation dates must divide the regular period precisely
ird-7
FpML/trade/product/swap/swapStream/calculationPeriodDates/effectiveDate/firstRegularPeriodStartDate
/FpML/trade/product/swap/swapStream/calculationPeriodDates/terminationDate/lastRegularPeriodEndDate
/FpML/trade/product/swap/swapStream/calculationPeriodDates/calculationPeriodFrequency
307
Counter-party internal validation failed
M#101
IBM
ISDA
2002-09-24T08:57:00-00:00
56323
56990
2000-04-25
2000-04-27
NONE
2002-04-27
MODFOLLOWING
GBLO
USNY
MODFOLLOWING
3
M
27
3
M
CalculationPeriodEndDate
MODFOLLOWING
CalculationPeriodEndDate
-2
D
Business
NONE
GBLO
ResetDate
3
M
MODFOLLOWING
100000000.00
USD
USD-LIBOR-BBA
3
M
ACT/360
2000-04-27
NONE
2002-04-27
MODFOLLOWING
NONE
6
M
27
6
M
CalculationPeriodEndDate
MODFOLLOWING
100000000.00
USD
0.06
2001-04-27
0.065
30/360
USD
15000.00
2000-04-27
MODFOLLOWING
MGTCGB2L
MSLNGB2XSWP
]]>
Lexical error scenario (overly simplified)
In this example the right angle bracket is removed from the element tradeHeader in ird-example-04.xml resulting in the following error being generated by an XML parser:
A name was started with an invalid character. Error processing resource
'file:/// bad_ird_example_04.xml'. Line 16, Position 4
---^
A corresponding messageRejected message would look like the following:
PartyB-101
PartyA-200
PartyB
PartyA
2002-09-24T08:57:00-00:00
201
16,4
A name was started with an invalid character.
partyTradeIndentifier
M#101
IBM
ISDA
2002-09-24T08:57:00-00:00
56323
56990
2000-04-25
2000-04-27
NONE
2002-04-27
MODFOLLOWING
GBLO
USNY
MODFOLLOWING
3
M
27
3
M
CalculationPeriodEndDate
MODFOLLOWING
CalculationPeriodEndDate
-2
D
Business
NONE
GBLO
ResetDate
3
M
MODFOLLOWING
100000000.00
USD
USD-LIBOR-BBA
3
M
ACT/360
2000-04-27
NONE
2002-04-27
MODFOLLOWING
NONE
6
M
27
6
M
CalculationPeriodEndDate
MODFOLLOWING
100000000.00
USD
0.06
2001-04-27
0.065
30/360
USD
15000.00
2000-04-27
MODFOLLOWING
MGTCGB2L
MSLNGB2XSWP
]]>
Note
FpML 4.0 Draft #2 is expected to include the removal of the default scheme attributes in the FpML root element. With this change, the validation schemes will be referenced in the following matter:
The element validation will replace element validationScheme in the RequestMessageHeader and NotificationMessageHeader types. This element has attribute validationScheme. Attribute validationScheme will default to a master FpML validation scheme. The scheme will either contain all FpML validation rules or point to other schemes containing those rules. The naming convention for the validation scheme default URI will include the FpML home, followed by the year, followed by the FpML release, followed by the literal validation, followed by a date in yyyy-mm-dd format referencing the release date of the validation scheme being used.
Example validation scheme URI:
HYPERLINK "http://www.fpml.org/2003/FpML-4-0/validation/2003-06-03" http://www.fpml.org/2003/FpML-4-0/validation/2003-06-03
Instead of the default, attribute validationScheme can point to a validation scheme that has been agreed upon between the parties involved in the trade. The naming convention for this schemes URI is left to the parties implementing the scheme.
A reference identifying a validation scheme.
Draft Technical Note: FpML Validation Messaging Infrastructure PAGE 1
H
I
J
# $ 0 X Z [
V W H P [ ` b ٻwk_w *hgB B*CJ
ph *hgB B*
CJ
ph *hgB B*CJ
ph
hgB 0J j6 hgB Uj hgB UhgB mHsH hv\ h; 0J 5h; h; 5 h; 5j h; 5U
hgB 0J 5j hgB 5U hgB 5j hgB 5U hgB 56 hgB j hgB UmHsH C D M N
2 R
Y
h
~
$If 7$ 8$ H$ ^` ~
i G kdL $$If l 0 $ 6 4
l a $If G kd $$If l 0 $ 6 4
l a
k G kd $$If l 0 $ 6 4
l a $If G kd $$If l 0 $ 6 4
l a ! 2 k i g i i b \ h^h
&