Page Comparison

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