3.1.1 Why Business Messaging?

Increased efficiency in financial markets can only be achieved through greater automation of transaction processing and use of electronic messaging (e.g. the exchange of information directly between computer systems with as little human interaction as possible). In order to achieve this all the parties involved in such communications must agree on four things, namely:

• Representation

  There must be a common representation of a transaction, product or other reference data item that is accepted by all the parties.

  The core FpML grammar defines a standard vocabulary for derivative based transactions and products that can form the basis of a messaging standard. As new messaging applications are considered the scope of the core grammar will need to expand to encompass the additional types of data referenced in these messages.

• Semantics

  All the parties must have the same interpretation of the information expressed by the representation.

  The work of the validation working group provides a set of rules to ensure that a product definition conforms to the market definition for that product. The FpML rule set will expand and evolve over time as new financial products and message types are added to the grammar.

• Business Process

  All the parties must follow the same business processes and respond appropriately to any communication they receive.

  To support business process the messaging working group has extended the core FpML grammar to add a framework for defining messages and their content. This section describes some business processes and shows how they could be implemented as message exchanges.

• Transport

  The parties must agree on the communications transport used to interconnect their businesses.

  FpML does not endorse any particular messaging transport for communication. The choice of transport is left to the implementer although in practice we expect only a few to be found suitable.

Disagreement over the first three of these features will mean that FpML users will potentially have to implement, maintain and support different software systems for each FpML aware service or application that they use. Supporting multiple communications transports is typically not that difficult although it does incur additional operations costs.

3.1.2 Design Assumptions

In order to create the messages and business processes described in this document some design assumptions had to be made, principally:

• Throughout this document we have assumed that message exchanges will be carried by an asynchronous passing of messages over a highly assured transport, such is provided by a messaging queuing system. This form of transport is commonly used today in the finance industry (e.g. AMQP, Apache QPid, FIX engines, MQSeries, MSMQ, RabbitMQ, SwiftNet Interact 'Store and Forward', etc.).

  One important consequence of this decision is that error cases related to non-delivery do not have to be considered (e.g. once accepted a guaranteed messaging queuing system WILL ALWAYS deliver a message) although the 'freshness' of the message may need to be considered (e.g. has the message been stuck in a queue waiting to be delivered for a long period of time). Similarly message queuing system can normally eliminate duplicate messages so these are not considered either.

• There is no requirement for message sequence to be preserved over the message transport. Message sequence must not be expected to be repeatable nor predictable.

  In practise enterprise message buses cannot be expected to halt the enterprise to preserver sequence. Hence this is not a requirement of FpML.

• Some of the business processes are 'long-running' in that once initiated they may remain active for a considerable time before completing (e.g. a request to confirm a trade may take many hours as it is dependent on the time of arrival of the matching trade). During this time the process may generate periodic notifications to the originator of the request and/or other parties. Such notifications will appear in the message stream set to a participant intermixed between other response messages.

  An implication of such 'long-running' transactions is that the 'service provider' will contain a complex 'state'. The service should make suitable provisions to persistently record its state so that in the event of a software or hardware failure it can recover transparently without its clients having to resend any information.

• All business process definitions must have an observable completion. The set of messages defining a business process needs to be complete. In addition, timeouts must be defined if necessary.

Implementers attempting to construct software based on these protocols using a non queuing transport (e.g. WebServices, DCOM, CORBA) will need to implement a reliable message layer to encapsulate the current message sequences (e.g. a get/put message interface using sequence numbers to detect lost or duplicated messages and positive/negative acknowledgments). The W3C site contains links to proposals for such extensions for use with WebServices.

3.1.3 Styles of Messaging

In general computer systems commonly use two styles of messaging to exchange information between each other, namely:

• Request/Response

  A style of exchange in which one system sends a message to the other to asking it to perform some function, the result of which is encapsulated in an appropriate response and returned.

• Notification

  A style of exchange in which a system sends a message describing a business event that has occurred and may be of interest to others.

The receipt of either kind of message may cause additional messages to be generated and sent as part of the processing to obtain information from other systems or to inform them of the business event underway.

3.1.4 Transport Independence

In general, four layers of specification are contained in a XML Standard. A multi-layer approach allows implementers to choose the most appropriate technology for a given situation. It allows development and modifications within one layer without affecting or requiring changes to the others..

From the top down, the four layers are:

3.1.5 Control Over Content

The design of a grammar must strike a balance between the degree of flexibility it allows and the complexity of its validation. An overly lax grammar allows the construction of documents that, whilst syntactically correct, may have no valid business interpretation. On the other hand a very rigid grammar may require many more grammatical productions in order to enumerate only the valid combinations.

In general it makes sense for a grammar to be strict when it can be achieved easily and without too much additional definition, and lax where flexibility is required (e.g. for proprietary extensions, etc.). In the case of the message framework the grammar provides a mechanism for ensuring that messages have the correct content that applies to them.

3.1.6 Identification of Purpose

The receiver of a message needs to be able to determine the function that the message is invoking. In XML there are three different techniques that can be used for indicating the purpose of a message.

The FpML 5.0 message framework is based on element naming (option 2 - By Element Name). Below is a short explanation of the three techniques:

<?xml version="1.0"?>

<FpML version="4-0"
 xmlns="http://www.fpml.org/2002/FpML-4-0-TradeConfirmationRequest">
  <header>
    ... Message header
  </header>
  ... Business data
</FpML>

<?xml version="1.0"?>

					<tradeConfirmationRequest fpmlVersion="5-0" xmlns="http://www.fpml.org/2007/FpML-5-0/confirmation">
  <header>
    ... Message header
  </header>
    ... Business data
</tradeConfirmationRequest>

<?xml version="1.0"?>

<FpML version="4-0" xmlns="http://www.fpml.org/2002/FpML-4-0"
      xsi:type="TradeConfirmationRequest">
  <header>
    ... Message header
  </header>
  ... Business data
</FpML>

3.1.7 Representing Internal Trades

The focus of FpML to date has been on the focus description of trades for B2B purposes. At the same time many of the existing implementations have been for internal trade exchanges between systems.

Extending FpML to handle internal trade information entails adding additional elements to the current schema to hold the values needed to categorize a trade for internal purposes. There are several ways this information could be added to the schema (e.g. optional elements, alternative inheritance structures, inheritance by restriction) each with its own properties in terms of ease of validation or affects on document style.

The FpML coordination committee is currently considering the types of information that would be useful to add for internal processing (i.e. management, risk and P&L reports, etc.) and the most appropriate location within the schema to place it. These enhancements will be included in a future release of FpML but in the mean time the FpML 2.0 Architecture specification contains examples of how bespoke extensions can be made to achieve this with the FpML 4.0 schema.

3.1.8 Sequence Diagram

A UML diagram that defines information flows. It focuses on the temporal order of the messages. Business Analysts can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact.

At the top of each diagram we see the names of actors or business objects involved in the process we want to describe. In the diagram above, Confirmation Requester and Confirmation Provider are examples of actors involved in the confirmation process.

The rectangles represent the systems involved in the process, e.g. Trading System, Confirmation System, and Matching System. However, in some other versions of sequence diagrams, the rectangles represent the actors or business objects.

Usually the actor or business object on the left side starts the interaction. Descending from each object is a line known as the “lifeline”. These lines define the time axis of the diagram. By convention, time proceeds in a downward direction. This practice is used in the FpML documentation.

The arrows between the lifelines represent messages being sent between the actors. For example, in the diagram above, RequestTradeConfirmation and TradeAlreadySubmitted are examples of messages being sent between the Confirmation Requester and the Confirmation Provider.

The white narrow rectangles that the arrows terminate on are called “activations”. For example, the rectangles between the RequestTradeConfirmation and TradeAlreadySubmitted messages in the diagram above are activations. They show the duration of the execution of a method or action in response to a message.

If you need more information regarding sequence or other UML diagrams, you can easily find UML diagram tools and tutorials by searching on the Internet.

3.2 The Message Framework

3.2.1 The Base Document

The XML schema for FpML 4.0 defines the type of the root FpML element to be 'Document', an abstract type with an empty content model save only for the standard FpML version.

The Document type serves as the base type in an inheritance scheme that provides the content model definitions for actual message types.

3.2.1.1 Data Documents

The DataDocument type provides the same content model as the pre XML schema version of FpML allowing the construction of documents that contain only product definitions.

To make an FpML 3.0 DTD based document compatible with the FpML 4.0 schema as a DataDocument a number of changes are required to the instance document, namely:

• The <!DOCTYPE> reference must be removed from the document.
• Where the <FpML> element defines a non-standard or institution specific default scheme attribute value it must be propagated the scheme attribute on all the appropriate elements.
• A reference to the FpML schema as the default namespace must be added.
• A reference to the W3C XML schema instance schema must be added and assigned to a namespace (e.g. 'xs' or 'xsi').
• A reference to the W3C XML Digital Signature schema must be added and assigned to a namespace (e.g. 'dsig').
• The type of the <FpML> element must be set to 'DataDocument'.
• A schemaLocation attribute may be added to the <FpML> element to hint at the location of the schema for XML tools that do not perform full 'entity resolving'.

3.2.2 The Base Message

The core definitions within the schema establish a set of abstract base classes, 'Message' , 'MessageHeader' and a model group called 'MessageHeader.model' from which all the other definitions are composed.

A specific type of message is the Notification Message; this demonstrates how the Message Header is included in the message:

The message header used xsd:restriction in previous versions in order to restrict the content model for requests, responses, and notifications. But tools issues with xsd:restriction made the Architecture Working Group to change the architecture of the message header using model groups and xsd:extension instead of xsd:restriction.

The following XML schema fragment shows how these types and group are defined.

 <xsd:complexType name="Message" abstract="true">
	<xsd:complexContent>
		<xsd:extension base="Document"/>
	</xsd:complexContent>
</xsd:complexType>

  <xsd:complexType name="MessageHeader" abstract="true">	
	<xsd:sequence>
		<xsd:element name="conversationId" type="ConversationId" minOccurs="0"/>		
		<xsd:element name="messageId" type="MessageId"/>	
	</xsd:sequence>
</xsd:complexType>
<xsd:group name="MessageHeader.model">
	<xsd:sequence>
		<xsd:element name="sentBy" type="MessageAddress"/>
		<xsd:element name="sendTo" type="MessageAddress" minOccurs="0" 
maxOccurs="unbounded"/>
		<xsd:element name="copyTo" type="MessageAddress" minOccurs="0" 
maxOccurs="unbounded"/>
		<xsd:element name="creationTimestamp" type="xsd:dateTime"/>
		<xsd:element name="expiryTimestamp" type="xsd:dateTime" minOccurs="0"/>
		<xsd:element name="partyMessageInformation" type="PartyMessageInformation" 
minOccurs="0" maxOccurs="unbounded"/>
		<xsd:element ref="dsig:Signature" minOccurs="0" maxOccurs="unbounded"/>
	</xsd:sequence>
</xsd:group>

The content of Requests, Responses, and Notifications Message Headers differ in the inReplyTo element so it is not included in the model group. Each specific type would control the existance and cardinality of the inReplyTo element. The role of each element is given below.

• conversationId allows a message sender to create a common context for a number of separate message exchanges.
• messageId contains the senders unique identifier for a message.
• inReplyTo contains the unique identifier for the request message that is being responded to.
• sentBy identifies the system or party sending a message.
• sendTo identifies the systems or parties who will receive a message and should act upon it.
• copyTo identities other systems or parties who will receive a message but who do not have to act upon it.
• creationTimestamp describes the time when the sender created the message.
• expiryTimestamp defines a time after which the sender will consider the message expired.
• dsig:Signature allows the inclusion of W3C digital signatures within the message.

The validation element in the Message type contains the URI for a set of additional validation rules to be applied to the document during processing.

3.2.3 Requests, Responses and Notifications

The following image shows the construction of just one message style type, as with in the exception of the type of the header element, they are all the same.

<xsd:complexType name="RequestMessage" abstract="true">
	<xsd:complexContent>
		<xsd:extension base="Message">
			<xsd:sequence>
				<xsd:element name="header" type="RequestMessageHeader"/>
				<xsd:group ref="Validation.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="RequestMessageHeader">
	<xsd:complexContent>
		<xsd:extension base="MessageHeader">
			<xsd:sequence>
				<xsd:group ref="MessageHeader.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="ResponseMessage" abstract="true">
	<xsd:complexContent>
		<xsd:extension base="Message">
			<xsd:sequence>
				<xsd:element name="header" type="ResponseMessageHeader"/>
				<xsd:group ref="Validation.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="ResponseMessageHeader">
	<xsd:complexContent>
		<xsd:extension base="MessageHeader">
			<xsd:sequence>
				<xsd:element name="inReplyTo" type="MessageId"/>
				<xsd:group ref="MessageHeader.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="NotificationMessage" abstract="true">
	<xsd:complexContent>
		<xsd:extension base="Message">
			<xsd:sequence>
				<xsd:element name="header" type="NotificationMessageHeader"/>
				<xsd:group ref="Validation.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="NotificationMessageHeader">
	<xsd:complexContent>
		<xsd:extension base="MessageHeader">
			<xsd:sequence>
				<xsd:element name="inReplyTo" type="MessageId" minOccurs="0"/>
				<xsd:group ref="MessageHeader.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

3.2.4 Error Handling

If a message cannot be processed for some technical reason such as: it has become corrupted, is not XML or is not a valid FpML message, then the receiver returns a 'MessageRejected' message to the sender. Usually the message will require manual intervention to diagnose and solve any problems. Such rejections will not be show on any of the diagrams in this paper.

If the message cannot be processed because the request is invalid, given the state of the data to which it applies, then an appropriate business level notification is returned to the sender (e.g. 'TradeNotFound', 'TradeAlreadyMatched', etc.) which in turn could be used to invoke either an automatic recovery or a manual intervention.

The design of the rejection message allows for the inclusion of multiple computer readable error descriptions. Each error is described by a collection of elements with the following interpretation:

• The reasonCode element contains a numeric code (taken from a standard list) which outlines the kind of error detected.

• The location element contains either a line and column number (separated by a comma) or an XPath expression. The value of the locationType attribute defines which type of location has been given. It may take the values 'lexical' or 'xpath'.

• The description element contains human readable text detailing the error.

• If the error is the result of a violation of a validation rule then the element validationRuleId contains the rule's identifier (e.g. 'ird-1').

• The additionalData element may contain extra information useful in diagnosing the reason for failure.

Another additionalData element is associated with the MessageRejected message after the error list to allow the source for the failed XML document to be returned. A CDATA section must be placed around the source message to prevent its interpretation as XML content. The following diagram shows the design for the complete message.

In order to encapsulate one XML message within another the addition data section would have to use an XML CDATA encoding to prevent the parser from attempting to process the contents.

Message rejections may use any of the following list of error codes to indicate the reason for failure. Institutions may define their own additional error codes in the numeric range provided for user errors.

Level 100: Message transport and delivery problems

• 100: Default transport error code
• 101: Transport unavailable
• 102: Unknown recipient/destination
• 103: Delivered to wrong recipient
• 104: Timeout - message delivered past expiration
• 105: This type of message not accepted on this transport
• 106: Message generation problem (e.g. data conversion)
• 110: Message corrupted (e.g. CRC failure)
• 111: Message text doesn't match digital signature hash

Level 200: Message Integrity and Processing problems

• 200: Default message processing error code
• 201: Lexical problem - not well-formed XML
• 202: Unsupported character set
• 203: Empty or missing content
• 204: Content too large
• 210: System unavailable
• 211: Message component text doesn't match digital signature hash

Level 300: Message Validation Problems

• 300: Default validation error code
• 301: Unknown or unsupported DTD/Schema
• 302: Unsupported FpML version
• 303: Invalid FpML message - message doesn't validate w.r.t. specified DTD/schema
• 304: Validation failure - unsupported message type
• 305: Validation failure - mandatory FpML rule (a rule we say must always be followed)
• 306: Validation failure - master agreement rule (a rule 2 parties agree to follow)
• 307: Validation failure - business policy (a rule that only the recipient has)
• 308: Validation failure - unsupported product/asset
• 310: Signature required - message content must be signed
• 311: Signature not accepted - problem with message signer (cert revoked, unacceptable principal, etc.)

Level 400: Business Process/Workflow Problems

• 400: Default business process error code
• 401: Don't know - unrecognized trade
• 402: Suitability - trade can't be done for client or dealer suitability reasons
• 403: Credit - trade can't be done for credit reasons
• 404: Not interested - recipient chooses not to respond
• 410: Message arrived too late - e.g. trade no longer exists
• 411: Message expired - message arrived on time, but a response was not generated in time

Level 500: User Defined

3.3 The Pre-Trade Business Processes

3.3.1 B2B Request for Quote

This section outlines a process for requesting and obtaining a quote for a trade prior to entering into a full contractual trade. The processes shown are based on those in use today in markets that already have an established electronic market.

Within this section well shall refer to two types of market participant, namely:

• Market Makers

  Dealers who will typically provide either a one or two way price on a given financial instrument.

• Market Takers

  Traders who will typically request and subsequently trade on prices provided by market makers.

A request for quote process could be conducted directly between a market maker and a market taker (e.g. Citigroup's 'CitiFx FX Benchmark' service) or more commonly through an electronic exchange or trading portal where several market makers may quote on the same request.

3.3.1.1 Product Specification for RFQ

The specification of products in request for quote messages is different than for those in post trade messages. The product may be more ambiguous (e.g. it may not specify whether it is a buy or sell) and irrelevant settlement specific data can be omitted.

In FpML version 5.x, this is supported by providing a different "view" of products that makes many of the fields optional. This allows an implementer to fill in only those elements that are required for the specific process.

3.3.1.1.1 Bilateral Request for Quote

This section describes the follow of messages required in a bilateral exchange directly between a market maker and a market maker. It is assumed that market maker operates two systems to support his trading business: one to manage his communication with market takers (the quotation system) and one to record transactions (the trading system). The features of these two logical systems could reside in a single physical implementation.

The following diagram shows the sequence of message exchanges (including an additional flow for a quote update) under normal operation.

The role of each of the messages is as follows:

• The market taker sends the quotation system a RequestQuote message describing the properties of the transaction in which he is interested in. The quotation system forwards the message on to the market maker for attention. The RequestQuote message uses the QuotableProduct definition to allow the product to be loosely defined.

Note that the message allows more than one product be to included to allow a number of quotes to be request simultaneously.

• The market determines either a one-way or two-way price for the product and the left of time for which that quote will be honored and returns it to the market taker via the quotation system. The market marker can quote for a subset of the requested products (or none of them by not responding at all). (Please note that the FpML Business Process working group is considering whether to change the name of the response message to something more generic, such as "quotePrice"; this may be implemented in a future working draft of 5.0).

• The market taker accepts the quote and informs the quotation system of which quote (if the price was two-way) was taken by returning a fully formed trade (possibly containing the market takers settlement information). The quotation system forwards the acceptance to the trading system.

• The quotation system should ensure that details of the trade within the QuoteAcceptance match the quotation provided earlier and that the quote is still valid.

• When the trading system confirms its acceptance of the transaction by returning it in a QuoteAcceptanceConfirmed message (possibly after adding its own settlement information) the quotation system can issue TradeAffirmations to inform each party that the trade is complete.

• Finally both parties confirm their acceptance of the TradeAffirmation to the quotation system to allow it to record the successful end of the transaction. (The TradeAffirmation and TradeAffirmed messages are described later)

The role of the quotation system in the above processing is to ensure that both market makers and market takers are treated fairly during the quotation process, by maintaining an audit record of message from both parties in order of arrival.

In practice the negotiation of a rate or price for a transaction may require more message exchanges than shown in the last example and there are a number of different outcomes that can occur, namely:

• The market taker may choose not to act on the quote, leaving it instead to expire at the time designated by the market maker.

• There are no messages to inform parties of the expiration of a quote, rather it is discovered by exception when a stale quote is acted upon (shown later).

• The market maker may choose to refine a previously made quote to reflect a change in market conditions. A marker taker may be tempted to trade on the new quote (as shown in the following diagram) or may leave it to expire or be cancelled.

• The market taker may re-request a quote for the same product for which he requested an earlier quotation. If the earlier quotation is still active then the request could be ignored or an update sent to original request. If the quote has expired then the normal quotation process is repeated.

• A market taker may attempt to take up a quotation after it has become expired. This could be accidental or caused through synchronization issues between the systems (e.g. differences between system clocks, message delays or processing order).

3.4 B2B General Processes

3.4.1 Trade Status Enquiry

At a number of points in the confirmation process it is possible that one or the other or both parties to a transaction received an unexpected error message from the other or the central service.

In order to determine the correct course of action to recover from such an error the participants need to determine the perceived state of their transaction within the other party's systems. This indicates that a simple status enquiry operation would be required to recover the necessary information.

For efficiency the trade status enquiry message should allow more than one transaction to be checked at a time (e.g. all outstanding unmatched trades, etc.). Its content model is as follows:

The response message returns each identifier with a suitable status code value (i.e. unmatched, matched, confirmed, not known, etc.).