Transcript Messaging Patterns

Proposals to change FpML
Messaging
1









Correlation
Acknowledgements
Exception modelling
Advice vs. Notification
Corrections
On behalf of
Trade Roles
Trade vs. Contract
Messaging Gaps
2

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
3

correlationId
◦ Applied to all messages
◦ Allocated by the initiator of the business process
4




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
5

sequenceNo
◦ To define a sequence number
◦ Although sequence numbers should be consistently
increasing in value they do not have to form a
gapless sequence
6
<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>
7


All requests messages must have an
immediate response
It allows a more synchronous style of design
Requestor
Responder
Request
Response
8


Worth recognizing errors separately from
normal responses
Add consistency across exceptions
9

All existing errors can be adjusted to derive
from the ExceptionMessage type rather than
‘ResponseMessage’
Document
Message
Request
Message
Response
Message
Notification
Message
Exception
Message
10

A true notification should be something that
we can choose to disregard without having to
inform anyone else
Informer
Informed
Notification
11



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
12

Lack of consistency defining correction
messages
◦ <isCorrection> flag has been added to distinguish
between correcting vs. Non-correcting messages
◦ Used in patterns like distribution
13

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
14

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>
15
<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>
16
Message 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
RequestTradeConfirmation
BANK
SERVICE
AB/126
-
BANK/7
RequestAcknowledged
SERVICE
BANK
XZ/599
AB/126
BANK/7
TradeMatched
SERVICE
BANK
XZ/610
-
BANK/7
EventAcknowledged
BANK
SERVICE
AB/145
ZX/610
BANK/7
false
BANK/2
true
false
SERVICE/1
false
false
17


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
18

Separation of Party
and Account
◦ Make relationships
clearer
◦ Beneficiary or
servicing party
should be provided
19

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
20

Other Roles and
Accounts
◦ Support ‘Give-Ups’
and custodian
account
◦ Simpler
implementation
 Less indirection

Still Under
Discussion
21


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.
22
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)
23

Requirements
◦ Existing message sequences must follow a
Messaging Pattern




The
The
The
The
Negotiation Pattern
Distribution Pattern
Matching Pattern
Reconciliation Pattern
◦ All processes must have an ‘observable completion’
24

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
25

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
26


Messaging Gaps have been identified as
result of the analysis
Scripts for checking will be implemented to
avoid future gaps
27

Patterns
28




The
The
The
The
Negotiation Pattern
Distribution Pattern
Matching Pattern
Reconciliation Pattern
29

In many business processes a series of
exchanges are needed between the
participants before an agreement can take
place on the final outcome
Propose
Proposal
Propose
Counter
Abandon
Offer
Reject
Abandoned
Accept
Confirm
Agreement
Confirm
30

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
31


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
32

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 when action
processing begins
Time when action
is scheduled
Time when action
can be cancelled
Time when action
has already occured
Time
t0
t1
t2
33

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
34


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
Timeout 1/Allege
Request Match
Modify Match
Unmatched
Timeout 2/
Unmatched
Mismatched
Matched
atach
found
Cancel Match
35


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.
Create/Adjust
Unsubmitted
Submit
Create/Adjust
Submitted
Report
36

Gaps have been
identified to
FpML 4.5
applying the
patterns to the
existing business
processes
FpML 4.5 Message
Updated Model
Pattern
RequestTradeConfirmation
RequestTradeConfirmation
Negotiation
‘Acknowledgement’
Negotiation
RequestTradeConfirmation
Negotiation
‘Acknowledgement’
Negotiation
CancelTradeConfirmation
Negotiation
‘Acknowledgement’
Negotiation
TradeMatched
Advice
‘Acknowledgement’
Advice
TradeMismatched
Advice
ModifyTradeConfirmation
CancelTradeConfirmation
TradeMatched
TradeMismatched
Comments
New
isCorrection
set to ‘true’
New
New
New
37