Chapter 10

The Role of Accurate Static Data in the STP Process

The accuracy of static data is a significant factor in achieving STP. Incorrect or incomplete static information is a common cause of trade processing errors. The static data challenge for securities firms can be said to be to1:

• Gather the required data from disparate sources
• Store it securely
• Update it when necessary
• Utilise it appropriately.

This chapter explores the most important items of static data that need to be held regarding:

• The financial instruments that are traded
• The trading parties that the firm deals with
• The settlement agents used by the firm and its trading parties
• Divisions, departments and business units of the firm, including trading books
• Countries in which these various entities are located.

10.1 STATIC DATA OVERVIEW

In Figure 10.1, ABC Investment Bank has a number of dealing teams or trading books. The trading books buy and sell financial instruments that include bonds, currencies, futures and options and equities. The instruments, in turn have parameters, including price calculation methods – for all instruments – and interest rates and interest calculation methods – for bonds and currencies. There are also standard identifiers used throughout the industry to uniquely identify instruments, as well as rules that apply to the markets in which the instruments are traded.

In turn, all instruments are denominated in a currency – that is to say, bonds, equities, futures and options are normally traded and settled in a particular currency.

There is a public holiday calendar associated with each currency, and on the public holidays for that currency no trades can settle, and usually investment exchanges are closed.

The instruments are bought from or sold to trading parties. This term includes exchanges, counterparties and clients. Every one of these is resident in a particular country, as is ABC Investment Bank itself.

All of the trading parties, as well as ABC Investment Bank, have appointed settlement agents (this term includes central counterparties, CSDs and custodians) to settle trades in particular markets within a country. Settlement agents are unable to settle trades on a day which is a public holiday for the currency of the trade concerned.

ABC Investment Bank also has credit policies and credit limits that restrict the total amount of exposure that the firm is prepared to tolerate for particular trading books, trading parties, clients and countries.

The following static data elements also need to be maintained, and are not shown on the figure for the sake of simplicity:

10.2 DUPLICATION OF STATIC DATA ACROSS SYSTEMS

One of the problems involved in managing the IT infrastructure of a large institution is that there may be a large number of individual business application systems in the configuration, all of which hold some of this large amount of static data, and some of the information may be duplicated across the different systems. Where there is duplication of static data, there is a danger that errors creep in – for example, the data about a particular instrument in one system is slightly different to that in another system. Figure 10.2 – a simplified version of Figure 7.3 – illustrates the problem. It is clear that, for example, every one of the systems in this configuration would need to hold details about all the currencies that the firm trades, so there is a danger that such data may become insistent between them.

To overcome these issues, some firms have built separate static data repositories which take in data from reliable sources such as Bloomberg or Reuters, and then feed this data to all the other systems in the configuration; those firms now appear as shown in Figure 10.3.

If a firm chooses to build a repository, then it usually also sets up an operational department whose function it is to manage the collection and update of all static data. The advantages and disadvantages of using a static data repository may be summarised as in Table 10.1.

Table 10.1 Advantages and disadvantages of a repository

10.3 INSTRUMENT GROUP STATIC DATA

Individual instruments of the same type obviously have similarities to each other. It is therefore a useful concept in an investment industry application to hold a table of user-defined instrument groups, so that all individual instruments that are members of a group can inherit characteristics of that group.

The major advantage of using instrument groups are that when an attribute changes, the data need only be changed for the group, rather than for all the (potentially thousands of) instruments that are members of that group.

The firm can hold two types of data at instrument group level:

• “Hard data”: Attributes of the group that all industry participants would agree with
• “Soft data”: Attributes of the group that are specific to this firm.

Consider the following examples (Tables 10.2 and 10.3) of how default data may be maintained at group level instead of instrument level. Note that the examples are not all inclusive – they do not describe every item of data that could be held in this way, they simply provide examples of how an instrument group table could be utilised within a business application.

Table 10.2 Instrument group data for equities

Table 10.3 Instrument group data for debt instruments

Example 1: UK equities quoted on the London Stock Exchange

This table tells us the following “hard data” about all instruments of this type:

• The default currency of trading is pounds sterling – although this could be over-ridden on any individual trade.
• By default, the currency in which the trades settle is the same currency in which they are traded.
• Normally, trades are expected to settle three days after trade date.
• Normally, prices are quoted in penny units of the currency in which they are traded.
• Instruments of this type do not bear interest.

And it also tells us the following “soft data” about these instruments:

• This firm charges commission on trades in these instruments based on data held in a commission scheme called “LSE_Comm” – see section 10.7 for more information about commission schemes.
• As well as commission, there are other charges that may apply to trades in these instruments. Details of these charges are held in a charge scheme called “LSE_Charges” – see section 10.7 for more information.
• When this firm trades these instruments, it deals according to the rules of the London Stock Exchange – note that it is a regulatory requirement to print this information on trade confirmations.

Example 2: Straight Eurobonds

This table tells us the following “hard data” about all instruments of this type:

• As Eurobonds may be denominated in any currency, there is no default trade currency for the group. The data must be entered at individual instrument level.
• By default, the currency in which the trades settle is the same currency in which they are traded.
• Normally, trades are expected to settle three days after trade date.
• Normally, prices are quoted as a percentage of face value.
• Instruments of this type do bear interest.
• The normal interest calculation formula is actual/actual.

And it also tells us the following “soft data” about these instruments:

• This firm does not charge commission on trades in these instruments.
• There are no other charges on trades in these instruments.
• When this firm trades these instruments, it deals according to the rules of the International Capital Markets Association (ICMA) – note that it is a regulatory requirement to print this information on trade confirmations.

10.4 INSTRUMENT STATIC DATA

10.4.1 Instrument identification codes

In order that different industry participants are able to exchange messages between each other, standardised identification codes are needed for each instrument. For currencies, the ISO currency code is used almost universally.

For securities, a number of different coding schemes are widely used. This means that applications should be designed to have a one-to-many relationship between an individual security and the various identification coding schemes that may be needed to support STP in different markets in which the firm operates. These coding schemes are likely to include:

Table 10.4 Major country security coding schemes

Country	Coding scheme name
Australia	ASX
Canada	Cusip
Germany	WKN
Japan	Quick
USA	Cusip

10.4.2 Stock exchange ticker symbols

In addition to the security identification codes that are used in financial messaging, most stock exchange trading systems also identify securities by means of a ticker symbol, which is usually an abbreviation of the name. Investment firms may also need to store a number of ticker symbols for each security that they trade, each one will need to be associated with a particular market where the security is listed.

10.4.3 Static data needed to perform security calculations

The following items need to be stored for each security in order that the basic price calculations and interest calculations described in Chapter 6 can be performed accurately:

• For all instruments:

  – Price multiplier

  – Price divisor

• For interest bearing instruments:

  – For straight bonds – the coupon rate that will apply for the life of the bond

  – For floating rate notes – the benchmark interest rate and the margin above or below the rate that will apply to this bond issue

  – Interest calculation method

  – Rules for predicting coupon dates – for example, the legal documentation that accompanies a new bond issue will inform the reader of the following:

  The first date on which the bond pays a coupon

  The final date on which it pays a coupon, usually this is also the maturity date

  The coupon frequency (e.g. annually, semi-annually, etc.)

  For FRNs – the fixing dates when the benchmark rate will be determined for each coupon period

  The business rules that are to be used (in conjunction with first coupon date and coupon frequency) to calculate future coupon dates. These rules are written in legal terms that provide specific instructions as to what the application should do when a predicted future coupon date falls on a non-working day for the currency concerned.

These business rules must be used in conjunction with holiday calendar and normal working day tables that are explained in section 10.8. They are also examined in more detail in sections 23.3.1 and 23.3.2.

10.4.4 Other instrument static data

In addition to the identification data, and any data that is held at group level, the firm needs to hold, inter alia, the following data about each instrument.

All instrument classes

• The correct name of the instrument
• The minimum denomination of the instrument that can be traded and settled
• The maximum number of decimal places that a price may be quoted to
• The maximum number of decimal places of a quantity that may be traded and settled
• Rules for defaulting the standard value date.

Currencies

• The holiday calendar that applies to this currency
• The normal working days in the week for this currency.

All instrument classes except currencies

• Trading currency
• Settlement currency
• Rules for defaulting the standard value date
• Issue date
• Issuers’ business activities – this information is held for the following reasons:

  – The firm may wish to apply credit limits to different industrial sectors

  – Some business activities (e.g. defence and tobacco) are unsuitable investments for ethical investment funds and Islamic investors.

Equities

• Trading currency
• Settlement currency
• Issue date
• The identity of the issuer of the equity
• The exchange(s) where listed
• Number of shares in issue.

Debt instruments

• Trading currency
• Settlement currency
• Issue date
• The identity of the issuer of the debt instrument
• The identity of any rating agencies that have issued this instrument with a rating
• The rating(s) that each rating agency has awarded it
• Total size of issue.

Listed futures

• The identity of the underlying instrument
• The delivery date/expiry date
• Exchange where listed
• Underlying instrument
• Quantity of the underlying instrument represented by one lot.

Listed options

• The identity of the underlying instrument
• The expiry date
• Whether exercise can only take place on expiry date, or before expiry date
• The exercise price
• Exchange where listed
• Underlying instrument
• Quantity of the underlying instrument represented by one lot

10.4.5 Instrument associations

Many instruments are “associated” with other instruments. These associations can have an impact on the mark-to-market process, which is examined in Chapter 23, and the Value-at-Risk calculation, which is examined in Chapter 24. In order to value these instruments correctly, the static data records need to hold relevant, up-to-date and accurate information about the other instruments with which they are associated.

Table 10.5 table gives examples of some instrument associations and their impact on these processes.

Table 10.5 Instrument association static data

Main instrument type	Associated instrument type	Comment
Convertible bond	Other instrument (usually an equity) into which the convertible bond may be converted	The valuation of a convertible bond is dependent on the conversion terms (see section 3.1.6 for an example) and the current price of the associated instrument. Therefore the system needs to hold: 1. The unique ID of the instrument into which the bond may be converted 2. The conversion terms, including: Conversion price Conversion period dates.
Bond with warrants attached	1. The warrant	The price of a bond with warrant attached is the sum of the price of the warrant and the price of the ex-warrant bond. Therefore the system needs to hold:
	2. The ex-warrant bond	1. The unique ID of the ex-warrant bond
		2. The unique ID of the warrant.
Warrant or OTC option	Other instrument (usually an equity) that will be obtained when the warrant or option is exercised	The value of a warrant or OTC option is dependent on the value of the underlying instrument. Therefore the system needs to hold: 1. The unique ID of the underlying instrument 2. The exercise price of the warrant 3. The exercise period of the warrant.

10.5 TRADING PARTY AND SETTLEMENT AGENT STATIC DATA

10.5.1 Trading party identifiers

Firms that offer tax sheltered investments to private individuals will need (subject to legislative variations between countries) to record their clients’ National Insurance or Social Security numbers.

In order to identify corporate bodies it is necessary to record their company registration number and jurisdiction of registration.

On messages between investment industry participants parties are usually recognised by a BIC code or bank identifier code. This is the unique identification code of a particular bank. SWIFT handles the registration of these codes. For this reason, BIC codes are often called SWIFT addresses or codes. There are over 7500 “live” codes (for partners actively connected to the SWIFT network) and an estimated 10000 additional BIC codes which are frequently used to refer to trade parties who are not themselves connected to SWIFT.

The code is 8 or 11 characters, made up of:

• 4 characters – bank code
• 2 characters – ISO 3166-1 alpha-2 country code
• 2 characters – location code
• 3 characters – branch code, optional (“XXX” for primary office).

Where an 8-digit code is given, you may assume that it refers to the primary office.

For example, Deutsche Bank is an international bank; its head office is based in Frankfurt, Germany. Its BIC code for its head office is DEUTDEFF:

• DEUT identifies Deutsche Bank
• DE is the country code for Germany
• FF is the code for Frankfurt.

Using an extended code of 11 digits (if the receiving bank has assigned branches or processing areas individual extended codes) allows the payment to be directed to a specific office. For example, DEUTDEFF500 would direct the payment to an office of Deutsche Bank in Bad Homburg.

10.5.2 Other trading party static data

The following are the principal items of static data that the firm needs to hold about its trading parties:

• Party full name
• Party address
• Party type – e.g. private individual, bank, corporate, fund manager, etc.
• Regulatory information, including:

  – MiFID party classification. One of:

  Eligible counterparty – e.g. another regulated bank or stock exchange member firm

  Professional client – e.g. a pension fund

  Retail client – e.g. a private individual

  – Date that the party commenced dealings with this firm

  – Information about party’s risk tolerance, investment knowledge and financial position

  – Details of what steps were taken to verify client’s identity.

• Any other addresses where copies of correspondence need to be sent. For example, fund manager customers may require confirmations to be sent to the investor as well as to the fund manager.
• Country of incorporation or residence.
• Details of any credit limits that are applied to this entity – this topic is covered in section 24.1.6.
• Details of relationships with other parties on the database. For example:

  – We may have accounts with Mr John Brown and Mrs Jane Brown, who are husband and wife.

  – XYZ Fund Managers may be wholly or partially owned by XYX Bank. We need to be able to track corporate ownership structures so that credit limits can be applied to groups of companies.

10.6 STANDARD SETTLEMENT INSTRUCTIONS (SSIs)

10.6.1 Overview

Standard settlement instructions (SSIs) are the main driver of the STP process from the point of trade agreement to final settlement. SSIs provide details of which settlement agents both the sell-side firm and the investors who use its services are going to use to settle the trade.

Both the cash side and the stock side of a securities trade will be settled – normally on a delivery-versus-payment basis – by the settlement agents chosen by the sell-side firm and the investor. Where a fund manager is acting for a number of investors, it is the investors – not the fund manager – that choose their settlement agent. Sell-side firms normally appoint CSDs such as CREST or ICSDs such as Euroclear as their settlement agents, while institutional investors normally appoint custodian banks.

In order to generate instructions both parties need to know who to send them to (our settlement agent) as well as details of the other party’s settlement agent, as we need to advise our agent this information so that it can settle the trade. For this reason, firms hold details of the SSIs of those trading parties with whom it deals regularly as static data objects.

10.6.2 Examples of SSI data

Tables 10.6 and 10.7 show the SSI-related data held by ABC Investment Bank for itself, and also two of its investor clients for three major asset classes:

• UK listed equities settled in GBP
• Corporate bonds traded in London and settled in EUR
• Corporate bonds traded in London and settled in USD.

Table 10.6 Key to SSI table column headings

Column name	Purpose
Trading party	Identity of the party with which the firm is trading. The firm itself is also a trading party in this context
Instrument class	Identifies the type of asset concerned
Settlement currency	Identifies the currency of settlement
Stock depot	Identifies the settlement agent that will accept or make delivery of this type of asset on behalf of the trading party
Depot account code	Identifies the relevant account number at the stock depot
Cash nostro	Identifies the settlement agent that will accept or make payments for this type of asset on behalf of the trading party
Nostro account code	Identifies the relevant account number at the cash nostro
Instruction method	The method that the trading party will use to send instructions to the settlement agent

Table 10.7 Example SSI data

The tables introduce us to two new terms:

• Depot, which is the account with the settlement agent that is used to record transactions and balances in security quantities is often referred to as “the depot account”.
• Nostro which is the account with the settlement agent that is used to record transactions and balances in money amounts is often referred to as “the nostro account”.

10.6.3 Omgeo Alerts™ – centralised storage of SSI data

Traditionally, every trade party has had to maintain a file of the SSIs of every other trade party with whom it does business. This is clearly inefficient, as when one trade party changes its settlement instructions, it has to notify every other trade party that might be concerned. As a result, Omgeo LLC, a joint venture of the Depository Trust & Clearing Corporation (DTCC) and Thomson Financial, established Omgeo Alerts, a centralised database of the SSIs of over 9000 participants.

This database is updated by fund managers, global custodians and sell-side firms whenever new information is added or existing information is changed. Fund managers may also identify a list of sell-side firms with whom they wish to share this information for each of their investor clients. When any one of these organisations changes its SSIs for a particular instrument class then the other relevant parties are notified.

The product validates data as it is entered, for example invalid BIC codes are detected. It also allows fund managers to specify the method by which confirmation messages should be delivered, and allows them to specify the delivery addresses for each message.

The data that has been entered may be viewed in a web browser or printed out and entered into individual firms’ settlement systems in order to update the SSI tables held in their internal systems. The functions of Omgeo Alerts are illustrated in Figure 10.5, which is reproduced by permission of Omgeo LLC.

Each party inputs details of any new or amended SSI data. For example, a fund manager inputs amended SSI data for one of its investor clients. The data is validated appropriately and then accepted by the application. When the sell-side firms that execute trades on behalf of that investor log on to Alerts, they are informed that the SSI details for that investor have been changed, and are able to inspect details of the change, and amend their own SSI records appropriately.

10.6.4 Identification of depot and nostro account numbers

Bank account numbers have traditionally been expressed in different forms in different countries, which has made the storage of depot and nostro account numbers in applications somewhat imprecise.

As a result, in 2003 the European Union decided to adopt the IBAN code to overcome this problem. The IBAN was developed to facilitate payments within the European Union. The IBAN is not yet used as a standard in messaging, because the IBAN has not yet been widely adopted outside Europe. Adoption may take up to 10 years, so it remains necessary to use the current ISO 9362 Bank Identifier Code system (BIC code) in conjunction with the BBAN or IBAN.

At present, the United States does not participate in IBAN. Any adoption of the IBAN standard by US banks would likely be initiated by ANSI ASC X9, the US financial services standards development organisation.

Currently all European non-CIS countries, as well as some African countries and Turkey, participate in the IBAN system, while the rest of the world remains outside of it. British dependencies (except Gibraltar and the Crown Dependencies) don’t participate in the IBAN system.

The IBAN consists of an ISO 3166-1 alpha-2 country code, followed by two check digits (represented by kk in the examples below), and up to 30 alphanumeric characters for the domestic bank account number, called the BBAN (Basic Bank Account Number). It is up to each country’s national banking community to decide on the length of the BBAN for accounts in that country, but its length must be fixed for any given country.

The IBAN must not contain spaces when stored electronically. When printed on paper, however, the norm is to express it in groups of four characters, the last group being of variable length.

10.7 STATIC DATA THAT IS INTERNAL TO THE FIRM CONCERNED

The firm also needs to set up a number of static data elements that tell its business applications information about the firm itself. These “internal” static data objects will include, but are not limited to:

A sample hierarchy might look like Figure 10.6.

10.8 NORMAL WORKING DAYS AND PUBLIC HOLIDAYS

A firm needs to establish tables that informs it of:

• The various public holidays that apply across the globe. On these days stock exchanges and the banking systems in the countries concerned will be closed, so that no trades can settle. Note that in most jurisdictions there are very few public holidays that close exchanges or banking systems to large transactions. Although Italy, for example, had 11 public holidays in total in 2007, only two of those – 1 January and 25 December – were days on which the banking system was closed to transactions of this type.

In older investment industry applications, public holidays were traditionally associated with either currencies or countries, but this relationship is now considered over-rigid in the design of investment industry applications, as the following example will show.

• For this reason, in modern business applications it is now considered “best practice” not to associate holiday calendars with countries or currencies, but to consider them as freestanding objects that may be associated as and when necessary with individual instruments and transactions as and when appropriate.
• Normal working days: Most countries use Monday to Friday as normal working days, and banks are closed at weekends. There are exceptions to this rule – some Islamic countries close their banks on Fridays and open them on Sundays.

10.9 COUNTRY INFORMATION

Countries are normally recognised by a two character ISO country code such as GB or US. Firms need to record the country of incorporation or residence of their trading parties and settlement agents so that:

• They can produce a number of statistical returns that may be demanded by their governments. Some of these returns are concerned with investment regulation; others may be concerned with data required by tax authorities and also requirements imposed on the industry to supply the government with data used to compile the home country’s balance of payments data.
• Some firms will wish to apply credit limits that restrict their exposure to individual countries.

1 Michael Simmons provided this definition in Securities Operations – A Guide to Trade and Position Management; John Wiley & Sons, 2002. Reproduced by permission of John Wiley and Sons Ltd.