About a-team Marketing Services
The knowledge platform for the financial technology industry
The knowledge platform for the financial technology industry

A-Team Insight Blogs

MiFID II – Why ISINs for OTC Derivatives are Bad for Transparency

Subscribe to our newsletter

By: Amir Khwaja, CEO of Clarus Financial Technology

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.

TradeWeb APA

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)
  • ISIN
  • 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 let’s 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 list 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 harder 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 and 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 there 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 and they 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?

Let’s try a simple back of the envelope calculation.

Let’s 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 let’s 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.

Final thoughts

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.

Anyone listening?

Please email/call/badger your regulator/ESMA/MEP/EU Commission.

This article first appeared on the Clarus Financial Technology blog

Subscribe to our newsletter

Related content


Upcoming Webinar: How to ensure employees meet fit and proper requirements under global accountability regimes

Date: 17 September 2024 Time: 10:00am ET / 3:00pm London / 4:00pm CET Duration: 50 minutes Fitness and proprietary requirements for employees of financial institutions are not an option, but a regulatory obligation that calls on employers to regularly assess employees’ honesty, integrity and reputation, competence and capability, and financial soundness. In the UK, these...


Snowflake and NVIDIA Expand Collaboration to Accelerate AI Productivity in Data Cloud

Snowflake and NVIDIA have expanded an existing collaboration by bringing together the full stack of the NVIDIA accelerated compute platform with Snowflake’s Data Cloud data foundation and secure AI. The result, a combination of computing power and infrastructure designed to accelerate AI productivity. The expansion builds on Snowflake and NVIDIA’s previously announced NVIDIA NeMo integration...


Data Management Summit London

Now in its 14th year, the Data Management Summit (DMS) in London brings together the European capital markets enterprise data management community, to explore how data strategy is evolving to drive business outcomes and speed to market in changing times.


A-Team Group’s Valuations Vendor Directory 2009

An indispensable guide to valuations professionals seeking providers of services in the asset valuations market. A-Team Group’s latest release in its series of directories – available for FREE download – focuses on vendors of valuations data, models and analytics. But this is not just another list of firms with their telephone numbers – you can get that...