Messaging Patterns Proposal to change FpML Messaging

Issues Correlation Acknowledgements Exception modelling Advice vs. Notification Patterns Messaging Gaps

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

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

Correlation-Sequencing In a long running operation message ordering is important Each messages 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

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

Example false 7 1 … Lots more here … …

Example Message TypeSenderReceiverMessageIdInReplyToCorrelationIdSequenceNo RequestTradeConfirmationBANKSERVICEAB/123-BANK/7BANK/1 RequestAcknowledgedSERVICEBANKXZ/567AB/123BANK/7 ModifyTradeConfirmationBANKSERVICEAB/126-BANK/7BANK/2 RequestAcknowledgedSERVICEBANKZX/599AB/126BANK/7 TradeMatchedSERVICEBANKZX/610-BANK/7SERVICE/1 EventAcknowledgedBANKSERVICEAB/145ZX/610BANK/7

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

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

Exception modelling All existing errors can be adjusted to derive from the ExceptionMessage type rather than ResponseMessage

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

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.

Patterns The Negotiation Pattern The Distribution Pattern The Matching Pattern The Reconciliation Pattern

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

The Negotiation Pattern The key points are: –The proposing party starts the negotiation and decides when it 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

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.

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.

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

The Matching Pattern Matching is the process of pairing trades 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

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.

Messaging Gaps Gaps have been identified to FpML 4.5 applying the patterns to the existing business processes FpML 4.5 MessageUpdated ModelPatternComments RequestTradeConfirmation Negotiation AcknowledgementNegotiationNew ModifyTradeConfirmation Negotiation AcknowledgementNegotiationNew CancelTradeConfirmation Negotiation AcknowledgementNegotiationNew TradeMatched Advice AcknowledgementAdviceNew TradeMismatched Advice