messaging patterns proposal to change fpml messaging
Post on 27-Mar-2015
225 Views
Preview:
TRANSCRIPT
Messaging Patterns
Proposal to change FpML Messaging
Content
• Correlation• Acknowledgements• Exception modelling• Advice vs. Notification• Corrections• On behalf of• Trade Roles• Trade vs. Contract• 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 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
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<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>
ExampleMessage Type Sender Receiver MessageI
dInReplyT
oCorrelationI
dSequenceN
o
RequestTradeConfirmation
BANK SERVICE AB/123 - BANK/7 BANK/1
RequestAcknowledged SERVICE BANK XZ/567 AB/123 BANK/7
ModifyTradeConfirmation BANK SERVICE AB/126 - BANK/7 BANK/2
RequestAcknowledged SERVICE BANK ZX/599 AB/126 BANK/7
TradeMatched SERVICE BANK ZX/610 - BANK/7 SERVICE/1
EventAcknowledged BANK SERVICE AB/145 ZX/610 BANK/7
Acknowledgements
• All requests messages must have an immediate response
• It allows a more synchronous style of design
Requestor Responder
Request
Response
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’
Document
Message
Response Message
Notification Message
Request Message
Exception Message
Advice vs. Notification
• A true notification should be something that we can choose to disregard without having to inform anyone else
Informer Informed
Notification
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.
Informer Informed
Advice
Acknowledgement or
Exception
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
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
onBehalfOf
• An explicit indication of the party for whom the trade should be processed is needed– It should be included in every message
<someRequest> <messageHeader> … Basic message details </messageHeader> … <onBehalfOf> <partyReference href=”JPM”/> <accountReference href=”PORTFOLIO1”/> </onBehalfOf> … Request specification here</someRequest>
Example<tradeExecutionAdvice>
<messageHeader>
</messageHeader> <isCorrection>false</isCorrection> <correlationId correlationIdScheme=”http…BANK…”>7</correlationnId> <sequenceNo sequenceNoScheme=”http…BANK…”>1</sequenceNo> <onBehalfOf> <partReference href=”BNK”/> </onBehalfOf> <execution> <trade> … Lots more here </trade> </execution> <party id=”BNK”>…</party> <party id=”SRV”>…</party>
</tradeExecutionAdvice>
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
Trade Roles: Solution (I)
• Separation of Party and Account– Make relationships
clearer
Trade Roles: Solution (II)
• Book-to-Book 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
Trade Roles: Solution (III)
• Other Roles and Accounts– Support ‘Give-
Ups’ and custodian account
– Simpler implementation
• Less indirection
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
transaction. ‘Trade’, ‘deal’, ‘contract’ and ‘transaction’ are often used interchangeably.
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)
Messaging Gaps
• Requirements– Existing message sequences must follow a
Messaging Pattern• See Appendix for details on exchange patterns
– All processes must have an ‘observable completion’
• Messaging Gaps have been identified as result of the analysis
• Scripts for checking will be implemented to avoid future gaps
Appendix
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
Offer
Propose
Abandon
Agreement
Confirm
Accept
Proposal
Counter Propose
Reject
Abandoned
Confirm
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.
Informing Party
Informed
Inform
Acknowledge or
Exception
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
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 Informing
Party Informed
Retract
Acknowledge or
Exception
Informing Party
Informed
Correct
Acknowledge or
Exception
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
Request Match
Unmatched
Mismatched
Timeout 1/Allege
Timeout 2/ Unmatched
Matched atach found
Modify Match
Cancel Match
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
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 ModifyTradeConfirmation Negotiation
‘Acknowledgement’ Negotiation New
CancelTradeConfirmation CancelTradeConfirmation Negotiation
‘Acknowledgement’ Negotiation New
TradeMatched TradeMatched Advice
‘Acknowledgement’ Advice New
TradeMismatched TradeMismatched Advice
top related