Proposals to change FpML Messaging

` ` ` ` ` ` ` ` `

Correlation Acknowledgements Exception modelling Advice vs. Notification Corrections On behalf of Trade Roles Trade vs. Contract Messaging Gaps

Confusion in the current model on how to identify the context in which the messages will be interpreted
conversationId
x Optional x Not well-defined

eventId
x Optional x Not in all messages (before 4.2) x Forces common content for all messages

correlationId
Applied to all messages Allocated by the initiator of the business process

` `

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

sequenceNo
To define a sequence number Although sequence numbers should be consistently increasing in value they do not have to form a gapless sequence

<tradeExecutionAdvice> <messageHeader> </messageHeader> <correlationId correlationIdScheme=httpBANK>7</correlationId> <sequenceNo sequenceNoScheme=httpBANK>1</sequenceNo> <execution> <trade> Lots more here </trade> </execution> <party id=BNK></party> <party id=SRV></party> </tradeExecutionAdvice>

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

Requestor

Responder

Request

Response

Worth recognizing errors separately from normal responses Add consistency across exceptions

All existing errors can be adjusted to derive from the ExceptionMessage type rather than ResponseMessage
Document

Message

Request Message

Response Message

Notification

Message

xception 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=httpBANK>7</correlationnId> <sequenceNo sequenceNoScheme=httpBANK>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

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

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
x Difficulty to represent internal trades

New optional account reference

x Single party in both sides is possible x Info for settlement

20

Other Roles and Accounts

Support Give-Ups and custodian account Simpler implementation
x 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
x x x x The Negotiation Pattern The Distribution Pattern The Matching Pattern The 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 Negotiation Pattern The Distribution Pattern The Matching Pattern The 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

Pr e

Proposal

Propose

Counter Abandon Offer Abandoned

Reject

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.

Inf r ing P rty

Inf r

A knowl ge or Ex eption




32

Inf r

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.
x Any attempt to modify the original notification should be refused to force the informer to issue a compensating transaction x The informer does not know when the informed has entered the grey-area unless the notification can generate a response.
Tim r c ssi cti i s Tim is sc cti l

Tim c

cti c ll

Tim s lr

cti cc r Tim

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

  
Infor ing P rty Infor ed

A knowledge or Ex eption

Acknowledge or Exception

 



Infor ing P rty

Infor ed

etr

orrect

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

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.
&"
reate/Adj t

Unsubmitted

Submit reate/Adjust

eport

$ #"

itted

% '

36

FpML 4.5 Message

Updated Model RequestTradeConfirmation c no ledgement

Pattern Negotiation Negotiation

Comments

Acknowledgement

rade atc ed

rade atc ed

Acknowledgement

rade ismatc ed

rade ismatc ed

ancel rade onfirmation

ancel rade onfirmation

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

RequestTradeConfirmation

Ne

ModifyTradeConfirmation

RequestTradeConfirmation Acknowledgement

Negotiation Negotiation

isCorrection set to true New

Negotiation

Negotiation

New

Ad ice

Ad ice

New

Ad ice

37