Wholesale Financial Markets: Business Process

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.

The Principle of 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.

The Pricing Conversation

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.

The Order Conversation

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.

The Credit Conversation

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.

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.

Statements

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.

Examples of Business Models Supported by the Standard

TWIST promotes open standards that can be used by any service provider to ensure an effective and efficient process. TWIST has identified a number of different scenarios that can be used which all focus on the processes used to create, price, confirm, modify and settle a FX trade.

Scenario 1: Bilateral Trading Model

In this scenario, the price taker creates a trade and then requests a quote from a price maker. The price maker supplies the quote, which is accepted by the taker. With an executed trade the next step in the process is confirmation. Both parties can send the other a copy and confirm or a confirmation service can be used. If modifications to the original trade are required after confirmation, then a separate negotiation is required. Typically this results in a new trade, which replaces the old. Finally both parties review trades on a regular basis for reconciliation or other control processes. Each party can maintain their own view or a central service could provide a common view.

Scenario 2: Many Price Makers for One Price Request

In this scenario, the price taker sees no difference from Scenario 1 except that when requesting a quote the taker selects multiple price makers. The trading service breaks this request into separate requests for as many price makers as were selected. The price makers submit their quotes and the service presents these back to the taker who can choose a quote. The losing price maker will receive a “not done” message. Confirmation, updating and reporting proceed as in the simple bilateral case.

Scenario 3: Price Makers Presents Executable Prices to a Service Which Distributes to Takers for Execution

In this scenario the process begins with the price maker presenting executable prices to the price taker. In other words this diagram reads from the right to the left. In this environment the taker simply ‘hits’ a price to complete a deal. Details of the trade must still be completed as in the other scenarios and the post execution steps proceed as in the bilateral scenario once the trade parties are identified.