We have been working closely with the F2 Advisory Board to study symbology, and the role F2 can play in a universal identifier that could work for both financial instruments and other entities. A Working Group was formed to further study this space, and we're pleased to share our findings, a proposal on how to address this problem, and a proposed technical implementation that could become available from F2 in the future.
Critical to the success of F2 is the creation and adoption of a standard, universal identifier that covers tradeable instruments and non-tradeable identifiable objects. The creation of such an identifier will allow F2 Containers and Apps to talk to each other and share information.
The Problem
The financial industry has yet to agree upon a universal symbology. There are hundreds of different symbol sets in use today by various financial services and financial media companies, including RIC, CUSIP, BBGID, ISIN, NSIN, Sicovam, SEDOL, Valoren and WPK.
The Object Management Group, partnering with Bloomberg, described the problem of proprietary symbologies in its July 2014 FIGI Beta 1 specification introduction:
The development of a Financial Instrument Global Identifier originated out of the recognition that chaos theory has nothing on the complexity generated everyday by the millions-perhaps billions-of security transactions that cross trading floors, clearinghouses and exchanges all over the world. Almost every aspect of securities management is based on closed systems that use proprietary identifiers that are privately owned and licensed. Closing each deal is as much an exercise in translation as it is in transaction processing, as traders, investors and brokers wrestle with multiple proprietary formats to determine what a security is, who owns it, how much it is worth, and when the deal should be closed. It introduces a tremendous amount of friction into the trade lifecycle and creates opaqueness where clarity is sought. In addition, the use of proprietary identifiers adds significant cost and overhead when users wish to integrate data from disparate sources or migrate to a different market data system.
The evolution of advanced symbologies has helped the securities industry grow, but the limitations and costs imposed by the closed systems have become more apparent as companies and institutions continue to integrate operations on a global scale. Proprietary symbology now stands as one of the most significant barriers to increased efficiency and innovation in an industry that sorely needs it.
Hypothetical Scenarios
There are several scenarios that illustrate the need for a universal identifier within an F2-enabled solution.
Scenario #1
An F2-enabled solution includes two F2 Apps—one from 'Content Provider' (CP) and one from 'Retail Brokerage' (RB).
The RB App displays a user’s portfolio holdings. The CP App can analyze a user’s portfolio with its Instant X-Ray portfolio analyzer. Using F2 Events and Context, the two Apps should be able to communicate with each other within the browser session and share the list of holdings in order for each App to do its job.
Today, for this communication to be successful, RB and CP would need to agree on which symbology would be used to pass the list of holdings prior to any in-browser communication. If 'RB' chose to use 'CP's symbology, RB's App could not be used with another portfolio analytics App, unless that other App happened to also use CP's symbology.
Scenario #2
Container provider integrates F2 Apps from multiple vendors; these Apps use F2 Events to share data as F2 Context. Each App party uses a different symbology.
Unless there is a service provider offering a cross-reference capability-as-a-service, here the Container Provider would need to dictate the preferred symbology and each App provider party must conform.
If a standard, universal symbology existed within the F2 specification, the Container provider and App providers would only need to conform to this F2-defined symbology in order for their solutions to simply work together. In addition, the Apps would be reusable in other F2-enabled Containers, meaning that App providers could create once and sell many times.
Possible Solutions
Adding a standard identifier to the F2 specification would drastically reduce the barrier of entry for F2 Container and App providers and increase efficiencies across firms developing F2-enabled solutions.
Requirements for Effective F2 Identifier
The following are the requirements for an effective F2 Identifier:
- Must be universally unique
- Must be persistent (not subject to change)
- Must be an alpha-numeric UTF-8 string (no special characters)
- Must not require a fee-based license
- Must account for existing standards (such as ISO or RiXML) for nonfinancial instruments
The following are not necessarily requirements but would make the F2 Identifier more useful:
- Includes standard identifiers for tradeable instruments across all asset classes, from fixed income to common stocks
- Includes other identifiable objects such as countries, internationalization locales, currencies and more leveraging
- ISO standards where applicable
Option #1: Use of Existing Standard for Universal Symbology
The F2 Advisory Board should first explore existing standards for universal symbology, and whether a universal symbology exists and can be leveraged for inclusion in the F2 specification. Current standards for possible evaluation include but are not limited to Bloomberg’s BSYM symbology and their BBGID identifier, as well as the International Securities Identification Number (ISIN). Only where a solution does not currently exist or is found to be inadequate should the Advisory Board look to create a new identifier standard.
If the Advisory Board is able to locate an existing identifier that fulfills the requirements outlined above, next steps would be to incorporate this Identifier into the F2 specification and implement the supporting web service in the manner described later in this document.
Option #2: Creation of an F2 Identifier
Another option is for Advisory Board firms contributing data to create and power an F2 Identity Specification & Service (“F2 Identifier”) that is created specifically to allow cross-communication among F2 Container and App providers. More detail on this option is provided on the following pages.
Considerations for creating a new identifier include: cost of adoption by both F2 Container owners and App providers (including symbol mapping to existing symbology) and maintaining the service that supports the F2 Identifier.
F2 Identity Spec & Service
Components of an F2 Identifier
An F2 Identity Spec & Service would allow App developers to use a single identity convention for financial instruments and allow for easier communication between Container and App providers. By way of example, the F2 Identifier for APPL might be “123456789.”
The F2 Identifier would be sourced from a database of identifiers allowing for quick and intuitive search of tradable instruments, regardless of issue classification scheme. It would allow both name- and description-based lookups for any underlying instrument and return a matching identifier (the “123456789” described above.)
An F2 Identity Service would require at least two components: (1) symbology provider(s) who contribute their data sets to a single database via feed or otherwise and (2) a firm who develops, hosts and maintains the web service (or API) that performs the cross-referencing and returns the F2 Identifier as illustrated below. In addition, it will require that the F2 Identity Specification is written and maintained in accordance with the existing protocol.
Use of Context with an F2 Identifier
The existence of a consistent F2 Identifier would allow Context to work most effectively.
Context refers to the information passed from Container to App, from App to App, or from App to Container. In the examples shown below, two types of Context are shown: symbol and trade ticket context. This illustrates in-browser messaging between two Apps.
CCurrently, the Event API in F2.js allows a collection of arbitrary name/value pairs to define the message. The below demonstrates a simple Context message where a container broadcasts a symbol change event. The Context message contains a symbol property. Given the wide array of symbol identifiers at play in the financial industry and the inherent problem with using a Street symbol, neither symbol nor AAPL is very useful programmatically.
In a future state, by using the F2 Identifier, F2 will enforce the name/value pair used as part of a symbol-based context message. In the example below, the name/value pair contains SecurityID and the integer representing "AAPL", 123456789:
This standardization allows for interoperability of Apps from various firms.
Proposed Technical Implementation
The following is an API request when a search is performed using the ISIN for Microsoft.
Note: service.openf2.org is an example hostname.
The following is a what would be returned in a scenario in which an F2 Identifier (here, the Identifier for MSFT is 205778) was present; the inline JavaScript comments define each property in the response, which is based on the field definitions in the FIX Protocol.
Summary
Next steps for F2 Identity include a vote by the Advisory Board to formally create a project, and a call for contributions in the form of technical resources, to build the service, write specification, and create documentation.
The end result is expected to be the creation and adoption of a standard, universal identifier that allows F2 Containers and Apps to talk to each other and share information, furthering the goal of F2 to allow financial services firms to work together seamlessly.
