Financial Markets Operations Management (15 page)

We saw earlier that we can codify financial instruments through the use of CFIs. This tells us nothing, however, about how financial instruments are typically cleared and settled.
Table 3.7
shows a template for a country's central counterparty(ies) and central securities depository(ies).

Reference data can be captured from a variety of different sources that range from the counterparties themselves to specialist information vendors which provide market data and securities reference data.

Information on counterparties and customers can be obtained by approaching the entities directly. Some information will be in the public domain (e.g. annual report and accounts) whilst other information will be confidential (e.g. custodian/bank account details for securities and cash). Where possible, information verification is desirable as part of the due diligence process, especially with regards to know your customer (KYC) and anti-money-laundering (AML) regulations and requirements.

Investment managers, brokers/dealers and custodian banks can automatically share accurate account and standing settlement instructions (SSI) information worldwide by interfacing with the Omgeo ALERT system. The interface is either web-based or direct using Java API. Omgeo is a wholly owned subsidiary of the Depository Trust & Clearing Corporation.

Information on securities can be obtained from a variety of sources, including the issuer (either direct or through its prospectus/offering circular), the appropriate central securities depository, custodians and market participants such as market makers and brokers. This is a rather laborious and time-consuming task. A more efficient alternative is to download the information from one or more information vendors, and some examples are noted below.

You will see a list of information vendors, together with their URLs and a selection of their services, in
Table 3.8
.

Data management refers to the governance, oversight and monitoring of data to ensure accuracy and consistency. Information can become redundant and therefore a high degree of manual maintenance is called for. There is a risk that different departments within an organisation might very well be acquiring, maintaining and using the same information. This can lead to information redundancy. Information coming into the organisation needs to be verified for accuracy, which, again, calls for a high degree of manual maintenance.

There are three traditional approaches to data management:

• Transactional:
  Process-based, known as
  extract, transform and load
  (ETL). ETL systems obtain data from multiple sources using different data structures across multiple financial instruments.
  
• Analytical:
  Storage-based, known as
  warehouse
  . In a warehouse-based system, all incoming information is held within a common data structure. This requires the information to be processed in order to fit this structure; in addition, it might be difficult to include complex financial instruments that may not fit within the structure.
  
• Hybrid:
  A combination of ETL and warehouse designed with the best features of both approaches. The disadvantages might include the pre-processing of data before they enter the warehouse and/or the re-structuring of the data as they leave the warehouse.
  

The logical process from data acquisition to data delivery must include appropriate levels of maintenance and support within the following stages:

1. Data acquisition from multiple sources including information vendors and counterparty/ customer data systems.
   
2. Matching to ensure a consistent view of security, issue, counterparty or customer.
   
3. Validation of incoming data to ensure accuracy, completeness and quality.
   
4. Composition, where the data are made to fit within the users' data structures.
   
5. Data made available to those authorised to use them, for example, the trading desks, the operational departments and data management maintenance teams.
   

Before we turn to the final section in this chapter, recall that we recognise certain “entities” using a unique identification number. For example, there are several types of entity listed in
Table 3.9
.

With the exception of number six, all the above entity types have a unique identification system. This might suggest that we do not need a unique identification system, as we could record individuals, counterparties and customers by their name plus our own version of a short name and account number.

However, this would give us some potential problems, as the following examples will illustrate:

• There is no standardisation as to the number of letters contained in a name.
  
• The order in which names are quoted can vary, e.g. given name(s) followed by family name or family name followed by given name(s).
  
• An organisation such as the World Bank can also be recognised by the acronyms IBRD and BIRD. Furthermore, does it make a difference if it is IBRD or I.B.R.D?
  
• Many companies maintain a complex organisational structure, each unit of which has different business objectives. Banks, for example, can be structured as commercial banks, investment banks, insurance companies, asset managers, credit card companies, customers of other banks, etc.
  
• All these entities can be customers of more than one supplier, and each supplier will know its customer using an internal identification system.
  

With this “ad hoc” way of identifying these entities, there is every chance that entity details may be duplicated or mis-categorised, or that the entity's risk profile may be understated from a country or global perspective. What is required, therefore, is a unique identification system that allocates one ID to an entity no matter where the entity is domiciled or where in the world it undertakes business. The entity's risk exposures should be collated from all its global exposures.

The International Standards Organization's ISO 17442 refers to Entity §6 (in
Table 3.9
above) as a
legal entity
. Legal entities are defined as those entities that are legally or financially responsible for the performance of financial transactions or have the legal right in their jurisdiction to enter independently into legal contracts.

These entities therefore include:

• Financial intermediaries;
  
• Banks;
  
• Finance companies;
  
• Issuers and guarantors of all asset classes;
  
• Entities listed on exchanges or trading venues;
  
• Counterparties;
  
• Investment vehicles (including umbrella structures);
  
• All entities under the supervision of a financial regulator and their affiliates, subsidiaries and holding companies.
  

In 2012, the G20 group of leading nations mandated the Financial Stability Board to co-ordinate the establishment of a global LEI system. The FSB published a number of principles together with 35 recommendations for the development of the GLEIS.

The GLEIS is structured in three operational levels (see
Figure 3.3
).

• Regulatory Oversight Committee:
  Financial regulators from jurisdictions across the globe.
  
• Central Operating Unit:
  Co-ordinates and oversees the actions of local operating units.
  
• Local Operating Units:
  Responsible for assigning and maintaining LEIs. They are based in their national jurisdictions and sponsored by their local regulators.
  

Until the GLEIS becomes operational, an interim stage has been agreed whereby local regulators will authorise a “Pre-LOU” to issue “Pre-LEIs”. In due course, the pre-LEIs will be converted into official LEIs.

ISO 17442 has specified that each LEI must be a 20-digit, alphanumeric code, guaranteed to be unique, which provides access to key reference information and enables clear identification of the company concerned.

These 20 digits are made up as follows:

• 01 to 04: A prefix assigned to each LOU;
  
• 05 to 06: Two reserved characters set to zero/zero;
  
• 07 to 18: A randomly generated alphanumeric code;
  
• 19 to 20: Two check digits (as described in the ISO 17442 standard).
  

Table 3.10
shows the structure of an LEI and
Table 3.11
an example of an LEI.

The LEI contains the following reference data:

• The official name of the legal entity;
  
• The address of the headquarters of the legal entity;
  
• The address of legal formation;
  
• The official business registry where the foundation of the legal entity is mandated to be recorded on formation of the entity, where applicable;
  
• The reference in the official business registry to the registered entity, where applicable, e.g. company registration number;
  
• Last updated date;
  
• Previous legal name (if applicable);
  
• Date and reason for expiry.