Classifying financial products:
structure, structure, structure
Marc Gratacos (TradeHeader)
Regulatory reporting is requiring the use of product category codes, also called product taxonomies, while submitting financial transactions. From a regulator’s perspective, the categorization of the product facilitates data aggregation and the ability to query the data and extract risk measures. However, there is no standard product category or taxonomy list. Each standards organization, regulator, service provider, bank, asset manager, or custodian is managing its own financial product taxonomy or multiple at the same time. And the number of taxonomies is increasing every day.
Examples of taxonomies include:
ESMA Asset Class, Sub Asset Class – http://www.esma.europa.eu
ISDA Taxonomy (FpML codes) – http://www.fpml.org/coding-scheme/product-taxonomy-3-0.xml
FpML simple product type – http://www.fpml.org/coding-scheme/product-type-simple-1-5.xml
Internally, financial institutions may use product taxonomies for processing of transactions. For example, banks use product codes to route transactions in a message bus, to query the data, and to send the appropriate trades to the appropriate outside systems such as confirmations platforms and trade repositories. However, firms need to integrate taxonomies from different vendors and systems. Mapping product taxonomies requires significant resources with specialized product knowledge and analysis. Each vendor has its own classification using a different granularity. Financial institutions use internal canonical classifications and reference data translation systems in order to convert the product codes from and to the canonical values.
Mapping Codes vs. Analyzing Structure
We are seeing two main approaches to the firms’ problem of supporting multiple taxonomies:
- Mapping Codes
- Analyzing Structure
The first approach is mapping product type codes between different taxonomies. This is a difficult and costly task. Sometimes the definitions of the codes are not clear nor precise hence it becomes difficult to compare the meanings of codes from different taxonomies. In addition taxonomies may use different levels of granularity, making it impossible to have a one to one mapping between the codes.
The second approach is analyzing the structure of the product to assign the appropriate product type code. This approach not only is based on analyzing the structure of the message but also some of the values inside the message. For example, sometimes we need to analyze the floating rate index of a swap to know whether it is an OIS swap.
Another important point regarding structural analysis is filtering at various levels. In order to fully identify the product we may need to follow a set of intermediate steps to extract all product features. For example, to categorize a product as an asset swap, we will need to identify first whether it is a swap and then whether there is a reference to a bond asset.
Finally, last but not least, structural analysis depends on data quality. It’s impossible to fully categorize a product if the message doesn’t contain all data or data is wrong. That is the reason why data validation before applying structural analysis is critical. Data validation includes structural and business rule validation to ensure the product is correctly described. Working with clients we have found that implementing efficient business rule validation avoids many internal and external data issues.
Samples, samples, samples
Product categorization involves comparing products that may be structurally very similar in 99% of their features but the remaining 1% makes them a distinct product. In these scenarios testing becomes imperative to make sure the categorization tool works correctly. For testing a good set of samples is essential.
There are a couple of strategies to get samples for testing:
- Getting samples from real transactions
- Generating samples automatically
Both strategies are complementary; we want to test the product classifier with real data. At the same time, we may be interested in testing the classifier with high volume of data and with additional product variation not covered by the real transactions.
In order to generate samples automatically, we created a Sample Generator too. This application is capable of generating thousands of valid FpML messages. Business logic is coded in the application to be able to generate random examples that make business sense.
We have been looking on how open standards such as FpML, FIX/FIXML, and ISO 20022 cover all these product taxonomies. We found issues with the current version of the standards to cope with all these classifications. For example, some of the standards have a single Product Asset Class field and this is an issue if the message contains multiple classifications. That is the main reason why standards are creating regulatory specific structures to represent all these jurisdiction data elements. We find a good example of these types of structures in FpML, which includes a reportingRegime block. The structure is repeatable and can support multiple jurisdictions at the same time:
Our approach is to facilitate product classification as much as possible ranging from consulting to actual product development. Firms find it difficult to work with different standards and formats and having to produce and consume them.
The proposed solution is a Product Classifier tool that analyzes the structure of the message, including business validation, tested with a rich set of samples and outputting the right format with the classification codes in the right place.
Expertise in complex financial products and data standards is limited. In this current environment, where regulators are asking firms to classify trades in multiple taxonomies, tools that allow you to identify and classify products become important in order to facilitate regulatory reporting.