There has been some excitable chatter recently from some commentators and trade associations around the use of Delivery Type within the OTC-ISIN. I hope this article will shed light on this matter, in the usual DSB manner: objective, evidence-based and neutral.
Why is Delivery Type Important?
Let’s start at the beginning: is this issue worth spending any time on? The short answer is yes, for anyone involved in submitting CFI codes to ESMA for any of their OTC derivative regulatory reporting obligations. For the longer answer, read on:
The Delivery Type is one of the attributes of the ISO 10962 Classification of Financial Instruments (CFI) standard, which is mandated by ESMA as one of the fields that needs to be reported under both EMIR and MiFID II. Additionally, this is not just any old field. In a previous blog, I explained that ESMA uses the CFI as its primary instrument classification mechanism and therefore many detailed technical validation rules depend on this value.
It is worth noting that the Delivery Type is also a required field under the finalised technical specifications of the Unique Product Identifier, which is the global regulatory community’s attempt at identifying and classifying OTC derivative risk within the global financial system. Therefore this issue is likely to become endemic within all jurisdictions over time.
What is the Issue with Delivery Type?
The main confusion that we have heard centers around which Delivery Type value to use when creating ISINs for interest rate swaps. The 2015 version of the ISO CFI standard mentions two relevant values here: CASH and PHYSICAL. Given European regulatory mandates on the use of the CFI code, the OTC-ISIN faithfully reproduces these two values to allow firms to satisfy their regulatory obligations.
Specifically, when a user requests an OTC-ISIN, they choose whether to create the swap with a Delivery Type of CASH or PHYSICAL. Depending on the value supplied, the DSB will create and/or return an existing ISIN, but the returned ISIN will depend on which value was supplied. In other words, the DSB will generate two separate OTC-ISINs for two product requests, even if the only difference between the products is the Delivery Type.
Some excitable commentators have concluded that this means the OTC-ISIN is not working as designed. Hopefully this blog will show that the real situation is the exact opposite. In fact, the creation of two separate ISINs based on CASH vs PHYSICAL is necessary to meet MiFID II regulatory requirements.
The justification for my bold statement is below:
- Delivery Type is a part of the ISO CFI Code standard, which means that a different CFI code will be generated depending on whether Delivery Type is CASH or PHYSICAL. See here: https://en.wikipedia.org/wiki/ISO_10962
- Both the ISIN and the CFI code are mandated attributes within the MiFID II Level 2 regulatory text (RTS23), which means that the supplied financial instrument reference data MUST include both an ISIN and the CFI code. See fields 1 and 3 here: https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160714-rts-23-annex_en.pdf
- ESMA has stated categorically that the ISIN value in the reference data attributes supplied in an RTS23 submission must only match a single set of FIRDS reference data attributes (this rule is also explicitly laid out in the ISO 6166 ISIN standard, which is why ESMA can rely on it totally)
Taking all three points together, it follows logically that a single ISIN must map to a single CFI code and two separate CFI Codes require two separate ISINs in order to allow the trading venue or investment firm to satisfy their MiFID II regulatory reporting obligation .
So to return to my bold statement:
- Choosing CASH vs PHYSICAL will result in two separate CFI codes
- Given the mandate of MiFIDII RTS23, separate CFI codes must by necessity require separate ISINs
- The only way trading venues and investment firms can satisfy their RTS23 regulatory obligation is to supply separate ISINs to ESMA for contracts whose only difference is Delivery Type
Given the excitement from some quarters, I want to emphasise that the above conclusion is not merely a point of view. It is the articulation of a set of uncontroversial facts alongside the application of uncontroversial logic, provided publicly for all to see and validate for themselves, which leads inexorably to the above objective statement of fact.
Do we need both CASH and PHYSICAL for IRS?
Whilst the excitable chatter has always been just that, it does raise one serious question that is worth delving into: do we need both CASH and PHYSICAL for IRS, or is it possible for a given product to be either CASH or PHYSICAL but never both? If the latter were to be possible, then any product will only have one CFI code and hence one ISIN. And therefore the problem is solved and everyone can go on their merry way and focus on other issues.
So is this feasible? The short answer is: maybe in the short-term, but definitely not in in the medium term! For the longer answer, read on:
The issue is that the Delivery Type is defined within the ISO CFI Code standard. Given ESMA’s clear-cut mandate to use this ISO standard, the market cannot just decide what to use, but rather we must all use the ISO CFI definition.
So what does the latest ISO CFI Code specification say about this matter? Unfortunately, a detailed review of the specifications has highlighted a discrepancy between the existing text of the ISO CFI Code specification (2015 revision) and the intent of the drafters of the text.
This ‘typo’ in the specification creates two inter-related complications:
- Will ISO revise the 2015 specification text with an errata addendum (or equivalent) that inserts the original intent of the drafters into the 2015 specification? If ISO does this, then both PHYSICAL and CASH will continue to be valid but atleast industry will have precise clarity on which to use when. Alternatively, ISO could recommend not changing the 2015 specification text and instead propose that everyone should wait for the next revision of the CFI specification, due in 2019. In this case it may be possible (subject to further detailed analysis) to use only CASH between now and the date of enforcement of the new CFI code revision, but it will definitely not be possible after the new CFI revision takes hold (assuming it contains something similar to the original intent of the 2015 drafters).
- What is ESMA’s expectation of the CFI code Delivery Type? If ISO does not provide an errata to the 2015 CFI specification, but ESMA assumes both CASH and PHYSICAL are valid and useful, then the perceived loss of Delivery Type information may be problematic for the European regulatory community.
The DSB is Ready to Help
By now, I am sure most readers’ heads are starting to spin and the main question in everyone’s mind is how to make the whole issue just go away. Luckily, there is indeed a path forward that involves relatively small pain for DSB users, based on two considerations:
- The DSB is involved in discussions with ISO to understand whether the ISO 2015 revision will be updated or not
- The DSB is involved in discussions with regulators to understand the regulatory appetite to simplify the Delivery Type model for IRS to a single value
We hope there will be clarity on both points in the coming weeks, after which we will provide clear and explicit guidance to DSB users and trade associations for onward dissemination to their members. This guidance will include details of how to populate the Delivery Type in order to receive the correct OTC-ISIN and CFI code for submission to ESMA.
And Finally
I will sign-off by reminding users of the benefits of leveraging the CFI codes being generated by the DSB. The good news for DSB users is that once the DSB provides its guidance, we will also work to ensure our CFI codes are consistent with the guidance. So users who are taking the official DSB CFI Codes will find that they have less work to do compared to others. My previous blog also explained other reasons why the use of the DSB CFI code will increase industry data quality in submissions to ESMA. I strongly recommend all users to follow this path.
Sassan Danesh
Management Team, DSB
