FAQ - Corporate Social Responsibility
FAQ - General Information
At this time, there are six scenarios for consumption of DSB data:
- 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
- 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
- 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
- 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
- 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
- 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)
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 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”
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.
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
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
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.
The FAQ addresses the fact that it is possible for a DSB FDL File to include more than one record for a particular ISIN.
This is a rare occurrence, but may happen when ESMA/the FCA publish data on FIRDS/FITRS after a set cut-off time and so the DSB may still be having unprocessed data for an ISIN, from the previous day, when a new data is received. This will result in multiple records for the same ISIN being recorded and so it is important for the user community to understand how these records should be handled.
Under these circumstances, the DSB recommends that the user should access the ToTV record with the latest LastModifiedDate, as that would have a complete dataset for that ISIN on that day.
Where there is a duplicate entry, the record with LastModifiedDate is the latest dataset for that ISIN.
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 requires the entry of underlying Reference Rates based on entries in the current version of the FpML Coding Scheme (eg: “USD-SOFR-COMPOUND”). In order to support conformance to ISO20022, the DSB also maps each FpML Reference Rate to an equivalent ISO Reference Rate value that is determined in the following way:
- Set ISO Reference Rate to the appropriate code (if present) found in the ISO20022 BenchmarkCurveName2Code codeset.
- Else, set ISO Reference Rate to the appropriate code (if present) found in the ISO20022 BenchmarkCurveNameCode codeset.
- Else, construct the ISO Reference Rate value by removing any currency prefix from the FpML Reference Rate and truncating the resultant text to max. 25 chars.
It is assumed that within the ISO20022 standard, BenchmarkCurveName2Code is, and will remain, a subset of BenchmarkCurveNameCode. However, the two code sets have been listed separately in the above methodology in order to recognise their different capacities within the relevant regulations.
This approach is intended to allow for the reference rates currently published by FpML and any additional reference rates that may be added in due course.
Please refer to our Brexit page.
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.
- Please contact technical.support@anna-dsb.com in the event of any connectivity or other technical queries.
- Please contact secretariat@anna-dsb.com for all queries about Product Definition templates.
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
In order to reduce number of failed ToTV File Download requests, the users are requested to set up their processes such that they start polling the DSB’s ToTV File
Download data no earlier than the daily ToTV files may be possibly made available, specifically:
ToTV v1 File Download users are asked to avoid sending requests to the DSB for the daily files download
- between midnight and 10:00am CET for Production
- between midnight and midday CET for UAT
ToTV v2 File Download users are asked to avoid sending requests to the DSB for the daily files download
- between midnight and midday UTC for UAT
DSB ToTV current operating model document is available here.
DSB UK ToTV/uToTV specification is available here.
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: https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160714-rts-23_en.pdf.
Q: When was the last DR test?
A: The last DSB DR test was invoked against the DSB UAT environment, between the 16th July – 10th September 2021
Q: How long did the DSB take to complete the invocation?
A: The DSB completed the invocation to the secondary region in 4 hours and 5 minutes. The RTO (recovery time objective) is 4 hours. The issues causing this slight delay have been investigated and changes have been incorporated in the run book to ensure the next invocation is within the RTO.
Q: When is the next DR test?
A: The DSB Technology Advisory Committee (TAC) will provide further guidance on this at the next scheduled TAC meeting on Wednesday 3rd November 2021.
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.
The possible error messages provided by the system is dependent on the user’s request payload and data input. Users are recommended to use the UAT environment to validate the correctness of their query or request payload, test new standardization rules, record error messages, etc. all in accordance with the DSB Acceptable Use Policy.
The DSB provides ISIN templates to ensure acceptable payloads and data.
The Product definitions in effect for a specific environment can be downloaded via the File-Download service via the following links:
UAT
https://uat.anna-dsb.com/file-download/json-schema/isin-product-definitions/
Production
https://prod.anna-dsb.com/file-download/json-schema/isin-product-definitions/
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
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.
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
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.
Expand List
FAQ - Product Information
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
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.
FX Swaps that are based on non-deliverable or offshore variations of non-deliverable currencies are supported through the Non-Deliverable Swap (FX.Forward.NDS) template. The template supports the input of the ISINs of two matching non-deliverable (FX.Forward.NDF). or non-standard FX forwards (FX.Forward.Non-Standard) that have identical currency pairs and differing expiry dates.
Non-Deliverable Swap ISINs for Offshore variations of non-deliverable currencies (such as the Chinese Yuan/Renminbi) can be generated using a pair of underlying non-standard FX forwards (FX.Forward.Non-Standard). In this case, the underlying ISINs should include the ISO 4217 currency code (eg: CNY) and an appropriate ISO 3166 Place of Settlement (eg: “Hong Kong”).
The DSB has sourced the list of Floating Rate Indices from FpML, specifically the following schema:
https://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.
Users submitting a value for Settlement Currency in any FX ISIN product template are advised that the attribute is optional and should not contain XXX without prior authorization of the DSB Product Committee.
Users are requested not to submit a value of XXX which is defined in the ISO 4217 standard as “no currency involved in the transaction” and thus is not seen as appropriate for use in FX instruments.
The Product Committee requests that users wishing to submit XXX as an input value should provide a business case to secretariat@anna-dsb.com with supporting information.
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’.
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.
The FX Swap template is designed to allow two underlying FX Forward ISINs (based on the same currency pair) to be specified in the generation of an FX Swap ISIN.
In the case of FX swap transactions that are concluded by way of a strategy involving two separate legs, the near leg might be such that would be a spot transaction if it were concluded as a standalone transaction. However, in the specific context of this approach to an FX swap such a near leg should be regarded as a forward with a spot tenor.
Similarly, if you are looking to generate or retrieve an ISIN for an FX Swap instrument where one of the legs has an spot tenor, it will be necessary to use the ISIN for an FX Forward with the relevant expiry date (being the settlement date for the near leg) for the near leg underlier.
Best practice for the use of templates for IR Basis (Float vs Float) Swaps – as agreed by the DSB Product Committee (Feb 2019)
In order to ensure that ISINs for IR Basis Swaps (ie: Float vs Float) are generated in a consistent way, DSB users are advised to follow the guidance provided below.
For Interest Rates Swaps based on a pair of underlying floating reference rates:
- If the two legs have different Notional Currencies : use the Cross-Currency Basis template
(Request.Rates.Swap.Cross_Currency_Basis.InstRefDataReporting.json). - Else: If both legs are standard floating Reference Rates (eg: Libor, Euribor etc.) : use Basis template
(Request.Rates.Swap.Basis.InstRefDataReporting.json). - Else: If one leg is a standard floating Reference Rate and the other leg is an OIS Rate : use the Basis OIS template
(Request.Rates.Swap.Basis_OIS.InstRefDataReporting.json). - Else: If both legs are overnight interest swap rates (eg: EUR-EONIA-OIS-COMPOUND) : use the Basis OIS template
(Request.Rates.Swap.Basis_OIS.InstRefDataReporting.json).
The DSB is aware of the increased use of cross-currency Basis OIS and the PC will continue to monitor the situation and will follow up as required.
The DSB supports the creation of ISINs for several types of FX Forwards*:
FX Forward:
• Where both currencies are deliverable.
Non-Deliverable Forward (NDF):
• Where one or both currencies are non-deliverable (in the context of the trade) and require a Settlement Currency.
Non-Standard Forward:
• Where the FX Forward does not adhere to the standard instrument structure or
• Where the FX Forward is based on an Offshore variation of a non-deliverable currency (such as the Chinese Yuan/Renminbi). In this situation the Offshore variation of the currency requires a Place of Settlement to
provide a complete definition since the currency is not included in the ISO 4217 currency list.
* In addition to the above, the DSB also supports a number of specialised FX Forward products: Vol Var, Contract For Difference, Rolling Spot, Spreadbet and these fall outside the scope of this note.
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 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 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 Product Committee recommends that the Settlement Date is used to populate the Expiry Date attribute when generating / retrieving an FX Forward or Non-Deliverable FX Forward ISIN since fixing would occur ahead of any settlement.
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.
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.
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 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.
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 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.
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.
An FRA accrual runs from an Effective Date to a Termination Date but the FRA actually settles and expires on the Effective Date. For this reason, even though the FRA technically expires on the Effective Date, the DSB Product Committee recommends that the Termination Date is used to populate the Expiry Date attribute when generating / retrieving an FRA_Index or FRA_Other ISIN.
• In order to ensure consistency when creating or retrieving ISINs for Credit Derivatives where the underlying index does not have a Series, Version or Term (such as the iBoxx family of Total Return Indices), the request to the DSB should apply the following standard input values:
• Underlying Credit Index Series: 1 (one)
• Underlying Credit Index Version: 1 (one)
Note : A standard value for the Underlying Instrument Index Term Unit / Value has not yet been agreed.
• This advice applies to the following Credit templates:
• CDS Index Tranche
• CDS Index
• CDS Total Return Swap
• Non-Standard Credit Swap
• Non-Standard Swap (where a Credit Index is included)
• Non-Standard Other Derivative (where a Credit Index is included)
Expand List