Messaging Patterns

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

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

• lttradeExecutionAdvicegt ltmessageHeadergt
• lt/messageHeadergt
• ltcorrelationId correlationIdSchemehttpBANK
  gt7lt/correlationIdgt ltsequenceNo
  sequenceNoSchemehttpBANKgt1lt/sequenceNogt
• ltexecutiongt lttradegt Lots more
  here lt/tradegt lt/executiongt ltparty
  idBNKgtlt/partygt ltparty idSRVgtlt/partygt
• lt/tradeExecutionAdvicegt

8
Acknowledgements

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

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

11
Advice vs. Notification

• A true notification should be something that we
  can choose to disregard without having to inform
  anyone else

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.

13
Corrections

• Lack of consistency defining correction messages
• ltisCorrectiongt 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

ltsomeRequestgt ltmessageHeadergt Basic
message details lt/messageHeadergt
ltonBehalfOfgt ltpartyReference hrefJPM/gt
ltaccountReference hrefPORTFOLIO1/gt
lt/onBehalfOfgt Request specification
herelt/someRequestgt
16
Example

• lttradeExecutionAdvicegt ltmessageHeadergt
• lt/messageHeadergt ltisCorrectiongtfalselt/isC
  orrectiongt ltcorrelationId correlationIdSchemeh
  ttpBANKgt7lt/correlationnIdgt ltsequenceNo
  sequenceNoSchemehttpBANKgt1lt/sequenceNogt
  ltonBehalfOfgt ltpartyReference hrefBNK/gt
  lt/onBehalfOfgt ltexecutiongt lttradegt
  Lots more here lt/tradegt lt/executiongt
  ltparty idBNKgtlt/partygt ltparty
  idSRVgtlt/partygt
• lt/tradeExecutionAdvicegt

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

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.

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.

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

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

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.

37
Messaging Gaps
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

• Gaps have been identified to FpML 4.5 applying
  the patterns to the existing business processes