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 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>

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 for

consistency

<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> <partyReference href=”BNK”/> </onBehalfOf> <execution> <trade> … Lots more here </trade> </execution> <party id=”BNK”>…</party> <party id=”SRV”>…</party>

</tradeExecutionAdvice>

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 ZX/599 AB/126 BANK/7 false

TradeMatched SERVICE BANK ZX/610 - BANK/7 SERVICE/1 false

EventAcknowledged BANK SERVICE AB/145 ZX/610 BANK/7 false

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◦ Beneficiary or

servicing party should be provided

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

Trade Roles: Solution (III) Other Roles and

Accounts◦ Support ‘Give-Ups’

and custodian account

◦ Simpler implementation Less indirection

Still Under Discussion

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.

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 The Negotiation Pattern The Distribution Pattern The Matching Pattern The Reconciliation Pattern

◦ All processes must have an ‘observable completion’

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

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

Messaging Gaps Messaging Gaps have been identified as

result of the analysis Scripts for checking will be implemented to

avoid future gaps

Appendix Patterns

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 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 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

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 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

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 RequestTradeConfirmation Negotiation isCorrection set to ‘true’

‘Acknowledgement’ Negotiation New

CancelTradeConfirmation CancelTradeConfirmation Negotiation

‘Acknowledgement’ Negotiation New

TradeMatched TradeMatched Advice

‘Acknowledgement’ Advice New

TradeMismatched TradeMismatched Advice