Climbing the regulatory reporting mountain

Introduction

With the pressures around regulatory compliance only continuing to intensify, the critical role played in the reporting of financial transactions by product category codes has come into ever sharper focus.

Product categorization involves comparing products that may be structurally very similar in 99% of their features – it is the remaining 1% that makes them distinct. From the perspective of a regulator, the categorization facilitated by these codes – or taxonomies – facilitates at once data aggregation, transparency through the ability to query that data, and the extraction of risk measures.

Requirements

Deep domain knowledge and expertise in complex financial products and data standards are often limited within many financial institutions. In the current environment, with regulators asking firms to classify trades across multiple taxonomies, having access to the right tools to identify and classify products is key.

Financial institutions may deploy product taxonomies internally for processing transactions – for example, banks use product codes to route transactions in a message bus, to query data, and to send trades to the appropriate external systems such as confirmations platforms and trade repositories.

Challenges

However, there is no ‘standard’ list of product categories or taxonomies. Individual standards organisations, regulators, service providers, banks asset managers and custodians manage their own financial product taxonomy, or indeed multiple taxonomies simultaneously. And the number of taxonomies is increasing every day – among them the Classification of Financial Instruments (CFI) from the International Standards Organization (ISO); ESMA’s Asset Class and Sub-Asset Class; and ISDA’s Product Taxonomy codes.

The further challenge for firms lies in integrating taxonomies from different vendors and systems. Mapping product taxonomies requires significant resources and specialized product knowledge and analytical skills. Vendors have their own classifications, each of a different granularity. Financial institutions use internal and reference data translation systems in order to convert the product codes from and to these canonical values.

Firms are attempting to tackle the challenge inherent in supporting multiple taxonomies in two ways: mapping codes and analyzing structure.

Mapping codes for different product type between different taxonomies – is a difficult and costly task. Sometimes the definitions of the codes are not clear or precise, at which point it becomes difficult to compare the meanings of codes across different taxonomies. Moreover, those taxonomies may also use different levels of granularity, making a one-to-one mapping difficult between the codes.

Analysis

Analyzing the structure of a product allows the appropriate product type code to be assigned; this also entails analysing some of the values inside the message – for example, analyzing the floating rate index of a swap to determine whether it is an OIS swap.

Filtering at various levels is another key element of this analysis. Clearly identifying a product requires working through a set of intermediate steps to extract all the product features – again, as an example, to categorize a product as an asset swap, the first step is to determine whether it is a swap; the second step, which is determining whether there is any reference to a bond asset.

Last but not least, structural analysis depends on data quality. It is impossible to fully categorize a product if the message doesn’t contain all the data, or that data is wrong. Hence the critical importance of undertaking data validation – which includes structural and business rule validation to ensure the product is correctly described – before applying any structural analysis. Real-world experience has repeatedly shown that the implementation of efficient business rule validation allows firms to avoid many internal and external data issues.

Testing

Testing the integrity and effectiveness of product categorization tools is key, and accordingly a robust set of samples is essential. Two options exist when it comes to identifying samples for testing purposes: samples can either be extracted from real transactions, or they can be automatically generated.

Both strategies are complementary. Ideally you will want to test the product classifier not only with real data, but also with a high volume of data that encompasses additional product variations not covered by the real transactions. As an example, TradeHeader’s Sample Generator is capable of generating thousands of valid FpML messages, using business logic coded into the application to create random examples that make business sense.

Multiple classifications

A notable challenge is that while the current versions of open standards such as FpML, FIX/FIXML, and ISO 20022 cover all these product taxonomies, they struggle to accommodate these classifications. Some have a single Product Asset Class field, which clearly presents a problem if the message contains multiple classifications.

This is why those standards are creating regulatory specific structures to represent the full breadth of jurisdiction data elements. A good example of these types of structures can be found in FpML, in the form of a Reporting Regime block; the structure is repeatable, allowing multiple jurisdictions to be supported simultaneously.

Attacking the problem from different angles

Firms find it difficult to work with different standards and formats, in terms of producing and consuming them. The effective facilitation of product classification requires a number of disciplines, from consulting to actual product development, and demands a tool that analyzes the structure of the message – including business validation – and tests it with a rich set of samples, ultimately outputting the correct format with the classification codes in the right place.