Chapter 9

Straight-Through-Processing

9.1 INTRODUCTION

Straight-through-processing (STP) is a set of working practices and systems that enable transactions to move seamlessly through the processing cycle, without manual intervention or redundant handling. Transactions in this context include not only orders and trades, but also the position-related activities such as corporate actions, accruals and mark-to-market processes, which are described in Chapter 23.

The key principles of STP are the following:

1. The transaction is entered into the firm’s systems only once – it should never have to be rekeyed into another of the firm’s systems.

2. As most investment firms need to record the transaction into more than one system, there need to be automated interfaces between all systems that need to store records of the order or trade.

3. Transaction processing should consist of a set of logical stages, each one being dependent on the satisfactory conclusion of the previous stage. No stage should commence until the previous stage has completed successfully.

4. Clerical intervention should be avoided as far as possible, but clerical staff should be enabled to manage by exception – that is to say that if one of the processing stages fails to complete satisfactorily, the fact that this has happened should be presented to skilled staff in a form in which they can deal with the exception in the most efficient manner.

5. Principles 1 to 4 above apply not just within the firm but also between the various firms involved in the transaction.

9.1.1 Client orders and their contents

As far as trades in financial instruments and their settlement are concerned, STP flow always starts with the placing of an order. An order is an instruction to:

  • Buy or sell:
  • A specific quantity or money value of a specific financial instrument such as an equity, bond, currency or derivative …

… as well as a number of instructions relating to the price of that instrument, such as:

  • “At best” or “at market” – meaning buy or sell at the best available price the member firm can obtain
  • Limit – where a price is specified, meaning:

    – If selling, do not sell for a price lower than the limit price

    – If buying, do not pay more than the limit price

  • Stop loss – sell if and when the market price falls to this level …

… as well as a number of time related features such as:

  • “Good till cancelled” or “open order” – there is no time limit on this order
  • Expiry date – if the order cannot be filled by this date then it should be treated as cancelled
  • “Fill or kill” – if the order is, say, to buy 10 000 shares of ABC plc, then either complete the order in full or reject it if the member firm can only obtain, say, 5000 shares.

9.1.2 Buy-side and sell-side connectivity

Orders may be placed by the buy-side (and therefore received at the sell-side) by a number of methods, including:

  • By telephone or fax
  • By entering the order details into a secure web page provided by the sell-side firm
  • By sending the sell-side firm a SWIFT message. SWIFT is covered more fully in section 11.1.
  • By entering the order details directly into the sell-side firm’s order management system. This, in turn, may be facilitated by using a third-party “hub and spoke” order routing service. Providers of such services include:

    – Omgeo LLC, through its Oasys product

    – Thomson Financial, through its Autex product

    – Bloomberg, through its POMS and TOMS systems

    – Reuters

    – As well as many other package products and systems developed in-house by fund managers.

Consider the following example where an investor places an order with a broker who then places the order on a stock exchange order queue. The broker first needs to confirm the trade with the investor and then to send settlement instructions to its settlement agent, who will then settle the trade. These stages can be represented by Figure 9.1, and we shall look at the various stages of trade processing from the point of view of the broker.

Figure 9.1 Simplified order flow

Stage 1: The investor places an order with a broker. In a truly STP compliant environment this order would be placed electronically. If it is placed electronically, then it is automatically recorded in the broker’s front-office system without manual intervention. If, however, it were placed by telephone, then the broker would need to enter it into the system manually, and this is the only time that the trade is keyed into any of the broker’s systems

Stage 2: This order is then forwarded to a stock exchange order queue. The decision to do this might be taken automatically by the broker’s front-office system because that system includes business rules that tell it which exchange order queue to forward it to. However, if the order was for more than normal market size for that security, and/or the security was quoted by more than one exchange, then decisions about whether to split it into a smaller number of orders, and/or which exchange to forward it to, might need to be taken by a dealer. In a truly STP-compliant environment, an order that required human intervention would be flagged as such by the system, and displayed to the dealer concerned in such a way that he could select the most appropriate actions.

Irrespective of whether or not there has been human intervention of this kind, the order is placed on the exchange queue automatically by means of an interface between the broker and exchange systems concerned.

Stage 3: The exchange confirms that the deal has been executed by sending a message that is processed by the broker’s front-office system. This system contains business rules to check executions against orders, and provided that the message from the exchange passes the required test, the process moves to Stage 4. If there is a discrepancy, then details of the trade are displayed to the relevant users who then decide what action to take.

Stage 4: The broker then confirms the execution to the investor, by means of an automated interface.

Stage 5: The investor repeats the checking process within its systems. If it is satisfied that the executed trade represents the order it placed, then it affirms it back to the broker, by means of an automated interface. If it disagrees with the execution, then it takes it up with the broker – this process is not usually automated.

Stage 6: Subject to satisfactory completion of Stage 5, the trade details are then forwarded to the broker’s back-office (settlement) system.

Stage 7: The settlement system prepares the settlement instructions which are then sent to the broker’s settlement agent by means of an automated interface. The settlement agent acknowledges receipt of these instructions, again by means of an automated interface.

From time to time between the date and time of trade execution, and the date and time of actual settlement, the agent will communicate – using an automated interface – information about the likelihood of settling on the contracted date. It will inform the broker of any potential problems that would delay settlement, such as:

  • The seller’s instructions and the buyer’s instructions do not match
  • The seller does not have the securities to deliver
  • The buyer does not have sufficient cash or credit to pay for the securities.

In an STP-compliant settlement system there will be facilities to display these messages, together with other relevant information about the trade to users who can manually intervene to deal with the exceptions.

Stage 8: The agent settles the trade and reports to the broker that it has done so using an automated interface.

Stage 9: The broker records that settlement has occurred in its settlement system.

In addition to the steps shown on Figure 9.1, remember that each significant event – such as the generation of the trade from the order and the settlement event on actual settlement date – will also cause accounting entries to be posted to the broker’s general ledger system. These will be handled by an automated interface to the general ledger from the settlement system – refer to Chapter 14 for an explanation of how this is usually achieved. Again, in the STP compliant environment there is no rekeying of data, and facilities are provided to deal with exceptions if there are any problems with this process.

Interfaces may be real-time or periodic scheduled processes, as demanded by the nature of the information being transmitted. In older applications, exceptions may be printed on paper or displayed on user interfaces which users have to check regularly, but in newer systems these exceptions are often displayed in “workbaskets” and automated email messages warn affected users that there are items that require their attention.

9.2 TO WHAT EXTENT IS STP ACTUALLY ACHIEVED IN PRACTICE?

The STP compliant environment described in section 9.1 is an ideal, and not all firms achieve 100% STP for all financial instruments. There is evidence that the more complex the instrument, the lower the STP rate.

In 2006 the Celent Group conducted a survey, based on interviews of over 80 senior executives from a cross-section of European institutions. The majority of respondents indicated that less than 50% of OTC derivatives processing is automated, according to the survey. The lack of STP in OTC derivatives was mainly attributed to the complexity of transactions and lack of standards. As a result, 35% of respondents cited derivatives as the number one priority for STP projects as opposed to other instrument classes. The study also illustrates that equities, fixed income and foreign exchange are benefiting from relatively high levels of STP but still need improvement. The current level of automation of OTC derivative processes involved in trade agreement, and the obstacles to improving it, is examined in section 12.1.1.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.137.223.10