Every valid ISIN request submitted to the DSB will be returned with the CFI code as part of the ISIN record. The CFI code is constructed from 6 attributes that are either explicitly submitted by the user (in cases where there are multiple choices for a specific instrument) or derived by the DSB (in cases where there is a clear and accurate interpretation for a specific instrument).

The asset class based CFI taxonomy is outlined in each of the Product Definition documents published here

DSB ISINs are created for multiple purposes by users and the existence of any given ISIN does not guarantee its existence in FIRDs based on whether or not industry has a requirement to submit it to meet Reference Data Reporting obligations.

FIRDs reporting requirement begins on 3^rd January 2018 for all relevant parties that are obligated to meet Regulatory Reporting requirements.

The DSB has made a large amount of documentation publicly available on our GitHub or the DSB Section of the ANNA website.

The background of the DSB and its approach to generating ISINs is outlined in our Final ISIN Principles paper published here

A Product Definition is a unique representation of the population of attributes applicable to a specific OTC Derivative product within an asset class.

The list of Product Definitions defined by the DSB cover all five assets classes in scope for MiFID II Reference Data Reporting – Rates, Credit, FX, Equities & Commodities. The population was originally based on the ISDA 2.0 taxonomy and has been expanded upon through the input of various industry taskforces.

The Product Definition documents, including an annex for each asset class and machine readable JSON templates, outline the ISIN attributes that must be sent to the DSB to create an ISIN and the full record that is returned to the user. These are published here

At this time, there are six scenarios for consumption of DSB data:

1. Users get the DSB ISIN and associated product attributes from the counterparty to the trade or the venue on which the trade was executed
   • User Action: No contract needed with the DSB – click here for the DSB PROD Registration form and complete section 1 ONLY
2. Users access the DSB to download end of day files and use this data to search for the attributes that match their product preference
   • User Action: No contract needed with the DSB – click here for the DSB PROD Registration form and complete section 1 ONLY
3. Users access the DSB GUI and search for the attributes that match their product preference – contains end of day & intra-day data
   • User Action: No contract needed with the DSB – click here for the  DSB PROD Registration form and complete section 1 ONLY
4. Users access the DSB via an intermediary who uses the end of day files to search for the attributes that match their product preference
   • User Action: No contract needed with the DSB – click here for the  DSB PROD Registration form and complete section 1 ONLY
5. Users access the DSB directly to search for ISINs (intra-day & end of day), create ISINs manually and download end of day files
   • User Action: Users must contract with the DSB as either Infrequent or Standard User – click here for the suite of documents comprising the DSB User Agreement
6. Users access the DSB on a programmatic basis (either directly or indirectly) to search and/or subscribe to intra-day updates (contract needed with the DSB)
   • The user would be a Power User in this instance
   • The user would therefore have to contract directly with the DSB & pay Power User fees
   • The user’s vendor would also have to contract with the DSB as they would have to be party to the technical terms
   • The user’s vendor would not have to pay fees if they were not storing, distributing or otherwise consuming intra-day DSB data other than for you
   • User Action: Users must contract with the DSB as a Power User – click here for the suite of documents comprising the DSB User Agreement)