One of the goals of MiFiD II is to improve transparency of price and volume in financial markets and the implementation date of January 3, 2018 finally gave me an opportunity to look at the post-trade data made publicly available by Trading Venues and Approved Publication Arrangements (APAs).
This data relies on ISINs for OTC Derivatives and the sheer number of ISINs that have been created are an obstacle that is harmful to the goal of transparency. While there are obvious solutions to this problem, which must have been pointed out before by many firms, I wanted to lay out the scale of the problem and make crystal clear why it should be tackled with the highest priority.
The International Securities Identification Number (ISIN) is a code that uniquely identifies a specific security.
ISINs are universally recognised and I have come across them mainly for Bonds, where even though a Bond is referred to with short name constituted from the Issuer, Maturity date and Coupon, the ISIN is the categorical reference, widely available and extremely useful.
In 30 years, I have never come across ISINs being used for OTC Derivatives.
Until now with MiFiD II.
The ANNA Derivatives Service Bureau (DSB) is the numbering agency that generates ISINs for OTC Derivatives and their website is here.
The industry has been furiously generating the required ISINs for OTC Derivatives in the lead up to the January 3, 2018 implementation date of MiFID II.
According to a post on LinkedIn from Sassan Danesh from the DSB Management team, over 2 million ISINs were created in Q4 2017 leading up to January 3, 2018!
That is a phenomenal number! Certainly a lot of work must have gone in at many firms and the DSB to get this done for the deadline.
Further just for Interest Rate Swaps (Fixed vs Float) over 280,000 ISINs have been created so far and more continue to be created each day!
Now like any good politician, I like large numbers and like most members of the public I am impressed by them.
But in this case I am very concerned that so many ISINs actually harm transparency.
Let me explain why.
Using the TradeWeb APA as an example, I can see the public data for Bonds and Derivatives.
- Trade execution time
- Venue, in this case TREU (MIC code for Tradeweb MTF)
- Asset Class, Bonds, Interest Rate Derivative, Credit Derivative, …
- Price, Currency and Quantity
The required fields specified by ESMA.
For Bonds this data is great, as the ISIN readily resolves to a security that I understand.
Using a Clarus Microservice (which uses FIRDS data) I can resolve the name in one line of python code.
As used by many Venues, including TREU; in this case the Italian BTP 5% Aug34.
ISIN for an IRS
Now lets do the same for an IRS.
Showing TRDX and TREU as the two venues that have used this ISIN and the full name.
The name includes the date 20180110 in YYYMMDD format.
So it looks like a 10Y EUR IRS.
Odd that it only shows on two venues as I am sure given the size of the EUR IRS market, it would have traded on others?
The nagging concern I have is that other venues may have used a different ISIN. Not that I have any evidence that they did, but with 280,000 to select from, it is entirely possible to not find the correct one or to find a duplicate or one that appears similar.
My other concern is having to assume that this is a 10Y Swap from the date.
And this takes us to the crux of the problem.
Maturity date instead of Tenor period.
Creating ISINs for Derivatives
The ANNA-DSB generates these ISINs and the DSB GUI can be used to look at data for an ISIN and doing this for our ISIN above, we see that this record that was created on 8 Dec 2017.
There is an Expiry date field with 2028-01-10, a Reference Rate EURIBOR and Reference Term of 6 months.
So I would have to assume that if this was traded on 8 Jan 2018, then it is a standard spot starting 10Y EUR IRS Fixed vs Euribor 6M, the market standard trade and one of the largest OTC derivatives traded on a daily basis.
And on 9 Jan 2018, I would need to look for a different ISIN with expiry date of 2028-01-11 and on 10 Jan 2018 for one with an expiry date of 2028-01-12 and so on.
This is why there are a massive number of ISINs, the >280,000 number above and this lists keeps growing day by day, week by week, month by month.
Which makes it non-trivial to compare the price of a 10Y EUR IRS across venues on the same business day.
And makes it even hard to build a historical time-series of the price of a 10Y EUR IRS.
Two use cases that are very common and important in price transparency.
Now Clarus can help, as we will map ISINs to commonly used identifiers like Tickers.
But we really shouldn’t have to do this …
It Gets Worse
And what makes it worse is that even with these 280,000 ISINs we fail to get the granularity we need for price transparency.
Because if we want to compare prices between Trade Venues, then we need to know that the interest rate swap we are looking at is the same on each venue. But to do that we need other fields that are simply not in the static data for this ISIN.
- Bi-lateral or Cleared, which differ in price
- CCP, an EUR IRS has a different price at LCH, Eurex or CME
- With one date only, how do we know which are Forward Start Swaps, as a 5Y5Y would have the same expiry date as a 10Y, but a very different price. Do we rely on the text in the name?
How do we know which of these is assumed by the ISIN created by a Venue.
Indeed how does another Venue know what the creating Venue meant in order to decide whether to use an ISIN or create a new one.
280,000 ISINs for Vanilla Swaps and still not the granularity we need.
That cannot be right.
A Simple Fix
Generally I am wary of simple fixes as often they do not exist.
But in this case there is one.
We need the ISIN record to hold a Tenor Period instead of Maturity Date.
That way their would be one ISIN for a standard 10Y EUR IRS – say equivalent to the well known Bloomberg Ticker EUSA10. (I will stop myself segueing into why using existing well known market symbols instead of creating new identifiers would have been better …)
This new ISIN with Tenor Period of 10Y, could be used every day for a 10Y EUR IRS.
Trading Venues would not need to create new ISINs each day for the month ahead.
Trading Venues would not step on each others toes and being unsure if one was created, create their own, making a nonsense of comparison.
Users of the public data would not need to first search each day for a new ISIN for a 10Y EUR IRS.
So much overhead and complexity would no longer be needed.
Simply because there would be far less ISINs.
How Many ISINs?
How many do we need for vanilla Interest Rate Swaps?
Lets try a simple back of he envelope calculation.
Lets assume 18 clearable currencies for which IRS are traded in Europe, 15 instruments on a curve, that is 270, lets round it up to 300.
Then with our wish list of enhancements to separate CCPs, Forward Starts, we could double or treble this number at most, but to be conservative lets call it a round 1,000.
1,000 vs 280,000!
That is 0.4% of the existing count.
Soon to become 0.3%, then 0.2%, …. you get the point.
I could look at the numbers for OIS Swaps (50,000), Basis Swaps (25,000), Cross Currency Swaps (20,000), … but that would just make the same case again.
As for the 500,000 FX Forward ISINs and 150,000 FX Swaps ISINs; the less said the better.
I don’t know how we have ended up in this situation.
But it should be clear from the above that it not sensible for OTC Derivatives.
We could achieve a massive reduction in complexity and cost.
Saving everyone’s time and resources in creating and looking up ISINs.
Trading Venues, APAs, DSB and Users of the public data – all would benefit.
Transparency would be simpler, less error prone and achievable.
Surely that is a key goal of MiFID II.
I know CFTC started a Project KISS in 2017.
MiFid II Transparency is crying out for a Project KISS.
Please email/call/badger your Regulator/ESMA/MEP/EU Commission.
25 thoughts on “MIFID II – Why ISINs for OTC Derivatives are Bad for Transparency”
Segue versus SegWay 😉
Good blog post, the ISIN concept has gone wrong for OTC products, much to the amusement of the market who realise that transparency hasn’t been achieved.
Finding a unique ID to describe a contract which itself is defined by many data points was always going to be difficult.
Thanks Bill, edited to segueing.
Difficult yes, but still achievable.
Great Article Amir. I would like to have a chat with you on a bit of history on this, as I was “in the room” for many of these conversations. I believe ESMA was trying to accomplish to much with a single identifier and lead to some poor conclusions. I am a proponent of a more granular ID in the OTC space as a means to promote operational efficiencies in the post execution space, but a higher level is needed for pre-trade transparency. One of the issues with Tenor in ESMA’s mind was this:
Today I trade a 10 year vanilla interest rate swap: 01/10/2028 Tomorrow I know that it is a 9 year and 364 day swap (so what). I think you run into a problem from a risk perspective in five years. Fast forward to 01/10/23 and Someone trade a 5yr swap for 01/10/2028. Under his view there would be a swap with ID 1234 showing a 10 yr swap and someone would have an ID 3456 for a five year swap. They are the same darn thing at this point even if they were not at the time of trade.
Thank you Michael, you make good points and it is great to hear the history.
However the concern you note that a 10Y swap in 5 years time is the same as a 5Y swap in 5 years time is not strictly correct as the aged Swap will have a very different fixed rate and due to convexity and dual curves (OIS for discounting and IBOR for forecasting) will have subtly different value and risk and should be differentiated.
I’d argue that ISINs aren’t ‘universally recognized’ even outside of OTC Derivatives. With over 1000 different identification schemes, specific to use-based contexts, ISIN is just one. Everything for Bonds is simpler mainly because it’s still mostly an RFQ environment – but look as bonds move to exchanges, and you see different tickers for each. Also, name changes and other corp actions change ISIN, CUSIP, Sedol and tickers for bonds (and every other product).
What is the reasoning to ‘normalize’ swaps for ISIN purposes? Shall we get rid of the concept of Puts, and just make everything ‘calls’ by flipping the components? That may work for some people – but the concepts exist for reason for some processes.
I do not think it is achievable to create a unique ID to identify an instrument – OTC or otherwise. In data modeling, you’re always going to have to deal with context – which is consistently ignored in this instrument identification space. Different data is need attached to an instrument at different points and for different uses. A framework approach is needed – not a pure ‘hierarchy’ either. You do not have the right experts at the table working on this issue, and those in control aren’t going to allow that any time soon (hint; there’s money and careers at stake).
The hubris and ignorance shown by those claiming the DSB as a rousing success, and promoting ISIN as the answer to all the world’s problems is indeed, as Bill notes, cause for much amusement. But more of the “watching a train-wreck from inside the train” variety.
OH – and just a note on your simple fix. You need that, yes – something with the tenor period. Which also ties to any ‘parent’ curve as well as underlier (index or otherwise) that the curve is based on. THEN you need to be able to dynamically link that to another identifier on a daily basis that represents the fixed maturity date for those that hold that position after execution.
Just an FYI; FIGIs exist already for your tenor-based solution, and are tied to a FIGI Curve identifier and a FIGI for the underlier. As I’ve said for the past 2 years – an open, free identifier already exists for OTC; why does the industry have to pony up 9MM Euro (likely more) a YEAR to create and maintain something new, that obviously wasn’t going to work in the first place?
Yes I am aware of OpenFIGI and I was going to go into that in my blog, but thought it would take too much space and detract from the main point.
We have used OpenFIGI and worked well for us for a different use case, though I have to admit we used the Ticker much more than the FiGI identifier itself.
Reflects my thoughts exactly Amir. What makes it even sadder is that, there are comparable transparency solutions like FINRA-TRACE and SDR that could have been replicated (gives us a globally consolidated solution across the board). We seem to have added complexity and compromised the spirit of the regulation.
OH! One last note – do NOT use isin.org. That is not associated with ISO or ANNA in any way.
Ok thanks, after looking at that site more carefully I have removed the link.
No-one in their right minds will be using ISINs for derivatives as anything other than a necessary field for regulatory reporting. It is clear that far too much information is missing from the definition data set to create an identifier that will uniquely refer to a specific set of contract variables. Even though the ISIN for an IRS will need to change every day, a single ISIN can still be applied to an IRS contract with a range of different attributes, so it is largely useless.
The whole thing was badly thought-through and predicated on a political goal (they chose ISINs because they are issued by non-profits) and misunderstandings. Contracts are not, by their nature, instruments. Therefore it should be no surprise that using instrument identifiers to attempt to capture them will not work. Despite the standardisation of ISDA agreements a contract can be varied in any manner agreed to by both parties. What’s the DSB going to do with that?
One misconception – ISIN is not issued by non profits. That misconception continues to be encouraged. Individual Numbering Agencies are mostly for profit firms, with a local monopoly, unregulated in their marketplace. ANNA is a trade association of those firms. Which is also unregulated. They get people to infer they are non profit by saying they are an ISO organization, which is further disingenuous. They are for profit monopolies, and inEurope they are now a coercive monopoly with no regulatory oversight.
We have received a good number of comments, both public and private, that agree that ISINs as currently created for OTC Derivatives are problematic, but not a single comment justifying why these ISINs are appropriate. It would be good to hear from those that disagree with my article.
Look at those 2 ISINs:
Both are for an IRS EUR Fixed-Float 3M maturity 03-01-2019
Only difference is the registered reference rate:
EUR-EURIBOR-Reuters for EZJ56Y4L43L9
EUR-EURIBOR-Telerate for EZ26V979D731
So imagine how many we’ll end up with if we even have a differentiation by Euribor data provider 😉
Thank you for pointing out another example of why these ISINs are bad for transparency.
We are also aware that for some/many Swaps there exist two ISINs, one that specifies Cash and one Physical for Delivery type.
As the underlying of an IRS is a cashflow, we don’t need the Physical one.
I hope some MTFs/SIs/APAs are not using one and some the other!
I decided to look for the ISIN for a Vanilla IRS USD 5Y, which is SA vs Libor 3M, as would be traded today, meaning its maturity date would be 16-Jan-23.
So using the DSB Search tool I enter the following search string “Rates && Swap && Fixed_Float && USD && 20230116”.
Unfortunately it returns 5 ISINs!
While some are Libor 3M and others Libor 6M, so 2 would be reasonable to return, there should not be 5!
And as my registered account is limited to 5 return results, who knows whether more than 5 exist!
This is bad.
I would go for the following:
/Header/AssetClass:Rates && /Header/UseCase:Fixed_Float && /Header/InstrumentType:Swap && /Attributes/NotionalCurrency:USD && /Attributes/ExpiryDate:”2023-01-16″ && /Attributes/ReferenceRateTermValue:”3″ && /Attributes/ReferenceRateTermUnit:”MNTH” && /Attributes/DeliveryType:”CASH”
Which returns only 1 result. Should drop the Delivery Type criteria, you’ll have 3:
– 1 cash
– 2 physical with different notional schedules
Thank you for this.
ISIN is also a matching field for RTS 23 FIRDS reporting, which according to the latest ESMA opinion, that has yet to be revised, will be used to determine ToTV status.
If there are several ISINs for what is essentially the same OTC derivative contract, either users (venues / systematic internalizers) are entering the data differently to one another (eg delivery type) or the DSB are incorrectly assigning new ISINs based on constantly evolving instrument variables (eg maturity date). Worse still you could have different products assigned the same ISIN based on common core attributes applicable to both, but one product having additional building blocks that distinguish it from the other (eg exotics vs vanilla instruments). Each are detrimental to transparency and I would query the usefulness of the data. You would be comparing apples with oranges. Cleared contacts vs. bilateral. One contract cleared on one CCP vs. the same contract type cleared on another. One contract is subject to a CSA and another not, etc. Pricing will be markedly different. An unfunded OTC derivative is not the same as a funded bond.
Not only is transparency impaired but the orderly functioning of the markets too. How much cost has been incurred on delivering these reforms and how much business will be lost on systems development that prioritises achieving vague regulatory outcomes over client needs?
One positive of the current system is that it is clear over date/time boundaries which swap was traded. Since swap values can differ significantly from one date to the next due to end of month and other anniversary effects, anyone analysing IRS prices between days (which your system would make easier) should already be taking the date variations into account, so an extra step to get a different ISIN shouldn’t matter much.
A greater concern is that there are multiple ISINs for the same instrument – this has long been an annoyance in market symbols where there as many exceptions as there are rules.
Unfortunately this is an essentially impossible task because OTC derivatives can be so varied in every detail; some conventions are easy (what accruing convention on a GBP 20y float leg?) and some are hard (is a 1y QQ swap ending on an IMM date scheduled over IMM dates?). Unfortunately I think you’d optimise away a reasonable chunk of the symbols (maybe 50% or 75%) without making the systems that have to use them any less complex.
If the issue with multiple symbols for the same swap can be resolved, that is probably as much value as can be usefully gained here. The rest is a database query.
Phil, thank you for your comment, good to have one (partially) in support of ISINs.
However having thought about it more I an struggling to see how the current set-up of ISINs for OTC Derivatives is any better than allowing a free-for-all, so each MTF or APA to chose their own symbol or short name for the Swap traded or reported on their platform. As users of these MTFs will already be familiar with this symbol/short name, it will be more meaningful and it would be possible to build a dictionary to map between them. I think would be simpler than 2 million ISINs and growing.
The issue with many conventions is a valid one, but for transparency we are primarily concerned with the market standard trade, where specific conventions (day counts, rolls, calendars etc) are widely agreed and understood. Getting transparency on these would be a worthwhile goal, while the non-standard trades are infrequent and of lesser value for transparency.
Amir, good article and good comments, too. I fully agree that one ISIN per maturity date (and for Options also per strike Price) is completely against the concept of reference data. Why trying to make something to reference data which in the end is contract specific? A waste of resources. I had pointed this out to ESMA several times. Their reason for insisting on ISINs per maturity date was that for the transparency Regulation under MiFIR (e.g. RTS 1 = COMMISSION DELEGATED REGULATION (EU) 2017/587) they only have ISIN as a criterion to define e.g. the most relevant market of an Instrument, the Standard market size, the average value of Transactions or if a financial Instrument is illiquid.
So ESMA decided to save themselves the effort of extending their concept of financial Instrument by adding Tenor/maturity date and strike Price as separate criteria in Addition to ISIN. So they saved for themselves maybe 1 mio effort against several millions one-off and annual costs for the industry.
However, the industry can do better to cope with this. A pure OTC derivative does not require an ISIN to be reported under MiFIR. You can just report it without ISIN and use the MiFIR fields 42-56 to describe the Instrument. Only Systematic Internalisers need to provide an ISIN together with the reference data of the instruments for which they are SI to their NCA.
But for OTC derivatives there is no need to become an SI since SI Status is determined based on market share against the trading venues. Since there is no trading venue for pure OTC derivatives the SI Status for OTC derivatives is purely voluntary.
Therefore any SI who Requests OTC derivative ISINs from DSB for reporting its reference data to its NCA is itself part of the problem. If nobody would voluntarily become SI for OTC derivatives we would not even have ISINs for pure OTC derivatives.
So why are there SIs for OTC derivatives at all? Is this purely for marketing?
Thank you for your comment, very interesting and I was not aware of that.
What about Trading Venues though?
As they are the ones creating most of the OTC ISINs, which they must believe are required, as given the complexity not to mention the annual license fee at DSB, I would assume they would prefer to not use ISINs.
Sure for trading venues it is a nuisance to have to request a new ISIN for the same Instrument for every maturity date (and strike price). However, once an Instrument is traded on a trading venue I would not call it a pure OTC derivative anymore.
Comments are closed.