I. Use Case Description
Use Case Name
Exchange Instrument Data Offering
Use Case Identifier
FBC/SEC Content Team
Point of Contact
Elisa Kendall, Tony Coates
SEC-Creation / Revision Date
Requirements documentation, traceability matrix if applicable
II. Use Case Summary
There is no single publicly available model for instrument reference data for market traded instruments. FIBO should provide the core content for such a model, which is needed across the industry, including EDMC member institutions. While there are a number of proprietary models, such as those of data vendors, there is no general consensus.
This use case is focused on a fictitious offering of securities instrument data to users by an exchange, to establish a constrained baseline for the overarching use case defined in SEC-01.
Specify the essential securities instrument information needed for core securities master data management, specifically the subset that an exchange might publish.
In order to constrain the scope further, in this use case we will focus on (1) equities and (2) bonds.
This is high priority in order to (1) provide a much-needed reference model for securities master data management and (2) demonstrate how to use an ontology successfully and in a cost-effective way as the basis for other work inside an institution.
Primary stakeholders include any exchange that might publish instrument related information, consumers of that information including traders, front and back office personnel as well as compliance officers at institutions whose portfolios include securities and that need to manage information about those securities, other individual investors interested in the information, and various systems supporting all of the above.
There are a number of organizations that publish certain master data elements that we can use as the basis for coming up with a composite view, including OpenFIGI, the DTCC Security Master Data File (including intra-day), various exchanges including the NYSE and Nasdaq, and possibly CME. The purpose of the use case is to show how one might leverage data coming from multiple sources to manage security master data using FIBO.
There are several JIRA issues around accomplishing this goal. SEC-74, for example, is about representing a share of stock as listed in a specific exchange. That particular issue represents a subset of what we want to do in this use case, but is a starting point.
Actors / Interfaces
Actors include the stakeholders listed above, systems that maintain security master data including but not limited to those at the exchange, inside of an institution, or managed by regulators, and any other consumer of security master data.
III. Usage Scenarios
Our primary usage scenario is that an exchange decides that it would like to offer instrument master data directly to their end users. They choose the FIBO instrument master format because vendors support it, which reduces the onboarding cost for end users and increases the changes for uptake by those end users.
Content provided by an exchange about a given instrument typically includes:
- Information concerning the instruments themselves (contract terms, market data in some cases, etc.)
- Information about the entity that issued the instrument (reference data about the instrument)
IV. Competency Questions
- How would a user map the data published by Bloomberg via their OpenFIGI site for the common stock issued by a given issuer?
(a) Go to OpenFIGI (openfigi.com), select Wells Fargo and then filter by ( i ) Wells Fargo & Co, ( ii ) Security Type of Common Stock, and ( iii ) Market Sector of Equity, and export the following spreadsheet:
(b) Map the general Wells Fargo & Co share class level equity instrument as well as a specific Wells Fargo & Co exchange-specific share (e.g., issued on the New York Stock Exchange) to FIBO and create example individuals (see https://spec.edmcouncil.org/fibo/ontology/SEC/Equities/EquitiesExampleIndividuals) manually to make sure that we can do so and that all of the relationships work as intended. These examples only represent what is available publicly in OpenFIGI, not everything one would want to know about a given equity that could be published as instrument master data. Run two reasoners to make sure that the resulting examples are logically consistent. Note that the equity examples include details for a number shares on the Nasdaq and New York Stock Exchange.
(c) Automate generation of the remaining individuals extracted from OpenFIGI based on these hand-crafted individuals to demonstrate the feasibility of doing so.
2. How would a user represent the listings for the same common stock and class of share on multiple exchanges?
For this purpose, we created individuals for Apple common stock, with listing individuals in the Nasdaq and London Stock Exchange. These are available in the EquitiesExampleIndividuals ontology.
3. How would a user represent multiple classes of share for the same company? For this, we have modeled the shares for Alphabet / Google.
The multi-class share structure at Google came about as a result of the company's restructuring into Alphabet Inc. in October 2015 (NASDAQ: GOOG). Founders Sergey Brin and Larry Page found themselves owning less than majority ownership of the company's stock, but wished to maintain control over major business decisions. The company created three share classes of the company's stock as a result. Class-A shares are held by regular investors and carry one vote per share. Class-B shares, held primarily by Brin and Page, have 10 votes per share. Class-C shares are typically held by employees and have no voting rights. The structure gives most voting control to the founders, although similar setups have proven unpopular with average shareholders in the past.
The examples cover the Class A and Class C shares only, not Class B, which are not available on the Nasdaq, also available in the EquitiesExampleIndividuals ontology.
4. How would a user map the securities that they are managing to the CFI classification scheme?
Classes representing the exhaustive set of features for equities (e.g., voting rights, ownership restrictions, payment status, form) are defined in the EquityInstruments ontology. A partial set of individual codes covering common and preferred shares are available in the EquityCFIClassificationIndividuals ontology. The codes are mapped to the classes representing the combination of features they denote in that ontology. FIBO users can look at these examples to map other kinds of instruments and develop other codes in the same way.
Note that the 2021 version of the CFI codes are now published in RDF using a SKOS vocabulary, so we will be revising our CFI ontology to map to the ISO codes ontology over the coming months.
5. How would a user map the market data currently published by the New York Stock Exchange or Nasdaq for the common stock issued by a given issuer?
For Apple common stock listed in the Nasdaq, the following information is available:
Exchange - in FIBO
Sector - exchange specific, high-level is in FIBO
Industry - exchange specific, high-level is in FIBO
1 year target price - in FIBO, latest pricing ontology
Today's high / low price - in FIBO, latest pricing ontology
Share volume - in FIBO, latest pricing ontology
50 day average volume - not in FIBO
Previous close - in FIBO, latest pricing ontology
52-week high / low price, in FIBO, latest pricing ontology
Market cap - in FIBO, in equities ontology
P/E ratio - may need a property to be added (can be calculated)
Forward P/E 1 year - may need a property to be added (can be calculated)
Earnings per share (EPS) - may need a property to be added (can be calculated)
Annualized dividend - in FIBO
Ex Dividend Date - in FIBO
Dividend Pay Date - in FIBO
Current yield - in FIBO
Beta - not in FIBO ?
Next steps include demonstrating how to represent this information for a given listing in our equities examples, with adjustments to the ontologies as needed.
B. Bonds / Fixed Income Instruments
- How would a user map the data published by Bloomberg via their OpenFIGI site for a bond issued by a given issuer?
Note that some bonds are issued by a holding company, such as IBM, and others might be issued by a subsidiary. In this case, we want to show (1) an example issued by the highest level corporate holding company, and (2) an example issued by a subsidiary, showing the relationship between the two. One example is to show bonds issued by IBM (corporate holding company), IBM Credit, and Telelogic AB (at least one of each). Red Hat bonds are not listed under IBM on OpenFIGI yet, but we could add that example with the corporate structure included as well. Include listing information for the same bonds from the NYSE and Nasdaq.
(a) To demonstrate the example of a bond issued by the top-level corporate holding company, create individual business entities for IBM (see https://spec.edmcouncil.org/fibo/ontology/BE/LegalEntities/NorthAmericanEntities/USExampleEntities/ and https://spec.edmcouncil.org/fibo/ontology/FBC/FunctionalEntities/NorthAmericanEntities/USExampleIndividuals/).
(b) Go to OpenFIGI (openfigi.com), select IBM and then filter by Security Type of 'U.S. CP', and export the following spreadsheet:
(c) Map the two IBM Corp Commercial Paper instruments and create example individuals manually to make sure that we can do so and that all of the relationships work as intended. These examples only represent what is available publicly in OpenFIGI and not everything one would want to know about a given instrument that could be published as instrument master data. Run two reasoners to make sure that the resulting examples are logically consistent.
Knowledge Bases, Repositories, or other Data Sources
Access Policies & Usage
DTCC Security Master Data
See Documents, sample data for securities master file and intra-day securities master file
requires login, but available after that
IX. References and Bibliography
List all reference documents – policy documents, regulations, standards, de-facto standards, glossaries, dictionaries and thesauri, taxonomies, and any other reference materials considered relevant to the use case
There is always some piece of information that is required that has no other place to go. This is the place for that information.