Friday, September 30, 2016
Wednesday, June 22, 2016
Visit the following sources to download or install F2:
Monday, June 13, 2016
- 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
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:
- 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.
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
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 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.
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
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",
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.
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
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.
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
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.
Friday, October 24, 2014
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
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
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
Modalshave 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.jscustom 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
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
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 (docs.openf2.org) 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 www.openF2.org and let us know if you have any feedback.