CROSS-ASSET UNIVERSAL PRODUCT IDENTIFIER: is this the solution the industry is looking for?

  • 319

    CROSS-ASSET UNIVERSAL PRODUCT IDENTIFIER: is this the solution the industry is looking for?

    Covering the entire spectrum of asset classes and financial services, from loans and credit cards to derivatives and bond positions, a Universal Product Identifier (UPI) will enable a holistic approach to identifying all trades and positions, including capital calculations, reporting, clearing mandates and booking rules. While such an idea sounds great in theory, historical attempts at achieving global agreement have fallen short, even within a subsector of the industry. Peter Meechan, Jim Bennett and Pauline Tykochinsky examine the feasibility of universal product codes, ponder whether the industry is ready to come together to create them, and discuss what a potential solution might look like.

    During the past few years, firms have had to deal with a series of global regulatory changes, including the Dodd-Frank Wall Street Reform Act in the United States; along with European Market Infrastructure Regulation (EMIR), Markets in Financial Instruments Directive (MiFID) and Regulation (MiFIR) in Europe; and reporting and clearing requirements in Asia.

    These have resulted in numerous international regulatory bodies enforcing a series of new regulations for various jurisdictions, such as the Commodity Futures Trading Commission (CFTC) and Securities and Exchange Commission (SEC) (US), European Commission (EC) and European Securities and Markets Authority (ESMA) (Europe), Swiss Financial Market Supervisory Authority (FINMA) (Switzerland), Federal Financial Supervisory Authority (BaFin) (Germany), Financial Advisory Committee (FAC) (China), etc., to ensure transparency of trading activities and reduce systemic risk.

    A key area of change has been in the over-the-counter (OTC) derivatives space where new mandates that involved real-time trade reporting and mandatory clearing highlighted a major problem for all firms—product identification.

    Many of the regulations are tied to individual product types. For example, some products need to be reported to the CFTC, whereas others need to be reported to the SEC; some products must be cleared with a central counterparty, whereas others can remain bilateral. The problem lies in the definition of the products. The nature of the OTC derivatives industry means that many products have evolved over time to become highly customized for individual client needs and there is little standardization across firms as to how a product is defined or named. What one firm calls product ABC, another may call DEF. Making matters worse is that the regulator may call the same product XYZ. Anyone who has worked on implementing the new Dodd-Frank rules will have experienced the difficulty of deciding which rules applied to which trades and positions and how such trades needed to be classified when reporting.

    While the problem may have been brought to light by the implementation of rules for OTC derivatives, it also exists within a range of asset classes, including loans and mortgages. It is an issue that runs across asset classes for functions that need to include all of a firm’s positions but treat them differently based upon product type. A key example of this is with capital treatment, whereby calculations need to be treated differently based upon product but aggregated across all of the firm’s positions.


    The ideal solution to this problem would be a standardized way of referencing each product, based upon a set of differentiating attributes that are understood by both the industry and global regulators. Standardized identification exists today in other asset classes, such as the International Securities Identification Number (ISIN) for bonds, commercial paper (CP) and warrants. But, could such an identifier also work for areas that have historically resisted standardization and could disparate areas of the industry come together to utilize a single standard?

    There are many types of problems a Universal Product Identifier (UPI) could address. The complexity of the UPI could differ depending upon which use cases were included. Each type of market participant has a different level of interest in solving for each problem, so a consensus needs to be reached. Problems that have the most interest include:

    • Product/trade identification—What do we call this when executing, reporting or booking?
    • Capital calculation treatment—How do we calculate capital for this position?
    • QIS categorization—How do we categorize this position during quantitative impact studies?
    • Regulatory body and rules for trade reporting—Where and how do we report this trade?
    • Mandate to clear and where to clear—Do we need to clear and what are our CCP options?
    • Mandate to execute via a SEF—Do we have to offer this trade on a SEF?
    • Mandate for collection of margin—Do we have to collect/pay initial margin?
    • Booking rules—What system do we book this trade on and to what legal entity do we book it?
    • Short sale—Handling different levels of restrictions known as E-codes across various jurisdictions.
    • Tax—Consolidating several tax laws such as transaction tax, stamp duty, etc., across countries.
    • Cost Basis Rule (CBR)—Supporting long-term gain/loss reporting (IRS).

    The difference in each of these issues is the level of detail that needs to be attached to a UPI to determine the outcome. For example, the attributes required to determine if an OTC trade is CFTC or SEC reportable are different than the attributes required to determine if such a trade must be cleared. In other words, the UPI needs to be tied to a taxonomy. But questions remain. Does this taxonomy need to be completed prior to solving for each case? Can the same taxonomy structure be applied to all uses cases (just at a different level)? Or, does the structure need to flatten out? Figure 1 depicts the start of a possible hierarchy in which the number of layers required is dependent upon the use cases for which the hierarchy is to be utilized.

    Figure 1. Sample Product Hierarchy

    Another challenge in categorizing some asset classes is the requirement for dynamic classification that is triggered by a recent security event. For example, some regulatory disclosures require a more granular classification of loan products driven not only by the initial contract agreement but also by certain subsequent life cycle events. These could include default on payments; some operational specifics in booking the product, such as held-to-maturity versus available-for-sale; operation loss events; and certain risk metrics, such as fair market value (FMV), etc. Similarly, commodities options require information about the last tradable date to assess exposure and capital requirements.

    With certain credit products (e.g., credit indexes), the regulatory treatment of the product changes based upon the number of names at time of execution. Therefore, a product traded one day could be reportable to the CFTC, and the same product traded a week later could be reportable to the SEC. One way to address this is to limit the hierarchy of the product to data points that are fixed and leave dynamic items to the transaction. This would make for a simplified product taxonomy, but adds an additional set of criteria to be used in regulatory determination. As such, it does not solve the entire problem.

    Key to deciding upon the use cases is to determine the scope across asset classes. For example, can a UPI provide solutions across OTC derivatives or across all areas? A cross-industry sector UPI would certainly help when calculating capital, but implementing such a solution across areas that already have their own IDs (e.g., securities) raises its own set of problems.

    Solving across all asset classes is a lofty goal, but one that can be achieved. However, it is better to start with one area—such as OTC derivatives which has the most diverse set of products and the most pressing need from a regulatory perspective—and then expand to other areas. This means that when any solution is being designed, the end goal (one of true universal acceptance across asset classes) needs to be considered. This way, the solution can be extended rather than redesigned during each phase and some level of input would be required from all sectors at all stages of design and implementation. If a particular industry sector solves the problem in isolation, it will have a difficult time trying to force its design on an industry sector that already has some form of identifier.

    The final prerequisite is involvement from the regulators. It is pretty clear that most of the use cases revolve around the regulatory treatment of trades and positions. The UPI will only be effective if the regulators that decide upon the treatment are using the same taxonomy to make their determinations. Therefore, their endorsement is as critical as industry acceptance.


    When it comes to UPI issuance, there are three basic ways that it can be handled.

    1. UPIs are only issued by a centralized issuing entity. Product details (the defined set of attributes) are sent to the entity by either industry bodies (e.g., ISDA) and a new ID is published. This has the advantage of ensuring that there is no duplication of products but requires that a product taxonomy be fully defined prior to UPIs being issued. And, it means that either new products would be traded without a UPI or a method of assigning temporary UPIs must be defined.
    2. UPIs are sold in batches to organizations that may create new products (e.g., swap dealers). The organization assigns the UPIs themselves and returns the assigned UPI with product attributes to the issuing organization for validation and distribution. This has the advantage of providing dealers with the ability to create on-the-fly custom products and trade them with a UPI. The disadvantage is that other firms could assign their own UPIs to identical products, causing product duplication.
    3. Similar to option 2, UPIs are assigned by the dealers first trading the product. However, instead of a batch of numbers being purchased and later assigned, the numbers could be generated and assigned by the initiating dealers using an algorithm that ensures uniqueness. An example of this would be including a code that is unique to the dealer.

    Whichever method of implementation is chosen, the industry needs some form of market utility (or group of utilities) that would be responsible for distributing UPI information on behalf of the issuing entities. Figure 2 depicts how a centralized UPI utility (or series of utilities) could be used by the industry to generate UPIs and act as a UPI look-up service, working alongside the regulators.

    Figure 2. An Example of How a Centralized UPI Utility could be used to Generate and Manage UPIs

    Defining a new format for a universal code in one sector of the industry (e.g., OTC derivatives) and then trying to get another established sector to adopt it (e.g., securities), would be extremely difficult. However, there is little
    need to do this. There is no reason that each sector cannot maintain its own format and even generate and
    distribute its own identifiers, as long as each sector does the following:

    • Has identifiers that do not match those used by a different sector
    • Establishes an easy method of understanding which sector the identifier comes from by the format
    • Provides a centralized report of all identifiers across all industry sectors

    In other words, organizations generating the identifiers need to work together.


    Funding for a UPI utility or service would depend upon the method used to generate and distribute each UPI. If it is up to dealer firms to assign UPIs to products that they themselves create, then they could purchase blocks of blank UPIs, in a similar manner to how a grocery producer buys a block of UPCs (bar codes). However, if a centralized UPIgenerating organization creates and assigns all UPIs, then they would need to charge users of the service either a monthly fee or a transaction cost for retrieving UPI data.


    A UPI has long been thought of as an unattainable goal within the OTC derivatives industry and other non-standardized industry sectors. However, as regulations increase in these areas and become more product specific, the benefits of a UPI become more apparent. A key focus of much of the recent regulatory reform has been on the standardization across asset classes. With the move towards electronic trading and growth of straight-through processing (STP), market utilities and clearing demand this. A UPI would not only provide a catalyst to standardization but standardization would itself benefit from the introduction of a UPI, producing a self-improving circle. For the UPI to be successful, industry leaders need to first agree upon the problems that are being solved and the regulators need to be on board.

    The Authors
    Peter Meechan

    Peter Meechan
    is a Director of Business Consulting based in New York City. With over 20 years of cross-product, investment bank experience in business transformation, he has played leading roles in the development of several products, services and consortiums. Recently, Peter has been helping large investment banks implement changes required by regulatory reform and working with a range of industry participants to launch market utilities for client clearing and collateral management.

    Jim Bennett

    Jim Bennett
    is a senior executive based in New York City with more than 25 years of experience in capital markets, OTC and complex products. With a strong international background, Jim has helped firms navigate new regulations and adapt to changes in the global marketplace.

    Pauline Tykochinsky

    Pauline Tykochinsky
    is a Senior Manager in Sapient Global Markets’ Data Management Practice. Based in New York City, Pauline has over 16 years of experience delivering highperformance enterprise solutions. In her current role, Pauline applies her in-depth knowledge of the trade lifecycle when advising global firms on data modeling, data architecture and data governance approaches and best practices.

    Leave a Comment