With each trading system having proprietary product codes, with various in-house product codes being generated across the business, and with numerous industry classifications too, it’s challenging to assign to an instrument the right code for each purpose for which the product category or type needs to be known. Using a unifying financial product taxonomy to assign a standardized product code when an instrument is onboarded for trading is the nirvana, but most institutions are a long way from that.
As part of their drive towards oversight and accuracy, many Chief Data Officers, regulatory project or program managers and heads of data operations are looking to adopt the unifying financial product taxonomy strategy. With the potential for efficiency, straight through processing, and improving the trade lifecycle, risk management, product control and reporting, it’s no surprise that a common taxonomy across the institution has its appeal.
Trade execution product stamping
A usual situation among capital markets organizations is that after a trade has been executed the instrument needs to be assigned to a higher level product grouping in order to be managed properly for risk and regulatory reporting purposes, or to confirm which models should be used to value it. The trading system doesn’t provide the information and in most institutions the product code isn’t already stored among the reference data in a securities master. However, that code is needed, ideally before the trade reaches the trade repository. The process of assigning the code is sometimes referred to as product stamping, tagging or categorization, which has to happen at near-real-time speeds when any consuming system or process calls for the standard product code.
Internal and system vendor product classification hierarchies and industry classification schemes, which are particularly important for reporting, need to be understood, mapped and standardized in order to ensure accurate and timely regulatory reporting. For example, MiFID II and FRTB are regulations for which calculations and reporting depend on being able to assign or bucket eligible products. For this, an enterprise-wide financial product taxonomy is ideal.
Practicalities of a financial product taxonomy
Financial products are everything a bank sells to its customers, including to investment banking and commercial banking clients. A broad range of business lines necessitates an extensive systems’ landscape and involves multiple internal and external financial product classifications, including industry schemes such as ISDA and CFI. A fit-for-purpose financial product taxonomy must manage the complexity related to all products and all classifications.
Granularity is a particularly important factor when seeking to standardize classification schemes. BCBS 239 risk aggregation and risk reporting depends on a consistent product taxonomy throughout the enterprise. However, existing classification schemes vary both in granularity and the number of hierarchy levels. The granularity and hierarchy of a unifying financial product taxonomy must not only accommodate that, but also deliver the numerous hierarchy views demanded by different parts of the business, plus take into account the likelihood that any new business line or acquisition will bring with it more systems and data sets with additional classifications that need to be accommodated within the unifying taxonomy.
So what is required? A standard set of product codes available throughout the institution, driven by a central standardized taxonomy with granularity such that it is capable of identifying the unique structural feature of each and every current and future financial product. And all this has to be cross-referenced to all other classifications and hierarchies used in the course of business, now and in the future, unhindered by the hierarchy levels and the variety of nuanced product features that enable a unique attribute to be matched.
As with most things, maintaining a product code for each financial instrument is not without consideration beyond their static attributes. Product codes change over time due to variables such as date: e.g. it’s a ‘long term’ instrument if days to maturity are greater than 365; but changes to a ‘short term’ instrument when this becomes less than 365. Automating such changes, efficiently maintains the integrity of the classification process.
How do I know if I’m getting my financial product taxonomy right?
A measure of success of any product taxonomy initiative is the degree to which reporting deadlines and the service level agreements for internal customers are improving, e.g. regarding the completeness of product-related processes and compliance with CDO policies.
Increased straight through processing is another key indicator. With the financial product taxonomy in place, product lookup rules can be used to ensure the outputs from a system map to the attributes and domain values in consuming systems, avoiding process breaks or the need for reconciliations and exception management.
Doing business sooner is a significant commercial measure of success when new products are to be traded and sold. A faster, smoother onboarding of a product with an automatically assigned product code means a faster time to market and less remedial administrative effort down the line.
Finally, knowing that the bank’s standardized product codes are recognized in its security master, positions and transaction repository and entity master, also ensures a complete and consistent picture wherever and whenever product-level information is needed across the institution.
What needs to change?
Most institutions recognize that their processes for classifying products have room for improvement. And most know that it’s not sustainable to continue reconciling product codes at numerous points in trading, analytic and reporting processes. Maybe now is a good time for a financial product taxonomy that will carry the business forward more efficiently.