F2 is an open and free web integration framework designed to help you and other financial industry participants develop custom solutions that combine the best tools and content from multiple providers into one, privately-labeled, seamlessly integrated front-end.
You can use the F2 framework to build:
The F2 concept was born in Boulder, Colorado at Markit On Demand (MOD). F2 was brought to life through conversations with industry partners who individually express common frustrations and desire a coordinated solution.
MOD’s development team is committed to following the technical guidelines defined by the F2 standard and actively contribute enhancements to future F2 releases.
The F2 Advisory Board is an independent forum comprised of supportive industry participants. The Board’s purpose is to ensure that the F2 specification evolves to meet the needs of the industry. Advice, guidance and thought-leadership from the collective community are integral to the success of F2.
For more information about the F2 Advisory Board please contact firstname.lastname@example.org.
F2’s goal is to create a development standard for the financial services industry that offers a cost saving, risk-reducing method for building innovative, multi-provider solutions. In order to do this effectively, F2 provides solutions that address shared industry hurdles and concerns.
Because the spec is open, free, and exactly what the industry needs, we believe that it will be widely adopted, which will create new markets for app developers, content providers, and create vibrant app ecosystems for participants.
|Industry Problem||F2 Solution|
Monolithic, installed code bases that are closed and expensive to enhance. When a “redesign” occurs on this type of platform, it’s usually a do-over, from the ground-up. Integration is difficult.
Nimble, modern use of internet-delivery with a multi-vendor approach. Standardized framework used by all parties. Cost-effective and shorter development cycles.
Big Bang approaches stifle innovation and require significant investment in the integration of legacy systems. Buy-in from many stakeholders is essential and difficult to manage. Entire platforms must be redeveloped in order to make cut-overs. There are more bugs and problems at launch and unhappy users.
In the F2 environment you will be able to compete on features. It is easy to progressively make changes, enhancements, onboard new applications, switch content providers with little risk and migrate users and tools to the platform gradually as time and resources allow. Containers may also host previous versions of websites and apps to further simplify migration.
Separate projects, budgets and teams for web sites, tablets and hand-held devices.
The F2 specification describes how to develop one framework that can be managed to many devices.
Security concerns are a major reason firms worry about switching vendors or to a new technology.
F2 can entitle apps without passing sensitive client information to a third party app provider. This multi-provider solution is more secure and less vulnerable than single-provider solutions.
Over-provisioning of content happens frequently. It is expensive to pay for content that no one is using. This probably happens because it is difficult to manage and change entitlements.
The F2 spec makes it easy to turn on or off entitlements as often as may be required.
F2 will continuously evolve to bring the community the best features, services and apps. F2’s promise is to do this by building on the existing spec, not by changing it. The specification aims high to solve many problems and suit many needs. As the standard evolves and new requirements come to light, the functionality in F2 will expand accordingly.
To achieve steady growth and stable release cycles, F2 will be maintained under the Semantic Versioning guidelines as much as possible. For more information, browse to the readme on GitHub.
F2 v1.0 was released on October 15, 2012. The latest version of the F2 specification is 1.4.5 released on 2 March 2018. To provide transparency into the future of F2, a roadmap wiki will be available on GitHub. A changelog that tracks version-to-version changes, upgrades and deprecated features will offer a historical look at F2’s evolution.
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. For readability, these words do not appear in all uppercase letters in this specification.
The F2 open framework enables a division of labor among multiple parties who contribute to an integrated experience. By separating responsibilities into those of container and apps, F2 makes it possible for project owners to pick who they want to partner with, if anyone, for the development and hosting of their container and the apps they wish to include.
Following are definitions for the main F2 Framework components: the apps, the container, and the store.
In order to ensure that applications built using F2 are successful, they must be accessible. With this in mind, the front-end technology choice is HTML5. Using the progressive enhancement methodology, F2 incorporates a rock-solid foundation. The F2 open standard provides guidelines for developers to add feature enhancements targeting specific environments or visitors. For example, F2 apps built following the mobile first design approach and with responsive CSS, allow users to access the apps on their desktop, tablet or smartphone and App Developers only need to build a single app.
Support across all desktop browsers and mobile devices is sometimes limited so F2 includes some third-party web development libraries to bridge those gaps. Why reinvent the wheel, right?
F2 apps are synonymous with modules, widgets and portlets. Think charts, portfolios, trade tickets, and screeners. F2 apps only need to be programmed once, no matter where they will be used.
F2 apps are either:
The F2 design and development philosophy adheres to the Responsive Web Design Methodology to ensure app flexibility across mobile and desktop workspaces. Simply put, apps will only need to be programmed once, regardless of where they will be used.
Apps are capable of sharing “context” with the container and other nearby apps. All apps have context which means the app “knows” who is using it and the content it contains. It is aware of an individual’s data entitlements and user information that the container is requested to share (name, email, company, etc).
This means if a user wants to create a ticker-focused container so they can keep a close eye on shares of Proctor & Gamble, the container can send “symbol context” to any listening apps that are smart enough to refresh when ticker symbol PG is entered in the container’s search box.
The F2 container is a web page that is “aware” of its contents (the apps) and plays the role of a traffic cop managing context passing between F2 apps (when more than one exists in a container). It is also the layer between the browser and apps, and the location where apps reside.
In order to make it so that apps look good together in a multi-provider environment, the spec recommends that each app adhere to a standard, container-controlled grid. F2 relies on a responsive, 12-column grid system which is flexible enough to accommodate everyone’s needs.
The F2 standard outlines a consistent HTML structure and CSS classname convention so neither Container Developers nor App Developers have to think about harmonizing look and feel. Container Providers can create a customized stylesheet, and the selectors and declarations they define in CSS will cascade to their containers’ apps. Separately, apps can define a preferred resolution (in grid widths) for containers to position them appropriately within the grid.
While F2 is designed to handle several apps being displayed simultaneously, it doesn’t have to. The spec also permits full screen, single-provider displays. This is a useful feature for container owners who need to incorporate legacy, full screen content with the least amount of effort.
Examples of work the container, and therefore the Container Provider, are responsible for include:
The store exists as an access point for apps. Developers deliver apps to the store, administrators entitle apps, and app consumers may view and select apps from the store.
The store is also where the general F2 community goes to share, view, administer, purchase and entitle apps. App consumers can buy apps using an electronic payment mechanism (like a credit card), charge-back to their company, be entitled by a vendor or another business relationship or activate time-based, usage-based or free trials. The contents of the store, meaning the apps that are accessible, are controlled by the container owner.
The Developer Center will serve as a resource area for the F2 Developer community. Some of the content and services you can expect to find here include:
F2 enables all of us to build exactly the financial solutions that our customers want. Using the F2 Framework, you can efficiently create fully-integrated, multi-vendor, multi-asset class and multi-channel apps and deploy them in as many app ecosystems as you want.
Developers who adhere to the F2 standard will make it possible for multiple apps, developed independently by different organizations, to function together creating a seamless and integrated experience.
If you are interested in building apps, get started by browsing through this technical documentation or follow the project on GitHub. If you are interested in building containers, browse to the container documentation.