Friday, September 30, 2016

F2 Hacktoberfest is Here!

F2 will be participating in Hacktoberfest!

What is Hacktoberfest? It is an open source event sponsored by Digital Ocean and Github where if you issue 4 pull requests during the month of October you win a Hacktoberfest shirt.
We are encouraging all softwareware developers to get involved. Contributing to open source library is great way to get recognition as well become a part of the greater software development community. You can find out more at

Here are  the current list of issues tagged for Hacktoberfest as well as the list of F2 Hacktoberfest issues.

Good luck and Happy Hacktober!


F2 Technical Steering Committee
Quentin Rider - Markit Digital
Kaushal Amin - Interactive Data
Dan Collins - Morningstar
Lara Edwards – Markit Digital

Wednesday, June 22, 2016

F2 version 1.4.2 is Available

F2 version 1.4.2 is now available. This release mainly includes some small changes on how F2 is distributed and built. See the full changelog for details.

Change Log

  • Bower and Nuget install instructions in README
  • Fixed bug in Bower where Gruntfile.js was delivered with packages
  • Gruntfile now contains build task so that F2 can now be easily released.
  • CDNJS is now auto updated when the build is tagged.

Visit the following sources to download or install F2:

Monday, June 13, 2016

F2 version 1.4.1

Today we are excited to announce the release of F2 version 1.4.1.  This release includes a combination of bug-fixes, assembly changes, and the addition of bower. See the full changelog for details.

Change Log

  • Unable to install via npm due to preinstall requiring root access
  • Bower support
  • AppContent is undefined for pre-loaded apps
  • Semver devDependency ReDoS alert
  • Update Slack team invite form on Docs (Slackin') and add badge to readme
  • Update devDependencies in package.json with local modules for generating docs
  • Post-release: Add F2.js packages to cdnjs repo

Visit the following sources to download or install F2:

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: 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 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.

Friday, October 24, 2014

Recap of 2014 F2 Summit

The annual F2 Summit was held on September 18 and 19 in Boulder. The two-day event was an opportunity for F2 Advisory Board firms to gather and discuss the future of the initiative. The agenda was packed with presentations, demos and roundtable discussions. Of course we couldn’t miss the opportunity for a happy hour as well as a hike on the historic Chautauqua trails.

10 of the 14 Advisory Board firms sent representatives to the Summit, with most firms sending two individuals. The following firms attended (in alphabetical order): Markit, Moody’s Analytics, Morningstar, Pershing, RBC, S&P CapitalIQ, TD Ameritrade, TIAA-CREF, USA Today and Wells Fargo.

The overall objectives for this year's Summit were:
  • Bring F2 Advisory Board members together for networking opportunities
  • Engage in high-bandwidth discussions on key topics effecting F2
  • Increase and share F2 knowledge across Advisory Board firms
  • Address ongoing issues surrounding F2
  • Create a simple, documented governance model for F2
  • Demonstrate the long-term viability of F2
Throughout the two-day Summit—from talking through the vision of F2 to exploring governance —these objectives were achieved or at least moved forward. There will be more information forthcoming on the official governance model as the F2 Team works with the Board to document it.

On the afternoon of Day 1, representatives of TD Ameritrade and USA Today gave presentations of their firms’ production F2 implementations. These demonstrated not only the viability of F2, but also the flexibility of the framework to span across retail brokerage and into media.

The focus of Day 2 was aligned with the overall theme of the Summit: the evolution of F2. In the morning sessions, we covered various types of contributions to the initiative as well as governance models. After lunch, the Board moved across Markit’s Boulder campus to participate in an interactive brainstorm in the Design space. The purpose of the brainstorm, held in front of a 50-foot-long whiteboard, was to be creative with F2 and demonstrate how F2 Apps can be repurposed for almost any user experience. Divided into teams, the Board created F2 Apps out of paper rectangles and markers, then placed those Apps on 4 different delivery channels: desktop, iPad, large touch-screen displays, and a billboard in Times Square.

The 2014 Summit was incredibly successful. A huge thank you to Markit for hosting the second annual event and especially for the delicious Boulder-made chocolate. The core F2 Team is grateful to all of those who traveled to Boulder and participated in meaningful, thoughtful and candid conversations. There is much work to be done, and with the continued involvement and contributions from the Advisory Board, the future of F2 is bright.

The Summit notes are available in PDF.

Friday, September 12, 2014

Supporting Bootstrap 3

The F2 spec calls for the use of Bootstrap for consistent HTML & CSS structure across all Containers and Apps. This allows Container and App Providers to build and reuse front-end code while anticipating and relying on uniform presentation. F2 also uses Bootstrap javascript plugins for 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.

When F2 was originally released in 2012, Bootstrap was still a Twitter project. Since then, much has changed and, of course, F2 still uses Bootstrap. We've heard some questions about Bootstrap 3 support recently and wanted to clear up any confusion.

The currently-supported version of Bootstrap in F2 is 2.3.2. This means Container and App Providers should expect Bootstrap 2 code conventions, including functioning 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 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.

This is a temporary solution as there's an open Pull Request to officially upgrade to Bootstrap 3 in F2 1.4. You can visit #142 for all the details. Any questions or concerns? Get in touch with us.

Monday, August 18, 2014

F2 Summit 2014

The F2 Team is happy to announce the upcoming F2 Summit to be held in Boulder, Colorado on September 17 and 18, 2014. This second annual event is an opportunity for F2 Advisory Board firms to gather and discuss the future of the initiative.

The theme for this year's Summit is “The Evolution of F2.” The agenda for the day and a half event will include presentations on F2’s roadmap, panels showcasing F2 in production websites, and discussions around governing the open source initiative.

We are looking forward to welcoming both builders and non-builders alike from all of the F2 Advisory Board firms to this year’s Summit. We’ll be sure to post more information before and after the Summit in September, stay tuned!

Thursday, August 14, 2014

Announcing an all-new website and logo for F2

Our work on the complete redesign of the F2 website is complete and it is now live! The new design represents a fantastic refresh of both the visuals and presentation of information across the site. Beyond the look and feel, the amazing design team have reimagined the framework's identity by creating a new logo mark for F2. The website, hosted at the same address, launched at the end of July.

From the top of the home page all the way to the bottom, the flow of information provides deeper insight into what F2 is, how it works, who it's for, and what its benefits are. Additionally, the content aligns much more closely with the printed collateral for more unified materials. The Advisory Board firms' logos are represented on the site identifying the influential companies who support the F2 initiative. Finally, in response to feedback, we have a much more robust Hello World demo linked in the feature carousel.

Throughout the rest of 2014 the F2 team will be working to refresh the design of the F2 website stretching across into the F2 spec itself ( and this blog.

We would like to thank the Advisory Board members who participated in early design reviews for their valuable feedback and contributions.

Visit and let us know if you have any feedback.