1 / 37

Messaging Patterns

Messaging Patterns. Proposals to change FpML Messaging. Content. Correlation Acknowledgements Exception modelling Advice vs. Notification Corrections On behalf of Trade Roles Trade vs. Contract Messaging Gaps. Correlation.

gaia
Download Presentation

Messaging Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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</correlationnId> <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 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 negotiated outcome 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 entirely the 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

More Related