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

Exceptions could potentially be further refined into sub-categories, for example by process area as shown below.

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.

Error Reporting

Participants within FpML are divided on how best to handle errors. The approach taken to date has been to create strictly typed messages that indicate the major types problem detectable within the business processes. The alternative approach favoured by some is to use a single generic message into which details of the failure are placed using a error codes and a looser content model.

The attraction of the first approach is its strict control over content. Any implementer of the specification is forced to provide the same minimum data content for any error and can extend the type to provide additional propriety information if they wish. If exceptions are derived from types in a systematic fashion then tools can use knowledge of the inheritance hierarchy to help process them. The downside to this approach is that the standard will contain many message types for errors.

The second approach results in far fewer messages in the schema but relies on implementers to follow common conventions when building messages to ensure than they contain the same information. When this approach has been used in other standards messages they often fail to be correctly constructed (e.g. SWIFT FIN and FIX implementations must often handle different flavours provided by some counterparties). Often required values are omitted or features such as narrative text fields are used to contain data that should have been explicitly represented elsewhere.

The most successful standards for encouraging interoperability often provide the least ‘wriggle room’.

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.[3] 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.

In any revision to the business process they should all be described from the point of view of only two participants. The novation process in particular is especially complex because all the participants must take to each other directly rather than through a central controller.

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 following diagram illustrates the states in a negotiation model and the valid transitions between them.

The key points in a negotiation are:

·  The proposing party starts the negotiation and decides when it 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 process requires active participation for a successful end state to be reached. Potentially a participant could stop generating responses so an implementation would need to specify a timeout period after which the negotiation would be considered automatically abandoned.

The FpML specification does not prevent parties initiating multiple negotiations over the same transaction simultaneously (e.g. to compare terms for full vs. a partial termination or for different notional amounts).

The Distribution Pattern

In many of the current business 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 as the informer would normally like to know that the informed party has received and understood the information.

The current FpML ‘contract notification’ messages perform this role but are not integrated with the business processes that would generate them in fully STP world. They also currently lack the capability of sending a response that makes it impossible to signal automatically that an action cannot be accepted.

For example if at time t0 a contract notification is sent indicating that some action (e.g. a trade increase) is to be performed at time t2 then up until time t1 when the informed party begins processing the increase (e.g. issuing settlement instructions, etc) the original notification can easily be changed or cancelled because it has had no external effect.

When we are in the ‘grey-area’ between time t1 and t2 modifying the action becomes more difficult and some parties will have incurred financial costs. Any attempt to modify the original notification should be refused to force the informer to issue a ‘compensating transaction’ that will correct the situation. The problem is that the informer does not know when the informed has entered the ‘grey-area’ unless the notification can generate a response. Currently notifications that cannot be accepted must be handled as a manual exception.

Correcting Mistakes

When dealing with distribution we must take into account that sometimes an advice will be sent containing the wrong information, especially when the preceding process was not performed electronically (e.g. by phone or using a non-FpML based technology). There are two different cases that need to be considered.

·  The message details are sent to entirely the wrong party.

·  The message is sent to right party but the details are incorrect.

To these two cases the distribution messages need to support retraction and correction. As the informer would like to know if his corrective action has been accepted these messages should also follow the advice pattern as shown below.

Again the ‘grey-area’ means that requests to modify or cancel a previously sent notification message cannot be accepted because settlement based on the incorrect details has already begun.

The Matching Pattern

The trade confirmation process involves each participant sending a description of the trade details to someone who attempts to pair up matching descriptions. The current specification divides the task into two roles a ‘confirmation’ provider that manages the overall process of confirming and a ‘matching provider’ that performs the technical comparison. In retrospect this is overly complicated and only the interactions with only the ‘confirmation provider’ should be documented (how the matching is actually performed is an implementation detail).

The following diagram illustrates the states and transitions within a confirmation engine with respect to a single trade.

When a trade is sent for confirmation it is initially in an ‘unmatched’ state and here it will remain until the confirmation is cancelled, a match or mismatch is found, or the trade is returned unmatched (because no matching trade has found within a defined time period).

A shorter timeout period is needed manage the process of alleging trades against other parties. In all confirmations one party will always provide his copy of the trade details before the other. The receipt of an allegation will probably initiate a manual problem determination. Delaying the transmission gives time for the trade to flow through the other sides STP system and should minimises the number of allegations to be investigated.