The current level of OTC ISIN record generated by the DSB is designed to enable users to fulfil their RTS-23 reporting obligations and is aligned with ESMA’s needs at a minimum.

An extract of the relevant requirements are set out below “Given the scope of the financial instruments to be covered (about 15 million), the use of multiple identifiers for the purposes of data reporting under MiFID II/MiFIR would lead to difficulties in obtaining a comprehensive overview of markets and render market surveillance extremely difficult as different identifiers have to be
reconciled. It would also considerably increase the workload for ESMA and National Competent Authorities to analyse the data, and would lead to considerable costs due to the costs of underlying reference data.” with full details available here: http://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160714-rts-23_en.pdf.

Changing to API connectivity requires an upgrade from the DSB’s Registered User category to a Power User

An overview of the DSB Fee Model for the year ending 2018 is available here.

If joining mid-year, the applicable charges would be a quarterly based pro-rata’d amount based on the prevailing fee structure (Power Users fees are €112,500 p.a. for the full year ending 2018).

Full details about fees can be found in the Charges Policy which is available here.

If wishing to upgrade mid-year, a new Access and Usage Agreement would need to be executed and applicable charges would apply

Changing to API connectivity requires an upgrade from the DSB’s Infrequent User category to a Power User

An overview of the DSB Fee Model for the year ending 2018 is available here.

If joining mid-year, the applicable charges would be a quarterly based pro-rata’d amount based on the prevailing fee structure (Power Users fees are €112,500 p.a. for the full year ending 2018). Full details about fees can be found in the Charges Policy which is available here.

If wishing to upgrade mid-year, a new Access and Usage Agreement would need to be executed and applicable charges would apply

Changing to API connectivity requires an upgrade from the DSB’s Standard User category to a Power User

An overview of the DSB Fee Model for the year ending 2018 is available here.

If joining mid-year, the applicable charges would be a quarterly based pro-rata’d amount based on the prevailing fee structure (Power Users fees are €112,500 p.a. for the full year ending 2018). Full details about fees can be found in the Charges Policy which is available here.

If wishing to upgrade mid-year, a new Access and Usage Agreement would need to be executed and applicable charges would apply

Information about account set up for intermediary access is available here.

Each Power User (API user) is able to have up to 10 connections across both direct and intermediary access means, with the ability to facilitate multiple intermediaries.

Each end user seeking access to the DSB’s Production services will need to have contracted directly with the DSB.

Intermediaries connecting to the DSB for ISIN creation and/or API based search will need to execute a user agreement, but may not be required to pay fees unless the intermediary is also acting as a Power User themselves

Full legal documentation (agreement and policies) are available here.

Users are required to pass the DSB’s FIX Certification test in the DSB UAT environment as a precursor to connecting to DSB Production Environment. Test details are laid out in the FIX User Guide included in the On-Boarding Pack and also here

In the event you wish to terminate any existing connections, please inform the DSB in writing (via a note to technical.support@anna-dsb.com), following which the DSB will take action and notify you and the intermediary (where applicable) on termination of the relevant connection.

The DSB, founded by the Association of National Numbering Agencies, established the DSB Product Committee (DSB PC) consisting of Industry and Regulatory representatives to manage and carry out product governance and to ensure the maintenance of data specifications for ISINs for OTC derivatives, including addressing new market products and to ensure all regulatory requirements can be met. More information about the Product Committee and associated governance can be found here

 

The DSB is responsible for generating ISIN, CFI & FISN for OTC Swaps, Non-Listed Options and Forwards traded or submitted to trading on an EU trading venue.

From a CFI perspective, the DSB assigns ISINs for instruments classified as:

 

Category Group
‘S’ – Swaps ‘R’ – Rates

‘T’ – Commodities

‘E’ – Equity

‘C’ – Credit

‘F’ – Foreign Exchange

‘M’ – Others (Miscellaneous)

‘H’ – Non-listed and Complex Listed Options ‘R’ – Rates

‘T’ – Commodities

‘E’ – Equity

‘C’ – Credit

‘F’ – Foreign Exchange

‘M’ – Others (Miscellaneous)

‘J’ – Forwards ‘R’ – Rates

‘T’ – Commodities

‘E’ – Equity

‘C’ – Credit

‘F’ – Foreign Exchange

DSB ISINs can be identified exclusively by the prefix “EZ”

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

 

The DSB’s Final Fee model outlining the model, user categories and associated privileges and costs is published here

Full fee details are also available in the DSB User Charges policy. Please contact secretariat@anna-dsb.com to obtain the suite of User Agreement policies.

It is possible to connect via the GUI or programmatically via FIX SPI or ReST API for real-time, on demand ISIN creation & retrieval.

It is free to use the DSB’s UAT service and Production Registered User service – both available by contacting technical.support@anna-dsb.com

Technical specifications for FIX are published here and ReST 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)

Given the DSB’s industry utility status, we are following standardised processes for on-boarding of users on the DSB service. To this end, we have created a standard set of documents that address the majority of the on-boarding questions we have received from industry – contained in the User Agreement, accompanying policies, the attached document and the DSB InfoSec FAQ which can be found here.

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

This is an attribute of the ISIN and the value of this field is to be “NA” for all OTC Derivatives as the ISIN definition does not contain any issuer information.

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 3rd January 2018 for all relevant parties that are obligated to meet Regulatory Reporting requirements.

The primary focus of the DSB has been to ensure market participants can meet their regulatory
obligations to create OTC-ISINs as and when a new instrument is quoted or traded for the first time
rather than to make available the pre-seeding of the entire universe of potential OTC-ISINs. The
reason for this approach is that we are aware of the regulatory requirement to report with an ISIN
by 9pm CET any instrument that was quoted or traded by 6pm CET that day.

The DSB committed a year ago to going live on 2 October to allow users to plan their approach for
production and worked hard to meet that goal. As of the 18th December, just over 1 million OTCISINs
have been created by on-boarded users since launch and we continue to encourage users to
connect that might need to create OTC derivative ISINs to the service as expediently as possible. The
DSB remains focused on ensuring that the infrastructure retains its integrity so that DSB ISIN data
can continue to be made available to market – with the various acceptable use provisions designed
to facilitate this goal.

The FX Swap template is designed to require the underlying FX Forward ISINs to be provided in the request to generate an FX Swap ISIN. That is, two ISINs will be required to generate a third FX Swap ISIN. The two FX Forwards must be over the same currency pair.

FX Spot is explicitly out of scope of the DSB however where the near leg is a Spot transaction, this is considered to be simply a special case of a forward and so the forward Product definition should be used to generate the ISIN of the near leg.

The current FX Swap template has been built to accommodate two Forward ISINs as underlying using the FX Forward Product Definitions. The DSB has had a use case submitted to accommodate Non-Deliverable forwards as underlying and will be designing a new definition for release in early 2018. In the interim, the Delivery Type of the two FX Forwards and the FX Swap can be set to ‘Cash’ to indicate non-deliverable.

The Bank of International Settlement – Triennial Central Bank Survey September 2016 was used to determine the classification of G8 currency pairs as FXMJ, Non-G8 currency pairs as FXEM and all others as FXCR.

Any given currency pair is categorised as follows:

If both currencies are FXMJ à categorise as FXMJ

If both currencies are FXEMà categories as FXEM

If above criteria is not met à categorise as FXCR

FXMJ

Australian Dollar
Canadian Dollar
Euro
Pound Sterling
Swedish Krona
Swiss Franc
US Dollar
Yen

FXEM

Brazilian Real
Danish Krone
Forint
Hong Kong Dollar
Indian Rupee
Mexican Peso
New Taiwan Dollar
New Zealand Dollar
Norwegian Krone
Rand
Russian Ruble
Singapore Dollar
Turkish Lira
Won
Yuan Renminbi
Zloty

All others are FXCR.

The DSB has adopted the ISO Currency Code list (ISO 4217) for all currency attributes. To accommodate offshore currencies, the DSB has introduced ‘Place of Settlement’ (ISO 3166) as an additional attribute in the FX Non-Standard Product Definitions. This allows an offshore location to be input against an onshore currency for example to recognise CNH, the user should input CNY into ‘Settlement Currency’ and Hong Kong into ‘Place of Settlement’.

Where required the DSB has implemented normalization rules over the attributes to ensure that a single ISIN can be generated for any combination of attribute values that constitute the same instrument.

For all normalization rules please refer to our DSB Product Definitions document published here

The exact approach adopted for Strike price and Price Multiplier is IEEE 754 double-precision binary floating-point format: binary64.

Furthermore, according to: http://www.json.org/ the attribute can be constructed as follows:

 

All the following presentations are valid and equivalent:

    • “StrikePrice”:4.5E76
    • “StrikePrice”:4.5E+76
    • “StrikePrice”:4.5e+76
    • “StrikePrice”:4.5e76

The Product Definition documents reflect DECIMAL {15/14} following review of the JSON capacity.

The DECIMAL {15/14} refers to the length of accurate digits and not the actual length of the number.

The DSB will provide accuracy to the 15th digit but if the user submits 64 digits, it will be presented in exponent on the record.

The DSB is bound by open data principles meaning that all data submitted, used and made publicly available by the DSB must be free from any Intellectual Property restrictions. The Index enumerations provided within each asset class are in the form of the legal long name provided in an enumerated list and the contents comply with the above objective. At this stage no further indicators can be provided that don’t breach these principles.

Sources are as follows:

Rates – FpML Floating Rate & CPI

Credit – IHSMarkit

Equities – ESMA TTC Dataset

Commodities – TBC (Index), ISDA 2.0 (Reference Rate)

The DSB has sourced the list of Floating Rate Indices from FpML, specifically the following schema:

http://www.fpml.org/spec/coding-scheme/fpml-schemes.html#s5.91

The DSB is aligned with the FpML change process and cannot independently amend or add to the dataset. The DSB will work with industry and the index provider in the pursuit of enhancing the source enumerations in a timely fashion such that all required indices are represented.

The addition of new indices to the JSON schemas maintained by the DSB are subject to the Change and Challenge process policy to be published by the DSB.

The DSB has sourced the enumerated list from ESMA’s Transitional Transparency reporting data exercise that consolidated Index names traded and submitted by EU Trading Venues. This list is free from any IPR issues and is in compliance with our open data principles.

Unfortunately, there are no market identifiers provided and industry will be required to undertake a mapping exercise. The DSB has raised this to ISDA also who is exploring conducting a centralised mapping service.

The DSB is aligned with the ESMA change process and cannot independently amend or add to the dataset.

The addition of new indices to the JSON schemas maintained by the DSB are subject to the Change and Challenge process policy to be published by the DSB

The DSB has sourced the Index names from IHSMarkit and are published as the legal long name. This list is free from any IPR issues and is in compliance with our open data principles.

The DSB is aligned with the IHSMarkit change process and cannot independently amend or add to the dataset. The DSB will work with industry and the index provider in the pursuit of enhancing the source enumerations in a timely fashion such that all required indices are represented.

The addition of new indices to the JSON schemas maintained by the DSB are subject to the Change and Challenge process policy to be published by the DSB.

The DSB has sourced the Commodities Reference Rate from ISDA 2.0 2015 taxonomy. This list is free from any IPR issues and is in compliance with our open data principles.

The DSB is aligned with the ISDA change process and cannot independently amend or add to the dataset. The DSB will work with industry and the index provider in the pursuit of enhancing the source enumerations in a timely fashion such that all required indices are represented.

The addition of new indices to the JSON schemas maintained by the DSB are subject to the Change and Challenge process policy to be published by the DSB.

The Commodity Base Product/Sub-Product/Additional Sub-Product is defined by RTS 23 Regulation and will be the hierarchy that is put into the Production environment.

The values in this field are determined by the technical standard and there are no changes scheduled in the short term. The value of T – Term will be considered as part of the scheduled changes to EMIR in late 2018 to align with CPMI-IOSCO.

For instances where the enumerations are not relevant, the suggestion is to default to 1 DAYS.

A Proprietary Index workflow was created in order to facilitate the creation of OTC ISINs with proprietary indices as underlying. The relevant documentation can be found here.

‘Underlying Instrument Index Prop’ is the specific attribute field used for the Proprietary Index that has been submitted by users as defined in the workflow document.

On submission of an OTC ISIN request, users are instructed to input their unique company prefix followed by a “-“ followed by the index name eg ‘12345-ABCDEF’

Anonymised index names will be published by the DSB containing a unique company prefix prior to each index name submitted.

The Underlying Issuer type is a mandatory field required for the generation of a valid CFI code. The current 2015 ISO 10962 CFI taxonomy contains three values – Corporate, Sovereign & Local.

For instruments with Index underlier, this field is defaulted to ‘Corporate’ however is eligible for user amendment where required.

This attribute has been included in all Credit definitions to align with CPMI-IOSCO UPI list of attributes. Where this field is not relevant such as for Index & Index Tranche the DSB accepts a value of “n/a” in place of the usual enumeration list.

This field has a different interpretation depending on the asset class. For Rates particularly, the CFI working group assigned P – physical for all instruments other than non-deliverable indicating that the cashflows are physically delivered. Cash was reserved for non-deliverable instruments.

In any case, the attribute is optional and can be changed by the user on submitting an ISIN.

To ensure the OTC ISIN can be created, validated and returned to users near real time, the only validation the DSB performs on the underlying ISIN is syntactic validation. The onus is on the user to ensure the correct underlier is submitted for the correct template.

You should note that not all DSB ISINs that are created are being used for regulatory purposes, user have been creating DSB ISINs for internal use.

For full list of validations please refer to our DSB Product Definition documentation here