Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 20 Next »

 

I. Use Case Description

Use Case Name

Exchange Instrument Data Offering

Use Case Identifier

SEC-02

Source

FBC/SEC Content Team

Point of Contact

Elisa Kendall, Tony Coates

SEC-Creation / Revision Date

6/10/2019

Associated Documents

Requirements documentation, traceability matrix if applicable


II. Use Case Summary

Goal

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.

Requirements

Specify the essential securities instrument information needed for core securities master data management, specifically the subset that an exchange might publish.

Scope

In order to constrain the scope further, in this use case we will focus on (1) equities and (2) bonds.

Priority

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.

Stakeholders

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.

Description

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.

Assumptions

 

Open Issues

 

 

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:

  1. Information concerning the instruments themselves (contract terms, market data in some cases, etc.)
  2. Information about the entity that issued the instrument (reference data about the instrument)


IV. Competency Questions

 

A. Equities

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

5. How would a user map the top 20-30 characteristics that banks typically track internally for the common stock issued by a given issuer?


B. Bonds / Fixed Income Instruments

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

 

V. Resources

Knowledge Bases, Repositories, or other Data Sources

Data

Type

Characteristics

Description

Owner

Source

Access Policies & Usage

OpenFIGI

online resource



 Bloomberg

openfigi.com

 freely available

DTCC Security Master Data

 online resource


 See Documents, sample data for securities master file and intra-day securities master file


 https://www.dtccdata.com/products/security-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

 

 

X. Notes

 

There is always some piece of information that is required that has no other place to go. This is the place for that information.



  • No labels