Basics of Efficiency and STP in Securities Processing
Straight-through processing (STP) has been an industry buzzword for many years in the securities settlement business but there has been limited progress in achieving it. Objectives and plans have been set up by public authorities and market bodies like BIS/IOSCO (Recommendations for Securities Settlement Systems), the Group of Thirty (Global Clearing and Settlement – A Plan of Action) and SWIFT (the work on STP using ISO 15022 standards) but while some common agreement has been reached, the securities industry is still not close to attaining large-scale STP automation. The main reasons for this seem to be an insufficient focus on basic STP requirements.
The processing of securities transactions is a complex task and one where several parties and systems are involved. The typical securities deal is a two-way process, in which the securities flow from the seller to the buyer and the money and payment for the deal flows in the opposite direction from buyer to seller with an interlinked conditional delivery process in between to ensure that the delivery-versus-payment (DVP) requirements are fulfilled. Figure 1 below illustrates this process.
In Figure 1, the flow of securities from the seller is presented as a solid line and the payment flow from the buyer is presented by dotted lines. The seller makes a sell order to his broker/dealer, who makes a deal request to the stock exchange and when a deal is struck the securities are delivered for matching and DVP settlement. The buyer makes a buy request to his broker/dealer, who also makes a deal request to the exchange and when a deal is struck between these two, the payment will be matched and settled in DVP with an interlinked security leg. Both transaction flows, the security leg and the money leg, meet in the important DVP exchange phase, after which the payment and securities can be delivered with finality to the investors. Matching is the process in which the two flows are recognised as interlinked and fulfil the required conditions.
The DVP process in Figure 1 is performed at omnibus-level, i.e. between custodians, which is the traditional level for settlement. Some modern systems perform the DVP settlement in one go directly on the end-investor level, e.g. Nordic and Greek central securities depositaries (CSDs). In the first case, the wholesale model, the CSDs only carry custodian totals on the accounts while in the later case, the retail model, the CSDs carry individual investor balances.
Figure 1 gives a general picture of the flows, but there are some simplifications. It does not contain a central counterparty (CCP), which are used in some cases between the stock exchange and settlement systems. It neither explicitly shows over-the-counter (OTC) transactions and other deals done outside the stock exchanges or transactions settled directly on a given custodian’s accounts, which would shortcut some parts of the depicted flows. Free-of-payment type transfers would also be a simple transfer between a sending and receiving custody account without the DVP link to a payment leg. Figure 1 displays the possibility of two interlinked CSDs, which could be the case in Europe for cross-border settlement. It also shows the possibility of settlement money accounts kept with two different central banks, which can be feasible within the European RTGS-network called TARGET. Private settlement agents (money) are also used in some systems. Figure 1 presents a one-to-one deal for investment initiation flow made by the brokers/dealers. Often brokers and dealers combine the investment initiation of several customers into one major deal or make several deals in order to gather the total investment request made by the customer. However, the basic STP requirements are the same for both simple and more complex deals and therefore the technical design can be the same despite variations.
In order to achieve electronic STP, all securities need to be held in book entry format. This is the case in most countries, either via complete dematerialisation of securities or immobilisation of original certificates. The regulation and taxation differences that exist are problematic due to interoperability issues (this article focuses on technical interoperability issues only).
Different types of CSDs and securities settlement systems have been set up to handle automated processing book entry securities. Achieving STP will require messages between the different entities and systems in the process to be standardised and this has mostly been achieved through the development of the ISO15022 standards used in the SWIFT network. The content and design used for interbank/institution messages still need to be expanded all the way to end-investors in order to achieve STP reaching from end-to-end.
In addition to standardising the message dialogue, it is important to design a coherent set of identifiers used by everybody processing security transactions. An STP process requires clear identifiers so that all systems in the processing flows can identify the entities involved. The STP process should be seen as an end-to-end process starting from the buyer’s systems and ending with the seller’s system in both directions. The important data should flow through all processes even though only part of the data is relevant in each process. It is important that the banks and custodians are willing to pass through identifiers and other data that are important for investors for their automated portfolio management. Everyone in the process should receive the messages, including the important identifiers and other data, so that they can apply and re-use the data directly and find the internal data linked to the incoming messages in their databases.
A completely automated STP process requires the following identifiers:
Although these might seem like self-evident requirements, the problem seems to be that most of the current securities processing systems have been developed based on the historic needs of small scale paper-based processing environments without re-designing them for large-scale automated STP employment. The current identifiers, where they exist, are generally non-standardised and non-interoperable; therefore, the current legacy systems need a co-ordinated re-design for STP.
The only essential STP coding that has currently been implemented in securities systems is the International Securities Identification Number (ISIN). However, different kinds of irregularities can be found in the use of this standard. Sometimes securities can have parallel ISIN codes in different systems when the original securities have been moved to be processed in another system. These irregularities need to be corrected in order to support common international identifiers.
There are clear ISO codes for currencies. However, most of the current systems use one default domestic currency. Due to increased consolidation, cross-border trade and multi-currency processing, it would be advisable to require currency information to also become mandatory data in all transactions.
In order to move items electronically in STP mode between two participants, an unambiguous addressing system is required. Data communication requires clear senders’ and receivers’ addresses. For example, international card systems have solved the address problem by applying the international card number standard and everybody is familiar with the email @ address system.
In order to make a normal monetary credit transfer, the sender states the receiver’s account number. In order to facilitate international STP credit transfers, a standard called the international bank account number (IBAN) was created and its wide-scale implementation has already progressed well throughout Europe. It is one of the mandatory new standards in the single euro payment area (SEPA). The use of IBANs should become mandatory for the money legs of securities settlements.
The most important basic element that the securities settlement industry is currently lacking is a clear address standard for custody accounts. A suitable acronym could be the international custody account number (ICAN). By numbering all custody accounts according to an international standard, securities transfers could be made automatically between the custody accounts. There needs to be international standards, including routing information and check digits, in the same way as IBANs.
The processing of free-of-payment transfers of book-entry securities is very similar to normal credit transfers in payments. The resemblance between IBAN and ICAN is deliberate because in payments the customer IBAN is be required. In a DVP transfer the ICAN and IBAN would be the codes for efficient routing of both the securities and payment legs.
The standardised IBAN consists of a country prefix, an international check digit and a domestic account number, in which the domestic institution code and individual customer account numbers are embedded in different ways. The ICANs could have the same structure as IBANs, but because the ICANs will be created almost from scratch, it could be more efficient with a general construction more in line with the card number design in which the first six numbers identifies the issuing institution and the remaining numbers are for individual customer accounts with a trailing check digit. The use of IBANs and ICANs will facilitate efficiency in all kinds of transactions including corporate actions.
All securities transactions start and end in the investors’ portfolios. The investors on investors’ portfolio managers need references to identify the incoming transactions and messages belonging to the original orders. When selling securities based on an order, the order reference should also be contained in the incoming payment transfer and vice versa for the buyer. These reference codes, which could be called BUY-REF and SELL-REF, need to be carried through the whole system of linked processes and in both directions in DVP deals. The STP should stretch through to the end-users/investors. These codes help the end-investors to automatically reconcile orders and deliveries.
These reference codes need to be unique within the buyers’ and sellers’ systems so they can select them freely, but it would be most effective if they could have a simple common structure of a maximum length and check digit. A standardised check digit convention would be helpful in ensuring correct keying in, when these codes are, for some reasons, keyed in manually somewhere during the process. It also facilitates improved validation of the codes during the process, which results in early alerts to possible system malfunctions.
The data fields for these reference codes are available in the current SWIFT messages, but their use is optional and varies. Every service provider should be required to pass on these references and both the buying and selling entity should consistently quote them in order to increase processing efficiency on both sides.
It is also typical that brokers/dealers group end-investor orders into bigger groups. This will result in a stepwise process in which the brokers/dealers are the primary parties in the settlement process on the infrastructure level and later split the incoming delivery batches to separate end-investors in the same way they have originally compounded the outgoing batches.
Nowadays, when someone sends a parcel with any of the parcel mail service providers, they get a parcel identification code, with which they can follow, in real-time on the Internet, the progress of the parcel’s transportation. In the same way, each transaction in the settlement infrastructure would need a transaction code (TRAN-CODE) to identify it throughout the process. It will also be the audit trail code for following its passage through the different accounting systems. In case of inquiries, this code can be used to retrieve the necessary information from any stage of the process.
Applying ICANs and IBANs directly would, to some degree, reveal the buyer/seller. Information on the deals made by larger players might have a market impact. Anonymous one-time exchange deal identifiers called DEAL-CODEs could be used to hide the original investors and brokers/dealers could keep the cross-reference tables. The DEAL-CODEs are also necessary when the brokers/dealers merge several orders into groups and then need to keep information on how the combined deals are made up of original orders.
Once the deal is made, the stock exchange creates a matching code that defines which deal requests belong together. This unique MATCH-CODE would then be used in the settlement system in order to unambiguously combine the two delivery legs for DVP settlement. Where the deal is agreed outside the stock exchange the original investors or their brokers/dealers assign a unique MATCH-code. Clear match coding would improve the current matching process considerably because it would be explicit and unambiguous compared to the current practice, which is based on finding sufficient similarities in a number of fields, but still leaving the possibility of mixing similar transactions/deals.
The described model of identifiers is especially well suited to electronic trading in which the buyer and seller sends one deal request, which is processed on a one-to-one basis through the system. Most of the current e-trading platforms function in real-time with immediate feedback. It might be that in the near future these will be accompanied by real-time settlement, in which case STP supporting identifiers will become inevitable.
However, the proposed identifiers are also suitable and required for traditional trading and settlement in STP mode. This is often a three level-process. The investor makes a deal request through his dealer for a securities lot, for example, at a value weighted average price. During the day, the dealer makes a number of deals in order to produce the required lot for this customer. At the same time, he might also make other deals for other customers for the same item. At the wholesale level settlement, the custodian will have to deliver at least the net value of items for the trades connected to investor portfolios in custody.
In order to achieve STP, the traditional three-level design requires three levels of IBANs and ICANs (investor, dealer/brokers and custodians) and also three levels of references. To connect the reference chain between investor references, dealer references and custodian references it is necessary to construct a cross-reference table that conveys the information on which investor requests belongs to which dealer requests and which investor requests belongs to which settlement requests. The cross-reference tables are an important part in automating the traditional trading conventions where there are complex m:n relationships compared to the simple 1:1 relationships generally used in e-trading.
Within the infrastructure, all institutions need to be clearly identified, which calls for an institution coding INST-CODE. One good alternative for this could be the bank identification code (BIC) used in the SWIFT network. In order to be more general in this article, the institution code is called INST-CODE, partly due to fact that the BIC coding is not yet agreed universally as an institution identifier in all situations. The INST-CODE would be needed for all stock exchanges, settlement systems, CSDs, custodians and broker/dealers as well as banks.
The INST-CODE is also important for identifying the custodian level accounts in the CSDs (i.e. the omnibus-accounts) and the settlement money accounts with the central banks (or with other settlement agents). Homogeneous standards would require these to follow the ICAN and IBAN standards for the investor accounts. Only the institutional part of these codes would be different and refer to the CSD and central bank instead of normal credit institutions.
An efficient STP process requires that the necessary data can easily be found and retrieved from the different databases used in the process. Figure 2 below provides an overview of the databases and identifiers that are used as the essential database keys.
The identifiers make supply the essential keys for identifying the data in the process. Together with the message/transaction standards, the identifiers will provide the necessary structures for technical interoperability.
All corporate action services with money or security deliveries would benefit from coherent identifiers and especially investor IBANs and ICANs so that the items could be directly routed straight through to the end-investors. Corporate actions can be very complex and without getting the basic identifiers in place there are no possibilities for increased processing efficiency.
The technical standards for efficient STP will be capable of solving most of the efficiency problems in the securities settlement process. They will create the basis for interoperability among the involved parties. However, we also need to have open interfaces and networks between the systems in order to achieve more and sufficient competition. Free processing and movement of securities between the different CSDs, settlement systems and stock exchanges is important. Competition can only increase if the current silo-type monopolies change to open structures. Common technical standards will facilitate this.
There are also regulatory barriers that impede efficiency. Different national regulations and tax rules require separate processing rules and data content. Sometimes even relatively small differences can result in complicated extra processing requirements. However, these are easier to implement when the basic structure and identifiers are standardised.
Regulatory differences are often the biggest barriers for efficient integration and consolidation of infrastructures in Europe. Instead of a closed network of non-interoperable national monopolies, we should have an open network of interoperable competing service providers. The participants in the infrastructure need to agree upon interoperable business rules, which use the technical possibilities of the common infrastructure.
Automated STP will require the restructuring of paper-based processing conventions. It is essential that we find a common structure and design for the next generation of securities processing systems. Some readers may have found the text describing codes and identifiers somewhat dull, however, without getting these details correct STP will remain just a dream without the chance of becoming a reality. We need to get the basic standards in place in order to create the possibility for increased efficiency.
Next time you fly, spend a moment to consider the well-functioning coding systems for air traffic – with its destination addresses, air line coding and flight numbers, agents, seating arrangements, special food, airway bill numbers, luggage tags etc – where everything works online through one common worldwide network of interoperable computers and databases (and where there are identifiers and acronyms for everything). If we want to get STP in securities settlement to take off and fly we must get the basic coding and structures right on an international scale. Merely merging stock exchanges or settlement systems or providing completely new ones will not be enough to improve efficiency and STP rates, without at the same time tackling the fundamental ‘plumbing’ issues of STP.
Providing end-to-end STP will require global co-operation and standardisation according to a common, long-term vision. It requires commitment from all the major players to implement and use the common architecture. It requires a project-leading organisation that is capable of keeping all of the details on track, as well as long-term focus and investment in order to improve the infrastructure and allow STP to thrive. The possibilities for drastically improving system efficiency and significantly reducing processing costs are obvious, but it will not happen overnight and it will require hard work.