Wholesale Financial Markets: Specification

Applying new message standards for the wholesale trade lifecycle based on XML available over any network can bring the following benefits to all market participants:

• Reduced operational cost by increasing the level of STP
• Improved interoperability between market participants
• Universal applicability of a global standards that incorporates the relevant data elements from the various countries/regions and products
• Efficient and effective usage of a combination of banks and other niche service providers within one interconnected, but flexible and open infrastructure that fits the overall IT strategy
• Ease and low cost due to use of any network rather than specific networks with limited access

Using unambiguous XML standards with “plug and play” interfaces can significantly reduce implementation costs. A recent study at Shell’s corporate treasury indicated that the cost of developing interfaces based on open XML standards is less than 50% of the cost of developing traditional interfaces. These costs will be even lower when plug-and-play interfaces based on open XML standards become more widely available.

Open standards can be seen as reducing the obstacles currently in place to prevent corporates accessing certain businesses in the same way as banks. For example, this may seem to facilitate some corporates being able to access the FX and money markets in much the same way as banks rather than as customers. However, open standards do not, in themselves make policy decisions about customer access they merely facilitate a variety of approaches in as efficient and flexible a manner as possible.

Given the investments that have been made in the past, careful consideration will be applied to prevent these standards becoming just another solution to be added to the portfolio, but rather they provide a merger of various existing solutions into a single new one which can be accomplished over time. The major step is for banks and corporates to start building an XML infrastructure, at first in conjunction with the current infrastructures. However, many applications are currently able to support XML protocols for open communication with other applications. Such availability of XML support makes the bottleneck, not the XML-enabling of applications. However, some systems will need review with respect to whether the required data elements are supported in the database and whether access to such data and the processing of data in conjunction with other applications is surrounded with the necessary system and business controls.

TWIST develops practical, XML-based, standards for corporate treasury and fund management operations to communicate with their banks and brokers, and with electronic trading platforms, in order to negotiate, execute, confirm and settle trades in wholesale financial market instruments, and thereby to achieve efficient, well controlled, straight through processing of these transactions.

The TWIST messages can relate to a specific trade, or can convey more general information, such as deal statements, lists of trades, settlement confirmations and standard instructions. An exchange of messages is called a conversation.

Within a conversation, messages are organised into hierarchies or trees. A conversation can employ messages that might themselves invoke further conversations about the detail of the subject at hand. For example, a trade conversation can include sub-conversations about price, credit and settlement. The message sets include, where necessary, acknowledgements, confirmations and/or rejections to reduce ambiguity and improve certainty. In addition to enabling the various parties to specify all the details of a trade or other subject, TWIST includes freeform comment messages that allow users to add background information or notes.

The message that is the top node in the hierarchy of messages relating to a particular trade is called tradeConversation. It includes identifiers for the trade and for the users involved in the conversation, and a message that defines the purpose of the conversation, which usually entails further subsets of messages. Depending on what point the trade is at in its lifecycle, the purpose of the conversation could be about pricing, credit, affirmation, confirmation, settlement or modification of the trade.

Trades can be negotiated either through pricing or order conversations. A pricingConversation enables a price requester, such as a corporate treasury or fund manager, to negotiate the price of an instrument with a provider, say a bank or broker. The conversation entails a price request, a response, and the requester’s reply – either accepting the price or rejecting it – and ending the conversation. Where a price is accepted, the provider will acknowledge the price acceptance, and confirm the deal. In some cases, the price acceptance acknowledgement message is sufficient for the provider to execute the trade. In others an execution confirmation acknowledgement is required by the sender before the provider does the deal. A message is also available for providers to cancel prices that have not yet been accepted. Each element of this pricing conversation – request, response, acceptance and so on – can generate its own subset of messages.

The price request messages include identifiers for the request and the requester. TWIST provides identifier messages in all instances where it is necessary to establish a unique ID for an element under discussion and for the parties involved. The price request conversation also includes a message describing the financial terms for the deal for which a price is requested, and optional messages for information about further actions planned for the trade, an indication of the number of providers being asked for a price, a time limit for the quote, and a facility for updating prices if they expire. A message is also available to cancel price requests.

The price response messages include a message describing the kind of instrument for which the price is offered, such as, for FX transactions, a single leg of an FX deal, an FX swap or a term deposit, and the time in seconds for which the price is valid. The provider will also indicate whether it requires an execution confirmation.

The price acceptance messages enable a requester to take a price made by a provider. If the request was for two-way prices, the requester indicates the direction of the trade. There are also messages for cancelling a request, or informing the provider that nothing has been done with the price.

In some conversations, a trade will be done on the acceptance of a price and its acknowledgement by the provider. In others, a further exchange of messages is required to confirm the execution, with full details of the trade being sent by the provider including date and time in GMT. A notExecuted message is also available where the provider declines to execute, with reasons for the denial.

Where a trade is priced using an order workflow, the orderConversation generates a set of messages to initiate an order, and for the provider to accept or reject it, and if accepting it, to give details of how it is filled.

The order request messages include the specification of the type of instrument, such as, for FX transactions, single leg or swap, or, for money market transactions, a term deposit or loan, and a description of the financial terms of the deal for which a price is requested. It might also include parameters that qualify how the order can be filled. The messages can be sent directly to the provider or to an intermediate broker. If a broker receives the message, it will include its reference and forward the message to a providing party.

The order parameter messages will specify the type of order, such as benchmark, limit or stop-loss, the expiration data and time and whether partial fills are allowed. For benchmark orders, there is a message to name the benchmark, and for limit and stop-loss orders, messages to indicate the price that will trigger the fill.

As the order is completed, the provider will send orderFillmessages to the requester with details of each partial fill. There is a specific message to indicate the last fill, and messages for the requester to acknowledge the fills as they occur, or to cancel an order at any point.

A trade conversation can include a creditConversation to determine if credit is available for a trade with a particular counterparty. The messages cover the request to check for available credit from a list of providers, the responses, the drawdown of the credit with the counterparty following the trade, and a replenish message to restore the credit position with counterparties who granted credit for the request but with whom the deal was not done.

The credit request messages include the option of suggesting a rate for the proposed trade for which credit is being checked, and a message simply to discover available credit limits with a counterparty. The basic response will be yes or no, with details of the amount of credit remaining available to the requester after applying the request (which will be negative if a limit is breached). Optional messages are also available for credit management systems that have the capability to convey information about the type of limit being reported, the original available amount and so on.

A set of tradeModification messages is available to modify a trade after it has been executed. Either side can initiate a modification conversation, using a requestModify message. A modification is typically implemented by cancelling a trade and creating a new one with the modifications. The conversation can cover closeouts of forward positions prior to maturity, with details of the expected payment to cover the cost, and the breaking of a block of trades into smaller trades.

The block messages can be used to allocate, roll forward or separate in any way a single trade into multiple trades. The most common ways of blocking a trade are by counterparty or date. The messages specify the details of the component trades, with their financial terms and information about the counterparties if they are different from the counterparty of the parent trade. Some blocks will require pricing, in which case basic pricing conversation messages are used.

Finally, a tradeConversation might include a discussion element. This allows participants to add comments to the history of the trade. A subject message enables TWIST to thread related messages together. The discussionElement messages are for ad hoc discussions around trades only, and are different from the structured conversations that TWIST supports and for which it has a separate set of messages.

For organisations wanting to exchange information about things like deal statements, lists of trades, settlement and standard settlement instruction updates rather than specific trades, TWIST provides the conversation set of messages (as opposed to tradeConversation messages). As with trade conversations, each exchange of messages includes identifiers for the particular conversation and the participants, and the possibility of adding informal comments in a freeform message.

A trade statement conversation begins with a request to a counterparty for a statement about all the trades that meet a specified filter condition such as a date range or trade status, or about a specific trade or modification that has occurred since the last exchange of messages. The response to such as request will be a list of all the required trades and their details, or error messages where trades are not found.

A confirmation conversation begins with a participant sending a requestToConfirm message with all the details of trades in question. The reply will confirm or deny each trade, either using just the trade identifiers or supplying full details of the trades.

A further set of messages is available to confirm with a counterparty the method of settling a deal. The participant specifies the collection of settlements to confirm, identifying the trades and whether the settlement is to be gross, net or multilateral. Each form of settlement has its own subset of messages. For gross settlement, messages identify the trade and payment, indicate who is the receiver and the payer, and specify whether the settlement should follow a standard settlement instruction (SSI) or give full instructions including whether the settlement is to be split into pieces.

For net settlement of a collection of payments between two parties for the same day and currency, messages specify the currency flows to be netted, the payment amount – which must equal the net amount of the trades in question – and the settlement instruction.

TWIST has also developed a set of messages which support multilateral settlement through the new CLS Bank. Such settlements must be handled by an organisation that has agreements with all the parties. The messages identify all the items for netting, with information on trade, payment and receiving party. There are no settlement instructions because the clearing agency handles this.

A conversation to inform a counterparty about standard settlement instructions starts with a notification message and is followed by one or more instructions with their identifiers. The corporate or other user specifies the currency and the activation parameters – date and scope – and a further choice of messages enables the user to specify who is to use an instruction and on what types of instrument(s) it is to be used.