Critical to the success of F2 is the creation and adoption of a specification that allows F2 Apps to be catalogued for the purpose of inventory management. This specification, called the “F2 Registry,” would be compatible with both the F2 Container and F2 App specifications, and would provide a means for Registries created and maintained by individual firms to communicate with one another.
In building an F2 Container or set of F2 Apps, a developer and a product owner will quickly encounter a need to manage a listing of those Apps. A listing is necessary in order to avoid duplication of Apps, encourage reuse of Apps, and provide a mechanism to discover Apps within a firm or to the public at large.
For a developer, such a listing could be as simple as a JSON list of App manifests inside of a Container or collection of Apps. For a product owner, it would require a user interface built on top of that JSON list, providing a visual catalog of Apps, their descriptions, data sources, and more.
Consider, however, that a Container owner might need Apps from multiple App providers, and that App providers need to supply Apps to many Container owners. In that scenario, each Container owner would need a Registry of their Apps (a "storefront"), and each App provider might need a Registry of all of the Apps they have available (a "warehouse").
At the same time, Container owners and App providers have different needs. App providers want to make new Apps available in their Registry; potentially create both public and private spaces; and provide entitlement controls. Container owners want controls over which Apps are released to their production environments as well as which are made available via internal App registries. Container owners have varying degrees of compliance review and release schedules; App providers have a vested interest in getting their Apps out as quickly as possible, and need to comply with policies of the various Containers to which they supply Apps. Not only do Container owners and App providers have different perspectives on App review, privacy, availability, discovery, and security; individual Container owners have different perspectives from one another on these same issues, as do individual App providers.
A single Registry for a Container or App collection is too constrained to address these solution differences. Therefore, if multiple financial data providers want to provide Apps to a single Container owner (or multiple Container owners), a broader, networked registry of those Apps is needed.
In exploring this problem with the F2 Advisory Board, we determined that the problem as it exists within F2 is different from the problem addressed by Apple’s App Store or Google’s Play Store, each of which provides a centralized repository of Apps with differing standards of quality control and approval. The financial services industry has a need to maintain multiple registries of variant privacy -- some private, some public, and some that communicate with one another.
F2 recommends a networked App Registry model wherein each participant in the F2 ecosystem hosts and maintains its own individual App Registry. These various App Registries will be configured to allow for interoperability, communication, and synchronization. This approach has several benefits:
To support this model, F2 proposes the following:
The Advisory Board has further identified a number of additional enhancements to the F2 spec, outside of the immediate scope of the F2 Registry, but necessary for the long-term success of the F2 initiative:
The following items are not a part of F2’s Registry specification, roadmap or plans:
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 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.
There are several scenarios that illustrate the need for a universal identifier within an F2-enabled solution.
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.
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.
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.
The following are the requirements for an effective F2 Identifier:
The following are not necessarily requirements but would make the F2 Identifier more useful:
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.
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.
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.
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.
The following is an API request when a search is performed using the ISIN for Microsoft.
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.
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.
F2.UI.Modals. This is the only place Bootstrap code is actually used within F2; the majority of Bootstrap's inclusion is in the specification.F2.UI.Modals. However we've seen and heard about recent implementations where Modals have not been required in the solution thus leaving the door open for separate parties to mutually agree on using Bootstrap 3 code conventions for more "modern" development. In fact, we've done this ourselves on the new F2 website! To make this point even more clear, no F2 code needs to be modified to use Bootstrap 3 today. Simply get the F2.no-bootstrap.js custom build of F2.js, understand you won't be able to use Modals, and push all involved parties to agree on the Bootstrap 3 styleguide.
CONTAINER_SYMBOL_CHANGE event in F2 when you tap on a result. (All of the apps are already listening for that event per the F2 specification.)