Tuesday, August 18, 2015

F2 Registry - Organizing and Connecting Containers and Apps

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.

The Problem

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.

The Solution

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:

  • Allows any Container owner, App provider, or App Registry provider to maintain their own rules and controls around App privacy, App review cycles, entitlements, pricing, whether they provide Apps via a storefront, etc.
  • F2 provides common denominator items such as App title, App manifest, and App provider to ensure consistency
  • New entrants, whether Container owners, App providers, or App Registry providers can participate in the F2 ecosystem with minimal technical friction, aligning with F2’s goal of “the best App wins”
  • In the below example, F2 Registries are labelled as “App Marketplace” and “App Warehouse” respectively, demonstrating the differing needs of Container owners and App Providers.
Screen Shot 2014-09-16 at 4.25.50 PM.png

To support this model, F2 proposes the following:

  • Creation of an F2 project under which F2 Registry will be created and will solicit contributions from the open source community
  • Creation of an F2 specification for App Registry
    • Definition of inputs and outputs for RESTful JSON APIs
    • APIs would be built & hosted by App Registry Providers adhering to spec
  • F2 Specification additions on how F2 Apps can exist in any App Registry
  • Specification on how an F2 Container can connect to an App Registry
  • Documentation on how an F2 App can be submitted into and managed within an App Registry
  • Documentation and specification on how App Registries synchronize with one another
  • Reference examples of how an F2 App Registry can maintain a list of apps from multiple providers, connect to multiple containers, and connect to other registries

Proposed Future Enhancements

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:

  • Single Sign On (SSO)
  • Identity - symbology, users, and entities
  • Entitlements - first phase with “trusted partners” (i.e., no official entitlements)


The following items are not a part of F2’s Registry specification, roadmap or plans:

  • Hosted services (API spec/definition only)
  • Hosted App store

Monday, June 8, 2015

F2 Identity - a Solution for Financial Services Symbology and Entity Identifiers

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.


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.

Friday, April 10, 2015

F2 Version 1.4.0 Released

The F2 Team is happy to announce the release of version 1.4.0! This marks the end of a long series of updates and includes some great enhancements to the framework. Version 1.4 is the first release of 2015 and the first major release since October 2013.

First and foremost, the documentation has been redesigned and overhauled. It now matches the refreshed design on OpenF2.org and features two new landing pages (Developers and Getting Started) aimed specifically at technology teams. These new pages answer many questions we've received over time and provide quick access to demos, source code, and community resources.

Enough, let me get F2.js!

In reviewing the milestone for version 1.4, the team worked through nearly two dozen Issues, produced 163 commits and changed almost 500 files in the repository. The goals for this version were as follows (with some additional detail below):
  • Simplify App integration
  • Add i18n support
  • Tune performance of App dependency loading
  • Update 3rd party dependencies
  • Fix outstanding bugs/issues
  • Redesign docs to match new website

Simplify App Integration

The team added all-new functionality to make loading Apps much simpler. The functionality is called "App Placeholders" and allows developers to write an HTML element with data attributes. Abracadabra, F2.js does the rest! Read about Placeholders in the docs.

Internationalization ("i18n")

This addition was requested frequently and the implementation design was led by Advisory Board member Pershing/BNY Mellon. Internationalization allows for defining the region and language targeted at a particular user base. For example, "en-us" is the i18n setting for English-United States. Likewise "de-de" is the setting for "German-Germany". Full i18n support now exists in F2 for both Container and App Providers, read more in the docs.

App Dependency Loading

We added an internal map to track App script and style dependencies so that multiple versions of the same files are not downloaded by a Container. This not only loads the parent page faster, it also represents a more responsible App reloading process — something many firms are doing. Learn about the page load life cycle in the docs.

Update 3rd Party Dependencies

There are a handful of 3rd party dependencies bundled in F2.js. Version 1.4 updates those dependencies and brings with them all of the bug fixes, security patches and feature enhancements we all need and love.

Bootstrap remains a core part of the F2 specification and bringing F2 up to date with the latest Bootstrap version was critical for this release. All of the documentation and all of the example Containers and Apps (including the iOS demo) have been upgraded to Bootstrap 3.

Review the changelog in detail on the wiki.