1 Messaging Patterns Proposals to change FpML Messaging
Mar 27, 2015
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
Requestor Responder
Request
Response
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’
Document
Message
Response Message
Notification Message
Request Message
Exception Message
11
Advice vs. Notification A true notification should be something that
we can choose to disregard without having to inform anyone else
Informer Informed
Notification
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.
Informer Informed
Advice
Acknowledgement or
Exception
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
ExampleMessage Type Sender Receiver MessageId InReplyTo CorrelationId SequenceNo isCorrection
RequestTradeConfirmation BANK SERVICE AB/123 - BANK/7 BANK/1 false
RequestAcknowledged SERVICE BANK XZ/567 AB/123 BANK/7 false
RequestTradeConfirmation BANK SERVICE AB/126 - BANK/7 BANK/2 true
RequestAcknowledged SERVICE BANK XZ/599 AB/126 BANK/7 false
TradeMatched SERVICE BANK XZ/610 - BANK/7 SERVICE/1 false
EventAcknowledged BANK SERVICE AB/145 ZX/610 BANK/7 false
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
Offer
Propose
Abandon
Agreement
Confirm
Accept
Proposal
Counter Propose
Reject
Abandoned
Confirm
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.
Informing Party
Informed
Inform
Acknowledge or
Exception
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.
Time
Time when action is scheduled
Time when action processing begins
t0 t1 t2
Time when action can be cancelled
Time when action has already occured
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
Informing Party
Informed
Retract
Acknowledge or
Exception
Informing Party
Informed
Correct
Acknowledge or
Exception
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
Request Match
Unmatched
Mismatched
Timeout 1/Allege
Timeout 2/ Unmatched
Matched atach found
Modify Match
Cancel Match
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.
Submitted
Create/Adjust
Unsubmitted
Submit
Report
Create/Adjust
37
Messaging Gaps Gaps have been
identified to FpML 4.5 applying the patterns to the existing business processes
FpML 4.5 Message Updated Model Pattern Comments
RequestTradeConfirmation RequestTradeConfirmation Negotiation
‘Acknowledgement’ Negotiation New
ModifyTradeConfirmation RequestTradeConfirmation Negotiation isCorrection set to ‘true’
‘Acknowledgement’ Negotiation New
CancelTradeConfirmation CancelTradeConfirmation Negotiation
‘Acknowledgement’ Negotiation New
TradeMatched TradeMatched Advice
‘Acknowledgement’ Advice New
TradeMismatched TradeMismatched Advice