Enhancing FpML Messaging: Proposals for Improved Correlation and Exception Management**

1. Messaging Patterns Proposals to change FpML Messaging

2. Content • Correlation • Acknowledgements • Exception modelling • Advice vs. Notification • Corrections • On behalf of • Trade Roles • Trade vs. Contract • Messaging Gaps

3. Correlation • Confusion in the current model on how to identify the context in which the messages will be interpreted • conversationId • Optional • Not well-defined • eventId • Optional • Not in all messages (before 4.2) • Forces common content for all messages

4. Correlation: solution (I) • correlationId • Applied to all messages • Allocated by the initiator of the business process

5. Correlation-Sequencing • In a long running operation message ordering is important • Each message’s ‘messageId’ is unique • But the order of messages can not be inferred by comparing two identifiers • Existing implementations (SWIFT-CUG) use trade versioning to derive ordering

6. Sequencing: solution (II) • sequenceNo • To define a sequence number • Although sequence numbers should be consistently increasing in value they do not have to form a gapless sequence

7. Example <tradeExecutionAdvice> <messageHeader> </messageHeader> … <correlationId correlationIdScheme=”http…BANK…”>7</correlationId> <sequenceNo sequenceNoScheme=”http…BANK…”>1</sequenceNo> … <execution> <trade> … Lots more here </trade> </execution> <party id=”BNK”>…</party> <party id=”SRV”>…</party> </tradeExecutionAdvice>

8. Acknowledgements • All requests messages must have an immediate response • It allows a more synchronous style of design

9. Exception modelling • Worth recognizing errors separately from normal responses • Add consistency across exceptions

10. Exception modelling • All existing errors can be adjusted to derive from the ExceptionMessage type rather than ‘ResponseMessage’

11. Advice vs. Notification • A true notification should be something that we can choose to disregard without having to inform anyone else

12. Advice vs. Notification • Most of the information we distribute as notifications we expect the receiver to act upon rather than ignore • Often we would like an acknowledgement of that action (e.g. ContractNotifications, matching results, etc) • Really this should be implemented as an ‘advice’ pattern using a request/response style pattern.

13. Corrections • Lack of consistency defining correction messages • <isCorrection> flag has been added to distinguish between correcting vs. Non-correcting messages • Used in patterns like distribution

14. onBehalfOf • There are situations where a third party can not easily tell which side of the trade he is supposed to be processing • Neutral view principle • Communication to a common third party

15. onBehalfOf • An explicit indication of the party for whom the trade should be processed is needed • It should be included in every message for consistency <someRequest> <messageHeader> … Basic message details </messageHeader> … <onBehalfOf> <partyReference href=”JPM”/> <accountReference href=”PORTFOLIO1”/> </onBehalfOf> … Request specification here</someRequest>

16. Example <tradeExecutionAdvice> <messageHeader> </messageHeader> <isCorrection>false</isCorrection> <correlationId correlationIdScheme=”http…BANK…”>7</correlationnId> <sequenceNo sequenceNoScheme=”http…BANK…”>1</sequenceNo> <onBehalfOf> <partyReference href=”BNK”/> </onBehalfOf> <execution> <trade> … Lots more here </trade> </execution> <party id=”BNK”>…</party> <party id=”SRV”>…</party> </tradeExecutionAdvice>

17. Example

18. Trade Roles • The addition in FpML 4.2 of the trade side structure allows party roles to be associated with a trade • The TradeSide structure is used to capture the role information mixes contractual and processing information • Most of these values are only relevant to specific business processes • They should be properties of the supporting messages

19. Trade Roles: Solution (I) • Separation of Party and Account • Make relationships clearer • Beneficiary or servicing party should be provided

20. Trade Roles: Solution (II) • Internal trades • Current model assumes buyer & seller always different • Difficulty to represent internal trades • New optional account reference • Single party in both sides is possible • Info for settlement

21. Trade Roles: Solution (III) • Other Roles and Accounts • Support ‘Give-Ups’ and custodian account • Simpler implementation • Less indirection • Still Under Discussion

22. Trade vs. Contract • Two structures describing the same information • Business process need to be duplicated • Examples: novations, terminations,… • Validation rules need to be duplicated • ISDA legal documentation uses term ‘Transaction’. ‘Trade’, ‘deal’, ‘contract’ and ‘transaction’ are often used interchangeably.

23. Trade vs. Contract (Solution) • The ‘contract’ concept could be removed from the schema and the CUG messages reverted to a ‘trade’ based model • Migrating Contract messages to trade has been analyzed (see separate presentation)

24. Messaging Gaps • Requirements • Existing message sequences must follow a Messaging Pattern • The Negotiation Pattern • The Distribution Pattern • The Matching Pattern • The Reconciliation Pattern • All processes must have an ‘observable completion’

25. Overview of Patterns • The Negotiation Pattern • In many business processes a series of exchanges are needed between the participants before are an agreement can take place on the final outcome • Examples of negotiation include the post trade operations (e.g. amendment, increase, full/partial termination, cancellation, etc.) • The Distribution Pattern • In many business processes the outcome of the negotiation often needs to be distributed to other parties not directly involved in the negotiation but who have a role in future operations • The general pattern for distribution should follow the ‘advice’ style discussed earlier

26. Overview of Patterns • The Matching Pattern • Matching is the process of pairing items (trades, events,…) submitted by their counterparties based on their definition. • The Reconciliation Pattern • It can take time for the participants to establish the data set they want the process to apply to and as a result the content of the data set may need to be changed before the processing can actually begin. • See Appendix for more details on exchange patterns

27. Messaging Gaps • Messaging Gaps have been identified as result of the analysis • Scripts for checking will be implemented to avoid future gaps

28. Appendix • Patterns

29. Patterns • The Negotiation Pattern • The Distribution Pattern • The Matching Pattern • The Reconciliation Pattern

30. The Negotiation Pattern • In many business processes a series of exchanges are needed between the participants before an agreement can take place on the final outcome

31. The Negotiation Pattern • The key points are: • The proposing party starts the negotiation and decides when he has reached an outcome that he will accept or abandon the process • The other party must always produce an offer based on the last proposal. He will only confirm an acceptance made on his last offer

32. The Distribution Pattern • In many processes the outcome of the negotiation often needs to be distributed to other parties not directly involved in the negotiation but who have a role in future operations • The general pattern for distribution should follow the ‘advice’ style discussed earlier • The informer would normally like to know that the informed party has received and understood the information.

33. The Distribution Pattern • Sometimes an action cannot be accepted • At time t0 a contract notification is sent indicating that some action is to be performed at t2 • Up until t1 the original notification can be changed or cancelled because it has had no external effect • Between t1 and t2 modifying the action becomes more difficult with associated financial costs. • Any attempt to modify the original notification should be refused to force the informer to issue a ‘compensating transaction’ • The informer does not know when the informed has entered the ‘grey-area’ unless the notification can generate a response.

34. Distribution: Correcting Mistakes • Sometimes an advice is sent containing the wrong information • The message details are sent to the entirely wrong party • The message is sent to right party but the details are incorrect • Retraction and correction is necessary

35. The Matching Pattern • Matching is the process of pairing items (trades, events,…) submitted by their counterparties based on their definition • The status of a trade held within a matching engine is ‘unmatched’ until one of three outcomes is decided • Matched • Mismatched • Unmatched

36. The Reconciliation Pattern • Cash flow and portfolio reconciliation are both long running reconciliation processes. • The process begins with the requester either creating a new data set or adjusting the content of an existing one.

37. Messaging Gaps • Gaps have been identified to FpML 4.5 applying the patterns to the existing business processes