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 | State any requirement(s)specific to this use case, including any capabilities from a business architecture or process model that the use case supports, any metrics or other reporting requirements, etc., including any reference identifier for the requirement(s), as applicable |
Scope | The use case is designed to specify the essential information that is most commonly used for 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. |
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 | Identify all known stakeholders for the use case |
Description | …
As an example, compare the format and content of the DTCC Security Master Data File formats (including intra-day) as a starting point, with our existing ontologies for coverage of essential concepts across security types. Do the same with similar information from CME given that they are willing to provide it. |
Actors / Interfaces | List actors: people, systems, knowledge bases, repositories, and other data resources, services, sensors, or other “things” outside the system that either act on the system (primary actors) or are acted on by the system (secondary actors). Primary actors are those that invoke the use case and benefit from the result. Identify the primary actor and briefly describe role.
Any actor that is external to or outside the control of the use case owner should be further described under Resources, below. |
Pre-conditions | Identify any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about the state of other related systems can also be stated here. List all preconditions. |
Post-conditions | Provide any conditions that will be true of the state of the system after the use case has been completed. |
Triggers | Describe in detail the event or events that initiate the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or a complex event that indicates that some set of conditions has been met. |
Performance Requirements | List any known performance-specific requirements – timing and sizing (volume, frequency, etc.), maintainability, reusability, other “-ilities”, etc. |
Assumptions |
|
Open Issues |
|
III. Usage Scenarios
Provide at least two usage scenarios that flesh out the requirements outlined in the summary, including identification of requirements specific to any envisioned ontology or semantically-driven service or application. Scenarios should be described as narrative, with supporting diagrams as appropriate. In an Agile process, every user story relevant to the use case should be included and elaborated/rolled up into one or more usage scenarios, with a clear mapping from the user story to the scenario it is integrated in or mapped to.
An Our primary usage scenario is that an exchange decides that it would like to offer instrument master data direct directly to their end users, and chooses . They choose the FIBO instrument master format because vendors support it and so it , which reduces the onboarding cost for end users and increases the chances of changes for uptake by those end users.
[Richard Beatch]: This is a better scenario because exchanges tend to exchange only certain kinds of instruments, and have limited data that they share. This may not be enough to cover what we want for FIBO but is a bounded case and a good starting point.
[Consensus]: We will use this usage
There are two important content areas to consider:
- Terms of the instruments themselves (contract terms), including the risks involved in having such a product on one’s books
- Terms regarding the entity that issued the instrument (reference data about the instrument)
We will use this scenario as the basis for an initial several subordinate use cases to flesh out, since it is the simplest. We need to pick an exchange that is willing to provide the most information to support this, though. What we would like is the combination of the reference data about the information about prices as well as information about the issuers that we can use, including a number of different identifiers for the issuer. If we start with a few examples that are publicly traded banks, since we have definitions for those identifiers, and then expand to some set of exemplar non-bank companies, that would be good.
There are two scenarios that are important to consider:
...
We have a few example individuals already in FIBO/FBC for publicly traded banks (holding companies), which we can use as a starting point.
The following smaller scenarios could be considered building blocks for this.
A. Equities
- How would can we 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:
| View file | ||||
|---|---|---|---|---|
|
(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.
(c) Automate generation of the remaining individuals extracted from OpenFIGI based on these hand-crafted individuals to demonstrate feasibility of doing so.
B. Bonds / Fixed Income Instruments
IV. Basic Flow of Events
...
In cases where the user scenarios are sufficiently different from one another, it may be helpful to describe the flow for each scenario independently, and then merge them together in a composite flow.
Basic / Normal Flow of Events | |||
Step | Actor (Person) | Actor (System) | Description |
|
|
| |
|
|
| |
|
|
| |
V. Alternate Flow of Events
Narrative: The alternate flow defines the process/data/work flow that would be followed if the use case enters an error or alternate state from the basic flow defined, above. A summary paragraph should be included that provides an overview of each alternate flow, followed by more detail expressed via the table structure.
Alternate Flow of Events | |||
Step | Actor (Person) | Actor (System) | Description |
|
|
| |
|
|
| |
|
|
| |
VI. Use Case and Activity Diagram(s)
...
Knowledge Bases, Repositories, or other Data Sources
Data | Type | Characteristics | Description | Owner | Source | Access Policies & Usage |
(dataset or repository name) | (remote, local/in situ, etc.) | e.g. – no cloud cover | Short description of the dataset, possibly including rationale of the usage characteristics |
| Source (possibly a system, or remote site) for discovery and access |
|
|
|
|
|
|
|
|
External Ontologies, Vocabularies, or other Model Services
Resource | Language | Description | Owner | Source | Describes/Uses | Access Policies & Usage |
(ontology, vocabulary, or model name) | (ontology language and syntactic form, e.g., RDFS - N3) | If the service is one that runs a given ontology or model-based application at a given frequency, state that in addition to the basic description |
| Source (link to the registry or directly to the ontology, vocabulary, or model where that model is maintained, if available) | List of one or more data sources described by and/or used by the model |
|
|
Other Resources, Service, or Triggers (e.g., event notification services, application services, etc.)
Resource | Type | Description | Owner | Source | Access Policies & Usage |
(sensor or external service name) |
| Include a description of the resource as well as availability, if applicable | Primary owner of the service | Application or service URL; if subscription based, include subscription and any subscription owner |
|
|
|
|
|
|
|
IX. References and Bibliography
...