Imagine the following: Mr. Trader has just bought 20,000 shares in Swiss Watch Company AG from Dealer A, and the order is handed to your back office on a piece of paper. Junior admin person, who had a late night last night, sleepily types in the details: 22,000 shares from Dealer B, and types in the wrong Valoren code. Unsurprisingly, the trade details are thrown out in the processing procedure and the trade cannot be completed until there is yet more manual intervention to figure out the correct number of shares, the counterparty details, and the accurate securities identifier.
This breakdown in data transfer means your firm has incurred additional costs due to the manual intervention, operational risk and lost opportunity. In this age of technical supremacy, can this scenario really happen?
The answer, unfortunately, is yes. Despite millions of dollars being spent on the integration of systems and middleware technology, still an astonishing one-quarter of all trades (and more in some cases) still fail on first settlement attempt. The majority of those trades are failing due to inaccurate, untimely or incomplete reference data.
We have increased the speed of information flow throughout the enterprise due to the implementation of technology, but the lack of attention to the quality of the data flowing through those systems has only led to ‘Automated Chaos’.
When the financial markets were booming, firms could afford to overlook the millions of dollars that the regular breakdown in the processing due to poor data was costing them. But with the tougher market conditions we’ve experienced over recent years, costs have been scrutinized, regulations tightened, and all against a backdrop of the drive towards straight through processing.
Hence the increased focus on reference data, which is an essential factor in enabling straight through processing, and is becoming more important as new regulations are enforced. The benefits of a cohesive strategy towards the management of reference data have been well documented over the past few years and include:
- Reduced trade failure
- Reduced costs related to manual re-keying of data and duplication of efforts
- Reduced operational risk
- Reduced number of missed trading opportunities
So just what is reference data?
Reference data is data that is used through the administration of a securities transaction, but through industry usage this term has taken on wider meaning than originally intended. As such it is now generally accepted to encompass static data, corporate actions data, securities identifiers, pricing data, and institutional or transaction data (see table 1). Many other data elements should also be considered when evaluating a reference data solution such as index data or ratings information.
Table 1
Two of these data types have received a lot of attention recently: corporate actions and securities identifiers. Corporate actions have historically been the least automated - and therefore more labour-intensive, error and risk-prone - areas in data processing within financial institutions. The term refers to information that affects the capital structure of a corporation, such as stock splits, right issues, or dividends.
The reason corporate actions processing continues to be the least automated area is due to factors including the many players involved in the processing cycle - from global and sub-custodians, to prime brokers, asset managers, and corporations, to data vendors and stock exchanges - as well as the multitude of formats the data is distributed in - such as fax, telex, email, and Swift, which is then often manually rekeyed into multiple spreadsheets. It is unlikely, however, that the entire corporate actions universe will ever be fully coded. This is in part due to the sometimes complex nature of corporate actions and their constant evolution as investment bankers explore new ways to structure corporations and improve the capital base. With the resulting variations and structural changes each day, it is difficult to fully code the data.
A survey of 242 firms in 33 countries jointly commissioned by Swift, Smartstream and CityiQ in May 2003 acknowledged the manually intensive nature of corporate actions. But it found that 57 percent of firms have at least some automation, operated by small teams of less than 10 people. A further 79 percent of respondents anticipated substantial automation across the entire corporate actions process. Forty-one percent of firms were considering automating the corporate actions process, although 51 percent of these were not expecting to select a solution for at least 12 months.
There are companies that provide a range of specialist corporate actions processing services, including ADP’s Wilco, Checkfree Heliograph, DTCC’s Global Corporate Actions service, Fidelity ActionsXchange, Mondas, Trace Financial, Vermeg, and XcitekSolutionsPlus.
Securities identifiers are essential in the flow of information for literally identifying the security that is being handled (see table 2). The problem here is that a single security can have multiple securities identifiers associated with it, but there is no unique identifier covering all necessary attributes of that security. This is largely due to the use of regional codes - Sedols, Cusips, Valorens, Sicovams - each of which has grown out of its domestic market. There are currently around 65 different national numbering agencies administering these codes. It is further confused by the different codes used in the front (typically data vendor codes, such as Reuters RICs) and back offices (more computer-based codes used for processing, such as ISINs and the local codes), which makes internal processing difficult and manually intensive.
But as with the increasing globalisation of the financial markets, these issues must be addressed in order to facilitate straight through processing. As recent analysis in a white paper published by the Reference Data User Group (RDUG) and Reference Data Coalition (Redac) [more on these below] found, three key elements are required to provide a unique instrument identifier:
- Unique issuer identification, used for security roll-up, risk management, overall position keeping and trading decisions.
- Unique instrument identification at the Official Place of Listing (OPOL), important for portfolio valuation, fungibility issues for multi-listed instruments, corporate action issues across OPOLs, risk across OPOLs/currencies, position keeping, settlement, VMU interaction (cross-bridge settlement, SSI) and arbitrage across currencies, markets and OPOLs.
- Trading identification at the place of trade, used for intra-day pricing decisions, arbitrage and market compliance.
The ISIN - International Securities Identification Number - was developed by the ISO Committee (ISO 6166) in 1969 to provide a uniform structure for a number that uniquely identifies securities to address the needs of global securities processing. The ISIN, which is maintained by the Association of National Numbering Agencies (ANNA) made up of the national numbering agencies, has been criticised for its lack of market-level identification, ie: OPOL. This is an issue that ANNA has recently decided to address by supplementing the ISIN with access to official place of listing (Opol) and Swift’s Market Identifier Code (MIC), with the resulting data identifying issues by location as well as by security.
This move appears to be in direct response to the London Stock Exchange’s expansion plans for its Sedol numbering system in a bid to establish the Sedol as a global standard. The plan is to move from a seven-character numeric code to an alphanumeric code, addressing the capacity issues that the LSE believed it would face with its existing structure. At the same time it is working to enhance its coverage and fill in gaps in global securities data.
Table 2
So how does this landscape translate into the business of supplying reference data?
Role of the Vendors
The business of data vendors providing reference data is by no means small. According to A-Team Consulting’s analysis the market totalled revenues in 2001 of $545.59 million (£373.69 at the time), or over half a billion dollars. Of these FT Interactive Data was estimated to have 52 percent of these revenues, followed by Telekurs Financial with 11 percent, Reuters (including the EJV bond evaluations business) with 10 percent, Standard & Poor’s with close to nine percent, and Bloomberg with eight percent. Other data vendors include Exchange Data International (EDI) and Fininfo.
Vendors are a crucial part of the information flow between originators (such as exchanges, local agencies, market participants) and the end users (see chart 2). Without the vendors each financial institution would have the cumbersome task of sourcing, integrating, quality checking, disseminating, and maintaining vast amounts of data. To do this requires major infrastructure and support operations, knowledge of the data, and increasingly of local markets, staff to liaise with information originators, and much more.
Not only can this prove costly to the firm, but it can also distract from the firm’s core abilities. Vendors act as an essential ‘middleman’, interfacing between the multiple sources and a financial firm’s systems. That said there is no once vendor that has the full range of data coverage or depth of attribute types needed to satisfy all client requirements. As a result, institutions typically need two or more data suppliers to fulfil their content needs.
Chart 1 - Source: A-Team Consulting, Ltd.
In selecting data vendors, considerations include: geographical coverage; instrument and asset class coverage; the infrastructure required on the client’s site; whether the data service integrates with off-the-shelf or a client’s proprietary software and applications; how the vendor charges for their service (by data type/geographical coverage subsets, databases, or data consumption); notice policy for clients of any systems or data changes; and customer service and responsiveness to data or product queries.
Also to be considered is how to combine the external data with data sourced internally, from counterparties, custodians and other parties involved in the investment process.
Financial institutions have taken a variety of approaches to sourcing and managing data, with many building extensive in-house systems and managing the process internally, while some others opt to outsource data management. As the sophistication of data management technologies improves, and the understanding of what third-party providers can offer deepens, the pace of outsourcing will likely improve. Outsourcing firms provide data selection, cleansing, integration and management services, and can add value by enabling comparisons across various sources.
There are a number of data management providers, including Asset Control, Cicada, Financial Technologies International (FTI), Fame Information Services (now part of SunGard), Soliton, and Xenomorph. Firms like DST International and Eagle Investment Systems have also extended and packaged their existing data management infrastructure that underpinned their software applications (in areas like portfolio management and investment accounting) to provide reference data management solutions to the market.
Data Integration with Software Providers
Managing reference data, however, cannot be considered in isolation. Just as firms should not implement software applications and technology solutions without considering the data aspect, implementing a data management solution cannot be done without considering integration with software applications.
The best of breed data management solution can be implemented but if, say, your portfolio management system does not know how to handle a particular corporate action fed by your data management system, chances are you will at best miss an investment opportunity or be tying up capital that could be better utilised, and at worst could be violating regulations and client agreements which may result in fines and client reimbursements.
Risk management is one of the key areas of opportunity, where the need to feed accurate and timely data into risk applications in order to produce the risk analysis required by regulators, particularly under the Basel II rules, has become apparent. In response to this, the data vendors are working to increase the interfaces between their data sources and the risk management and analysis software applications. In one example of close cooperation, data management firm Cicada has formed a joint venture with risk management software company Algorithmics.
In A-Team Consulting’s new reference guide Software Providers: Working with Reference Data, we surveyed 99 software providers across 11 operational areas (including portfolio management, performance measurement, investment accounting, risk management, corporate actions processing, order management, regulatory reporting, and more) to measure the level of integration between the data suppliers and software providers.
The results (see Chart 2) showed that FT Interactive Data, which has proactively worked on its relationships with software providers for many years, has the greatest level of integration, interfacing to 67 percent of software providers. Reuters integrates to 51 percent of software providers, followed by Bloomberg with interfaces to 41 percent. Telekurs Financial currently has interfaces to 33 percent of software providers, but the vendor is aggressively pursuing further integration deals and expects that with this development, their integration level will increase to 47 percent.
Chart 2 - Source: A-Team Consulting’s Software Providers: Working with Reference Data
Data Standards
While the utopia of industry-wide administration data standardisation is some way off, there are a number of initiatives that are aimed at making integration of reference data with software applications more standardized and therefore easier to manage.
The Reference Data User Group (RDUG) was formed in June 2002 by a number of institutions including asset managers, brokers and custodians, with the aim of evaluating options for reference data standards that can assist in automation and STP. Its focus is on ‘what’s deliverable in a reasonable timeframe’ where they can secure ‘quick cost effective wins’, according to RDUG. Similarly the Reference Data Coalition (Redac) is the U.S. equivalent, overseen by the Financial Information Services Division (FISD) of the Software and Information Industry Association (SIIA). Both RDUG and Redac are in cooperation and have discussed merging their efforts although nothing has yet been finalised.
Their focus so far has been on unique instrument identification (UII) and legal entity identification (LEI). In UIIs, the fruit of their labour was a joint white paper, which compared the current offerings in addressing the need for a UII (see section on securities identifiers above). This work was been passed onto ISITC, which in February 2004 created a new working group to define a best market practice recommendation.
In the legal entity identification area, which explores the issue of a lack of a common identifier for regulated entities, the groups published another white paper. Data is currently held in a multitude of formats by national regulators and exchanges, making it difficult for counterparties to identify the other side’s contracting entity. The aim is to create a LEI code, and the proposed definition has been passed to Swift, and debate continues within both RDUG and Redac, as well as via ISO’s Technical Standards Committee (TC68/SC4). The next area of focus for RDUG is corporate actions.
The FISD has also been heavily involved in overseeing the Market Data Definition Language (MDDL) initiative, which is a proposed XML specification for the interchange of information related to financial instruments. Version 1.0, covering equities, indices, and mutual funds, was released in November 2001. Version 2.0, covering corporate, municipal, government and agency bonds, was released in July 2002. It is now in ‘early adoption phase’, according to the FISD, and they are now working to promote the widespread adoption of MDDL. A core component of this plan is their efforts to integrate the MDDL vocabulary into the ISO 15022 data field dictionary.
Other organisations include the Association of National Numbering Agencies (ANNA), which maintains the ISO 6166 ISIN standard (see securities identifiers section above).
So the raised profile of reference data has resulted in a number of industry initiatives, which can only ease the problems associated with reference data management. Over the coming years we expect to see a broad adoption of standards, intelligent data management solutions and a higher quality of reference data flowing through our financial institutions.