Use case: SEC-01

I. Use Case Description
Use Case Name	Securities Master Data Model – High Level Family Use Case
Use Case Identifier	SEC-01
Source	FBC/SEC Content Team
Point of Contact	Elisa Kendall, Tony Coates
SEC-Creation / Revision Date	5/16/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. Having said this, asking banks to change out their current IT infrastructure to use semantic technologies over the myriad of legacy databases and systems they have in place is also unworkable. Instead, what is needed is (1) an ontology that specifies the core content needed in a common reference model for essential securities data, (2) guidance on how to extend the ontology to support use cases where the ontology might not have complete coverage, and (3) guidance on how to use the ontology as a human and machine-readable interlingua for generation of schemas, interfaces, and other artefacts allowing users to align with other systems and formats that they might need. Examples might include showing how to use the ontology to support trading systems, market valuation systems, reporting systems, and so forth. Data vendors are not necessarily interested in publishing their own models, and so the focus should be to distill the core information needed, and then demonstrating how people can extend it to cover content that is outside that core but needed internally for some purpose at some institution.
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 goal is not to cover the thousands of data points that the vendors maintain, but to specify the essential information that is most commonly used for securities master data management. We also need to be able to show how to use and extend that model to generate more system (platform) specific artefacts that are important to them. In other words, coverage of the most important (top 50, top 100, top x) concepts is critical, along with the ability to deliver something useful that can be mapped to various back end databases or sources of information.
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	… Coverage includes, at a minimum, the following securities / asset classes: Structured Finance - Asset-Backed Securities / Collateralized Mortgage Obligations - Mortgage-Backed Securities Corporate Fixed Income Securities Equities Funds/Trusts Government Securities Money Market Instruments Municipal Securities 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. Do the same with the information provided by Golden Source. Do the same with internal systems from EDMC member banks who are willing to work with us.
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.

A financial organisation is looking to purchase a new instrument master database for market traded instruments, but is hesitant about being locked into a proprietary data model that could make migration to any alternative vendor’s product prohibitively expensive. They shortlist only vendor products that can import and export the full database contents using the FIBO instrument master format, so that vendor lock-in is minimised.

[From Jeff Braswell]: ACTUS covers instrument contract terms but not some of the other knowledge we need such as counterparties. This particular use should clarified to cover only market traded instruments.

[John Gemski]: The definition of security is jurisdiction specific, differs by country. So, we should be careful about the definitions, and say that this use case does not cover OTC instruments.

[Richard Beatch]: We need to define what is meant by instrument master data, since front office, back office and compliance may have different needs.

[John Gemski]: The Golden Source model covers ‘everything’, but not all clients use all of it.

[Richard Beatch/Jeff Braswell]: The suggestion is that we need to ultimately cover what is needed to represent the content required to represent an instrument on a bank’s balance sheet. For the purposes of this use case, though, let’s cover back office. We should start with equities – debt is fairly wide. We also need to determine whether or not we are covering static data or what …

[John]: We should cover at least the static data (day 0) information that is needed to represent an instrument for the purposes of compliance, but not necessarily cover the market valuation process.

[JB]: Equity data is fairly straightforward – one source would be OpenFIGI, which does not include the LEI, but does have a number of basic details. The ability to correlate the issuer with its LEI is something that companies consider more valuable.

An exchange decides that it would like to offer instrument master data direct to end users, and chooses the FIBO instrument master format because vendors support it and so it reduces the onboarding cost for end users and increases the chances of 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 scenario as the basis for an initial 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.

A financial organisation has short-listed two instrument master data vendors, and wants to compare the data feeds to check for inconsistencies that could indicate data quality issues with one of the vendors. They ask both vendors to provide sample data using the FIBO instrument master format, so that the most important fields are easily and directly comparable.

[JB]: This is still more bounded than (1) but is very interesting and would cover what needs to be reported to regulators – but includes OTC instruments which we are excluding in the current context. Another potential benefit – there is sample data available that could be used with respect to static data, including some OTC instruments. If we cover the starting point terms of a contract, rather than attempting to cover all of the variability over time, that might still be a useful starting point, including potentially contract-type related algorithms.

If we establish a set of rules that are particular to contract types then we should be able to classify contracts as being of a certain type. ACTUS supports some of this, and has some general and optional parameters, where some optional parameters require others – this is where the subtlety comes in with respect to some of the data that is non-static. To do this we would need multiple experts who understand these kinds of contracts as well as those that are knowledgeable from multiple jurisdictions. There may be different conventions depending on the jurisdiction. For example, there may be more variation with respect to funds and related to that to alternative investment schemes. This use case won’t cover funds, but we need to be careful about the linguistic variations, and other jurisdiction-specific variation.

So – what do we mean by inconsistency? Between the two feeds? Between the feed and the bank consuming it? Both feeds -could- be inconsistent … there may be issues in reference data from some perspective but not necessarily all perspectives? What constitutes reference data from what sort of source?

IV. Basic Flow of Events

Narrative: Often referred to as the primary scenario or course of events, the basic flow defines the process/data/work flow that would be followed if the use case were to follow its main plot from start to end. Error states or alternate states that might occur as a matter of course in fulfilling the use case should be included under Alternate Flow of Events, below. The basic flow should provide any reviewer a quick overview of how an implementation is intended to work. A summary paragraph should be included that provides such an overview (which can include lists, conversational analysis that captures stakeholder interview information, etc.), followed by more detail expressed via the table structure.

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)

Provide the primary use case diagram, including actors, and a high-level activity diagram to show the flow of primary events that include/surround the use case. Subordinate diagrams that map the flow for each usage scenario should be included as appropriate

VII. Competency Questions

Provide at least 2 competency questions that you will ask of the vocabulary/ontology/knowledge base to implement this use case, including example answers to the questions.

Describe at least one way you expect to use the semantics and/or provenance to propose an answer to the questions. Include an initial description of why the semantics and/or provenance representation and reasoning provides an advantage over other obvious approaches to the problem. (optional – depending on the use case and need for supporting business case).

VIII. Resources

In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured. These resources include the set of actors listed above, with additional detail, and any other ancillary systems, sensors, or services that are relevant to the problem/use case.

DTCC Security Master Data - https://www.dtccdata.com/products/security-master-file/

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

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

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.