Messaging Patterns

Messaging Patterns

Introduction

The FpML schemas define a framework for messages of various types but it is best to think of them as ‘events’ that trigger the recipient into performing an action. Some of these ‘events’ ask for a business process to be initiated (e.g. request messages) while others distribute state information to process participants (e.g. response and notification messages).

The original message protocol designs where based on the assumption that the guaranteed asynchronous message queuing would be used by most implementations to connect the participants (such as IBM’s MQ Series, SWIFTNet, etc.) and to create processing systems with ‘Event Driven Architectures’ (EDA).

These assumptions lead to the use of patterns where some requests have no immediate response (such as ‘RequestTradeConfirmation’) which can be used to determine that the message has been processed. In this type of scenario the real business response is typically provided later by an asynchronous response.

For example, in the current confirmation protocol a request made to confirm a contract that contains unmatchable details in important deal terms would remain unmatched until the details are modified. The message flow between confirmation requester and provider would be as follows.

The ‘Confirmation Requestor’ does not receive an acknowledgement to his ‘RequestTradeConfirmation’ message because it would not tell him something that he does not already know (i.e. that his trade is pending a match). If the message contained errors or was inappropriate then an immediate error response would have been generated. No other response is possible until some other confirmation participant using the same protocol provides trade information that matches or mismatches with the original trade, or until the ‘Confirmation Provider’ decides that such information will never be forthcoming from another participant.

Of course if you do not trust your applications or middleware to provide guaranteed delivery or processing then the protocol does not provided sufficient information to allow message loss to be detected and/or corrected.

Adjusting FpML to provide additional acknowledgements is possible, as we shall see in the next sections, but it also impacts on other

An alternative to providing such acknowledgements in FpML is to generate them by encapsulating the delivery of messages in another layer of software between the application and the transport.[1]

Feedback from implementations has been that people prefer to get an immediate acknowledgement for every request to prove that the request has completed the entire ‘end-to-end’ processing. No one seems to have fully explored the possibilities of the layered approach.

Micro Level Changes

Adding Acknowledgments

Simply put this means adding messages into some of the FpML business processes to ensure that all request messages, such as ‘RequestTradeConfirmation’, have an immediate response. This will mean that all requests will now follow this pattern.

Providing each request with a more immediate and guaranteed response would allow a more synchronous style of design, such as this:

Here the requestor waits for the response before terminating its execution. This would allow an easier specification of timeouts related to request processing although as we shall see later has implications for gathering the results of long running processes, such as matching.

Simplifying Responses

As the current messaging is ‘event’ based there are often multiple response types for a given request. For example in the case of the ‘RequestTradeConfirmation’ request there would be at least five possible responses, namely:

MessageRejected – The XML message has somehow become corrupted in transit or contains a request or financial product not supported by the receiver.
RequestAccepted – The trade details do not match with any other trade description provided by the counterparty (probably because this party was the first to send them).
TradeAlreadyMatched – The request duplicates the details of a trade already known to be matched.
TradeMatched – The trade details exactly matched with an identical trade description provided earlier by the counterparty.
TradeMismatched – The confirmation was able to locate a trade description sent by the counterparty that should have matched (e.g. it contained a common unique identifier such as a MarkItWire or DTCC reference code) but differed in important trade terms.

There are several things to notice about the responses in this list

Some are error messages indicating that the requested action could not be performed (e.g. MessageRejected, TradeAlreadyMatched). These responses can be generated in immediate response to the request.
A single request can have many different types of return. Some return types could be result from different requests (e.g. RequestTradeConfirmation and ModifyTradeConfirmation can lead to a TradeMatched).
Many of the results are actually asynchronously generated matching events (e.g. TradeMatched, TradeMismatched, TradeUnmatched) rather than an acknowledgement of the last request and can be generated even if the trade state is not adjusted after the initial request (see following diagram).

The first point hints that it might be worth recognizing errors separately from normal responses. Modelling requests on programming language method calls for example might add some consistency across the model. For example if all requests follow a programming model like:

ResultType someFunctionOf (RequestType argument) throws Exception

Then their message implementation would resemble the following:

The FpML message hierarchy could be easily adjusted so that all the error messages are derived from a common exception message base class to help

The ‘ExceptionMessage’ type could be defined as follows: All existing errors can be adjusted to derive from this type rather than ‘ResponseMessage’.

The second point suggests that some simplification of result messages should be considered. Handling asynchronous events separately from responses for example so that each request type has a single response type (or an exception).

This leads on to the third point. How can we adjust the model for asynchronous event notification so that it too provides acknowledgment to the event sender. The current message flow is one-way and not acknowledged as shown below.

Should the protocol be fully bi-directional with either side being capable of initiating a message exchange? This works well with message based transports link MQ Series, FIX, SWIFT etc. but would make a WebServices implementation difficult.[2]

An alternative would be to provide a polling request to obtain the events. This style would be more suitable for client/server style transports like WebServices. For example:

Advice vs. Notification

The preceding discussion on event highlights another subtle problem in the current design of the messages. What is a notification?

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

Most of the information we distribute in FpML today as notifications we expect the receiver act upon rather than ignore, and 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.

On Behalf Of

The FpML neutral view principle when combined with some of the notifications for post-trade processes and a common third party such as a custodian results in situations where the third party can not easily tell which side of the trade he is supposed to be processing.

For example, parties A and B negotiate a trade and then send a contract execution notification to their common custodian C. The custodian may be able to figure out which side of the trade to process by means of the message sender’s identity but as a single sender identity might be used by several legally separate trading divisions within the same company group determining the correct party might require extensive organisational reference data. This approach would also fail for internal book-to-book deals where both sides would originate from the same sender.

What is needed is an explicit indication of the party for whom the trade should be processed included in every message. In the case of book-to-book trades this information should use account references to further qualify the party. For example:

<someRequest>
<messageHeader>
… Basic message details
</messageHeader>
<onBehalfOf>
<partyReference href=”JPM”/>
<accountReference href=”PORTFOLIO1”/>
</onBehalfOf>
… Request specification here
</someRequest>

Identity

Most business objects have one or more identifiers associated with them. FpML supports this in a way that gives all of them equal weight. This design choice means that when two or more identifiers are given some convention defined outside of the document must be used to determine which this the primary (e.g. the one with a previously agreed scheme URI).

The proposal to allow a single trade (or contract) identifier to be selected as the primary (for each party) clarifies the relative importance of these identifiers but the same clarity needs to be applied in other places in the schema where multiple identifiers are allowed (e.g. UnderlyingAsset, Account, etc.).

In FpML 5-0 the specification of a primary identifier should mandatory any where in the model where more that one can be given.

Trade Roles

The addition in FpML 4.2 of the trade side structure allows addition party roles to be associated with a trade. The aim was to support more complex trading situations such as ‘give-ups’ where one party leverages the credit rating to another institution to achieve a better price than they could get directly.

The TradeSide structure is used to capture the role information mixes contractual and processing information in a way that is reminiscent of a static database model such as would be found in a data warehouse.

Most of these values are only relevant to specific business processes and should be properties of the supporting messages rather than the trade as a whole. For example orderer and introducer are order/execution properties; executor/confirmer are related to execution; settler relates to settlement (currently outside the scope of FpML). The creditor and calculator roles are the only two that would be written into the generated contracts.[3]

The use of TradeSide complicates the processing of trades by introducing alternative ways of specifying trade data and makes resolving the party for a particular role a multi-stage operation.

In order to design a simpler solution to the trade role issue it will be necessary to make some changes to other FpML structures and introduce some additional business process. In particular the following schema changes will need to be made.

Separation of Party and Account
Currently accounts are specified within a party definition and the relationship between the two objects depends on the elements present. To simplify the structure and make the relationships clearer the account structure should be moved outside of Party and given a mandatory reference to its beneficiary and an optional reference to its servicer (this is the reverse of the current situation).

Book-to-Book Trades
The current FpML model assumes that the parties used as buyer and seller, or payer and receiver will be different. An internal trade can only be written (in a meaningful way) if two party definitions are created for the same logical party. If the buyer/seller and payer/receiver references are extended to include an option account reference then a single party can be on both sides of the trade and the accounts used to differentiate for settlement.

Other Party Roles and Accounts
Trades that are being negotiated with a view to being ‘given up’ or where additional related party accounts are needed (for example custodian accounts) need some where to record this information in a way allows it to be specified on a party by party basis but without the levels of indirection created by the TradeSide structure. Upon review the PartyTradeInformation area of the trade header may be the best new location for this reside.

I’ve only included the roles that we have a proven need for in the current message usage. Others can be added it needed.

Using these structures the only difference in the definition of a trade negotiated directly and one that will be given up would be the presence of a definition of the prime broker in the trade header.

<trade>
<tradeHeader>
<partyTradeIdentifier>
<partyReference href=”THEFUND”/>
<tradeId>FUND1234</tradeId>
</partyTradeIdentifier>
<partyTradeInformation>
<partyReference href=”THEFUND”/>
<primeBroker>
<partyReference href=”THEBROKER”/>
</primeBroker>
</partyTradeInformation>
</tradeHeader>
.. product ..
</trade>

This is only a partial solution for give-ups covering only the data side of the definition. Additional messages will be needed as well to completely describe the process electronically.

Correlation

Many financial business processes are long running and are comprised of many message exchanges occurring over a period of many minutes, hours or days. In order to correctly execute messages communicating parties need to establish a common identifier that is to identify the context in which the messages will be interpreted.

In FpML 4.0 it was envisaged that the conversation identifier would fulfil this role but in practice this has not proven to be sufficient. In FpML 4.2 another attempt was made to clarify the situation through the addition of the ‘Event’ type and its collection of ‘eventIds’ but this too has problems, namely:

The collections of ‘eventId’ elements is both optional and multiple so a message creator is not forced either to provide one or if several are present to indicate which is the main one.
Messages defined before 4.2 do not use the event base class so do not include ‘eventId’ element.
The content model for several notation messages is represented by the same Novation type which is derived from the Event type. Not all of the data within the Novation type is used in all the messages but as they use the same definition this cannot be enforced in the schema and has to be validated post-parsing.

FpML needs a simple and consistent approach to correlation that can be applied across all messages to make the intentions of all parties clear and which allows message content to be strictly defined (as validation against the schema is the easiest way to ensure all implementers meet a standard minimum level of error detection).[4]

The approach should also avoid using business identifiers for correlation as they are often not as static or unique as they should be (e.g. a trade send for matching is subsequently discovered to have been given the wrong identifier, etc.). The key process participant (e.g. the service provider) should allocate unique one-time identifiers for each process instance it is managing (e.g. like a help desk ticket). Note that this means it may be the response message that establishes the long term correlation identifier and not the initiating request. For example a ‘RequestTradeConfirmation’ should not contain a correlation identifier because the ‘event’ does not exist until the request is accepted.

The current ‘Event’ structure is close to what is required but needs to be made more prescriptive. Four types of event need to supported, namely:

Event initiating messages – a message that causes an event (e.g. process instance) to be started by the receiver if the request is accepted. This message should not define a correlating event identifier.
Event defining messages – a message that describes the correlation identifier to be used by future messages. (e.g. <eventId eventIdScheme=”…”>1234</eventId>)
Event referencing messages – a message that explicitly refers to a previously defined correlation event identifier. (e.g. <eventReference eventIdScheme=”…”>1234</eventReference>
Event defining or referencing messages – in an ideal world all trades would pass through the STP process and this would not be needed but as some trades will bypass some stages manually we need to be able to establish correlating identifiers in some message that should only reference them.

A standard EventId type could be used to define more precisely named elements in the messages (with model groups for re-use between messages) for example:

This regime allows us to make some other messaging clarifications, namely:

Every message will have a unique message identifier.
The ‘inReplyTo’ element of a response message (or exception) correlates with the ‘messageId’ of the associated request.
The conversationId become as candidate for removal.
Retransmission of a message for technical reasons (e.g. the last transmission of the request was not acknowledged or rejected) does not change the message identifier.
Replication of a message for business reasons (e.g. sending data that has been previously acknowledged) generates a new message identifier.
The response to a retransmitted request message should be identical to the original request.[5]
At the start of a long running process the managing participant a must create a unique one-time identifier for each process instance and distribute it to the other messaging party.
Every subsequent message sent by the requestor must contain the process identifier.
Messages may contain reference to other business process instances providing their role is clear and unambiguous (e.g. an order MAY reference a previous quotation).

Macro Level Changes

Probably the biggest mistake in the current messaging specification is the way in which some of the interactions are described for more than two participants.[6] For example the trade confirmation process diagrams show interactions with a separate matching engine but this is only one possible system architecture and ultimately what us really important is the protocol between the confirmation requester and the confirmation provider.