Financial Markets Operations Management (14 page)

BOOK: Financial Markets Operations Management
8.41Mb size Format: txt, pdf, ePub
NOTES
CHAPTER 3
Data Management
3.1 INTRODUCTION

In today's financial world, the typical Operations Department has to capture and process vast amounts of data and information. In our personal lives we have to remember a multitude of login IDs, passwords, PIN numbers, telephone numbers, addresses of family, friends, customers, etc. How do we remember any or all of these different types of information? We can either memorise them (open to forgetfulness) or write them down (open to losing the paperwork). Either way, we run the risk of not having the correct information at the moment when we actually require it.

We are probably able to correctly identify our personal telephone numbers, home address and our most frequently used PIN numbers; we might possibly think we can remember some of our less frequently used information but have little chance of remembering occasionally used information. What, then, can we do? The obvious solution would be to develop a database into which we can enter a variety of different types of information that can be accessed easily when needed. Straight away you might be able to identify a problem with this approach – your database might be appropriate for your needs but inappropriate for everybody else's! In one sense, this is what has happened in the industry: banks, securities houses, fund management companies and all the other types of participant have developed their own databases focusing on their own requirements. What is needed, however, is a high degree of standardisation, where information can be generated from one source and be understood by all those individuals and institutions that require it.

By the end of this chapter, you will:

  • Appreciate the importance of data and the information that comes from them;
  • Know the different types of data and how they impact on the Operations Department;
  • Understand how data are managed;
  • Have learnt about the new global standard for legal entity identification.
3.2 IMPORTANCE OF REFERENCE DATA AND STANDARDISATION
3.2.1 Introduction

In the early 1980s, the author was working in a Eurobond Settlements Department where manual ledgers were still being used to record Eurobond purchases and sales. He remembers that:

“Euroclear, who held our Eurobonds, would publish a thick, hard-copy directory every six months containing basic details of every security that they were prepared to hold.

Every time a transaction ticket came down from the trading floor, the first thing we had to do was to find the particular bond in the Euroclear directory. From this, we could find the following information:

  • The correct name of the bond, including the coupon rate and full maturity date);
  • The securities identification number (unique to Euroclear);
  • The last coupon payment date.

This would enable us to calculate the accrued interest, arrange for a confirmation note to be typed up and prepare the appropriate delivery/receipt instructions. These would be transmitted to Euroclear's proprietary system (known as Euclid) via an acoustic coupler (an interface device for coupling electrical signals by acoustical means) that was hooked up to a telephone handset.

In effect, we were using the directory as a manual version of a securities database. The main drawback was that this process took quite some time, especially as there was only one directory book for the whole department! The situation improved when the department was computerised; however, the system that we purchased used the Euroclear securities identification system (as we had done previously in the manual environment). This gave us problems when we were communicating with Cedel (now known as Clearstream Banking Luxembourg). Cedel had its own directory and unique numbering system …”

3.2.2 Basic Securities Transactions

Let us consider a basic securities transaction, thinking about the information that is provided by the Front Office and comparing that with the information we need to be able to settle the transaction effectively. In today's environment, the majority of transaction information will arrive in the Operations area in an automated and electronic fashion. To help with the visualisation of the information, it is worth considering a transaction example using a hard copy dealing ticket.

   

Then ask yourself whether there are sufficient details on the dealing ticket to enable you to settle the transaction. The answer should be “No”; it will, therefore, be our responsibility to add the appropriate elements of information so that we can prepare, for example, confirmation notes and settlement instructions, update our books and records and all the other various processes.

3.3 TYPES OF REFERENCE DATA
3.3.1 Required Reference Data

From the transaction in the previous section, we can create a list of examples of the required reference data (see
Table 3.2
).

TABLE 3.2
Required reference data

Data Type
Data Elements
Transaction data
  • Price
  • Quantity
  • Counterparty
  • Customer (if appropriate)
  • Exchange/trading venue
  • Settlement instructions
Security identification
  • Local market identifier
  • International identifier
  • Security class
  • Maturity
Counterparty information
  • Credit ratings (internal and external)
  • Account details
  • Transaction history
Customer information
  • Credit ratings (internal)
  • Account details
  • Demographic information
  • Transaction history
Settlement information
  • Clearing house(s)
  • Clearing model (BIS)
  • Timing (trade date plus
    n
    days)
  • Calculation conventions

We will now consider what data we require for three of these data types:

  • Securities;
  • Counterparties and customers;
  • Settlement information.

The challenge for the industry is to enable information to be classified and standardised in such a way that the users of information can access it and interpret it no matter what type of industry participant they are or in which market they are located.

3.3.2 Data Requirements – Securities

We will look at two issues regarding securities: the identification of securities and the classification of securities. Traditionally, securities issued in one
particular market would be identified by a national numbering system unique to that market.
Table 3.3
shows some examples of local numbering systems.

TABLE 3.3
Examples of local numbering systems

Country
Numbering System
Description
USA
CUSIP (Committee on Uniform Security Identification Procedures)
9-character alphanumeric code
UK
SEDOL (Stock Exchange Daily Official List)
7-character alphanumeric code
Germany
WKN (Wertpapierkennnummer)
6-character alphanumeric code

Whilst national numbering systems work well in a local context, a unique identifier is required in an international context. The internationally recognised standard for securities is the International Securities Identification Numbering system (ISIN). ISINs are issued by national numbering agencies (NNAs) using guidelines published by the Association of National Numbering Agencies (
www.anna-web.org
). An ISIN consists of 12 characters: a country code (two letters), nine characters taken up by the local number of the security and a final character acting as a check digit.

The NNA will typically be located in the country where the securities issuer is legally registered or, for debt securities, the NNA might be one of the international securities clearing organisations.

The international standard appropriate to ISINs is the International Organization for Standardization (ISO) 6166.

ANNA also acts as the registration authority for ISO 10962 – the Classification of Financial Instruments (CFI) Codes. CFI codes are allocated by the agency that allocates the ISIN and consist of six alphabetical characters that enable users to identify the type of financial instrument, its characteristics and attributes (see
Table 3.4
).

TABLE 3.4
CFI codes

Character Number
Classification Level
First character
Category of instrument

Equities (E)

Debt (D)

Rights (R)

Options (O)

Futures (F)

Structured products (S)

Referential instruments (R)

Miscellaneous (M)

Second character
Instrument group
Example – Equities:
  • Shares (S)
  • Preferred shares (P)
  • Preference shares (R)
  • Convertible shares (C)
  • Preferred convertible shares (F)
  • Preference convertible shares (V)
  • Units, e.g. mutual funds (U)
  • Others (miscellaneous) (M)
Example – Debt:
  • Bonds (B)
  • Convertible bonds (C)
  • Bonds with warrants (W)
  • Medium-term notes (T)
  • Money market instruments (Y)
  • Asset-backed securities (A)
  • Mortgage-backed securities (G)
  • Others (miscellaneous) (M)
Third to sixth characters
Attributes
Up to four attributes applicable to the financial instrument

Source:
ISO 2006. “Securities and related financial instruments – Classification of Financial Instruments (CFI code) – [Revision of ISO 10962:2001].” Available from
www.fixtradingcommunity.org/ mod/file/view.php?file_guid=43074
. [Accessed Monday, 25 November 2013]

Tables 3.5a
and
3.5b
give some CFI classification examples.

TABLE 3.5a
Equities

ISIN
US4592001014
IBM International
CFI
ESVUFR

E = Equities

S = Shares, i.e. common/ordinary

V = Voting

U = Unrestricted (no ownership/transfer restrictions)

F = Fully paid

R = Registered

TABLE 3.5b
Debt

ISIN
GB0002146073
Commonwealth Bank of Australia, exchangeable floating-rate notes 1988-perpetual
CFI
DCVTQB

D = Debt

C = Convertible/exchangeable bonds

V = Variable interest rate

T = Government/Treasury guaranteed

Q = Perpetual with call feature

B = Bearer form

In summary, for every type of financial instrument there will be a unique identifier and classification that enables users to standardise the information. However, there is yet more information that we need to know about the securities we are processing. We will look at this for examples involving a debt security (see
Figure 3.1
) and an equity security (see
Figure 3.2
).

Static Data Item
Example of a Bond
Typical Use of Data
Full Name of Security
British Land Company Co Ltd., 8.875% Bonds 2023
The formal description of the issue, used on trade confirmations & other correspondence with clients
ISIN
XS0047184964
The commonly known security identification number used for external communication, such as trade confirmations & trade instructions
CFI Code
DBFUGB
D = Debt, B = Bond, F = Type of Interest (Fixed), U = Guarantee (Unsecured), G = Redemption (Fixed maturity with call feature) & B = Bearer
Issued Currency
GBP
Quoted on trade confirmations & settlement instructions. Internally, represents the currency of the trading position & the cash owed by/to counterparties
Issued Quantity
150,000,000
Provides a measure of the position held in the issue as a percentage of the total issued amount
Security Type
Bond
Provides internal statistics & reporting by type of security
Security Group
Eurobond (GBP)
Enables distinguishing of security for static data defaulting
Coupon Rate Type
30E/360
Enables attachment of attributes such as accrued interest calculations
Coupon Rate
8.8750%
Enables calculation of cash value of accrued interest on trades & coupon payments
Coupon Frequency
Semi-Annual
Enables calculation of accrued interest on trades & coupon payments
Cpn Payment Date(s)
25 March & 25 September
Enables calculation of accrued interest on trades & coupon payments
Primary Value Date
15-Nov-93
Earliest value date of a new issue & the point from which accrued interest (on bonds) starts to accrue
First Coupon Date
25-Mar-94
Enables determination of (first) long, (first) short or regular coupon periods
Maturity Date
25-Sep-23
Identifies date of final capital repayment
Early Redemption
Yes
Call feature at any time, subject to notice, at the higher of either par or a GRY equal to that of a specified Reference Bond
Maturity Price
100%
Identifies the price of the bond payable by the issuer at maturity
Board Lot Size(s)
100,000
Ensures trades are executed in acceptable denominations
10,000
Default Book
Trading Book
Enables defaulting of the internal book that typically trades this security
Credit Rating
A+
Enables calculation of collateral values of this security. Ensures security is valid from a risk management perspective

FIGURE 3.1
Reference data – bonds

Static Data Item
Example of an Equity 
Typical Use of Data
Full Name of Security
Barclays plc, ordinary shares 25p fully paid
The formal description of the issue, used on trade confirmations & other correspondence with clients
Ticker
BARC:LSE
NSIN
3134865
The local/national identifier of the individual security (UK = SEDOL)
ISIN
GB0031348658
The commonly known security identification number used for external communication, such as trade confirmations & trade instructions
CFI Code
ESVUFR
E = Equity, S = Ordinary Shares, V = Voting (one share: one vote), U = Free (unrestricted ownership of transfer), F = Fully paid, R = Registered.
Settlement Currency
GBP
Quoted on trade confirmations & settlement instructions. Internally, represents the currency of the trading position & the cash owed by/to counterparties. (NB – shares priced in GBX in the UK)
Shares Outstanding
16.10 bn
Provides a measure of the position held in the issue as a percentage of the total issued amount. Can have regulatory implications (disclosure requirements)
Security Type
Equity
Provides internal statistics & reporting by type of security
Div Payment Date(s)
Interims: Jun, Sep & Dec Final: Mar
Identifies date(s) of dividend payment (subject to announcement)
Listing Date
31-Dec-53
Listing/admission to trading
Board Lot Size(s)
1
Minimum transferable number of shares
Exchange Market Size
10,000
Normal market size – ensures trades are executed in acceptable denominations
Default Book
Trading Book
Enables defaulting of the internal book that typically trades this security

FIGURE 3.2
Reference data – equities

3.3.3 Data Requirements – Counterparties and Customers

There is a requirement that information on counterparties and customers should be sufficient to enable:

  1. Financial institutions to effectively communicate with their counterparties and customers.
  2. Financial institutions to verify counterparty/customer identification information.
  3. Counterparties/customers to operate within anti-money-laundering regulations.
  4. Customer due diligence to be undertaken.
  5. The identification of politically exposed persons (PEPs).
  6. The submission of suspicious activity reports (SARs) to the appropriate authority.

For businesses, we need to keep identification information such as:

  • Full name of the business entity;
  • The entity's designation (e.g. Limited, plc, SA, Inc. etc.);
  • Trading name;
  • Registered number;
  • VAT and/or tax reference number;
  • Country of incorporation;
  • Business/trading address;
  • Registered office address;
  • Names of directors;
  • Details of any individuals who own/control/exercise control over the management of the entity.

This information enables us to identify individuals, counterparties, customers and, not least of all, the companies for whom we are working. There is still information that we need to know, and this can include the following:

  • Short name and reference number for counterparties and customers (used for internal reporting purposes);
  • The type of counterparty (e.g. institutional client, broker, trading organisation, etc.);
  • Any companies associated with a counterparty (plus the relationship);
  • Names and locations of custodians together with account numbers for both securities and cash;
  • Standing settlement instructions (the media through which instructions are sent to custodians and clearing houses);
  • Membership of exchanges (for reporting purposes).

Other books

Censoring an Iranian Love Story by Shahriar Mandanipour
Buried by Robin Merrow MacCready
Roses in the Sand by CS Patra