The problem with this is that new questions are just that – new – and unlikely to have been addressed by the standard. Oh, in some cases, yes, there can be applicability and alignment. But we should not accept it as de facto solution and blindly apply the prevailing standard, instead accepting that, as humans that created that standard, they likely couldn’t foresee every possible permutation or problem.
Herein we have just this approach, going through great pains to apply a solution that may not exactly fit the need. Examples follow.
FX Swaps reporting
For whatever reason, which has never been vetted, the powers that be decided that when requesting an ISIN number for an FX-related instrument from the DSB, that the currencies and their legs would be re-ordered to fit an alphabetical format.
From a regulatory perspective, this may or may not make sense. It likely can help aggregate transactions along pure currency pairings. Although, it may not represent the true directional movement of those pairs easily, except on a netted basis.
However, the market doesn’t trade alphabetically – nor does it book transactions as such. Rates USD to EUR and EUR to USD are inverse of each other. To be able to represent a transaction using only one representation (i.e. only shown as EUR / USD) would require either representing the rate agreed as it’s inverse (so not matching what really occurred in the market), and probably reversing the actual Buy/Sell indicator of a transaction (also distorting what has occurred from one party’s or both parties’ perspectives).
So, here, we are distorting the representation of what actually occurred in the marketplace to fit a standard that doesn’t fit the need. There seems to have been unilateral action by ANNA DSB to define something for their own purposes without knowledge of the industry mechanisms the identifier is meant to support.
Interest Rate Swaps Reporting
On Question 1, the issue of forward start IRS products is raised. This is a problem, as until the forward start date, two products that are the same in all respects, including expiry, have different price and risk profiles.
The answer is presenting again in terms of what is possible with ISIN to identify it, the primary point revolving around introducing the tenor of the forward start date. Including tenor in any reported ‘static’ instrument identifier (i.e. an identifier meant to represent a permanently unique and immutable representation) has significant issues – and had been discussed at length for at least 2 years within ISDA Symbology, and then within the ISO group that tried to resolve OTC for ISIN (that then gave rise to the DSB).
The answer then was that inclusion of tenor was a bad idea for many reasons, and introduced multiple data conflict and quality problems. Those issues have not changed – and introducing tenor here simply raises them again, possibly compounding them in two different directions. There is a reason this was not resolved previously. Forcing an answer now doesn’t make those issues go away – nor does ignoring the resulting consequences.
First, it would seem sensible that products with the same expiry, but different forward start dates should be uniquely identified from each other. For risk and valuation purposes, this is necessary. However, as those start dates come to be, those products naturally ‘merge’ and become the ‘same’. Yet now with potentially hundreds or even thousands of ISINs that are assigned to the same expiry, at some point, this will create fragmentation of the reality in the marketplace.
In many ways, this is a mirror issue to deal with stubs, between reset dates. Which also has not been addressed. But if the solution apply here to forward starts is applied to stubs, the data quality will plummet rapidly.
The second problem is not as problematic – although how to manage it in the data is curious, and the resulting proliferation of ISINs that are also, effectively the same. “IR Term of Contract” – in footnotes 33 and 34, specify that the data should not change, and be carried. Which, up until that forward start date, should be fine. However, in the examples, a forward start date of “none” is provided.
When you fall under the “8 years” as provided in the example, what is the procedure? If I have a “no forward start” with the expiry matching 28/02/2028, but on 8 years minus one day, the IR term is not 8 years – so ostensibly would get a different ISIN, and these would all be different than a ‘standard’ forward that only has an expiry.
Physical / Cash or Deliver/Non-Deliver
There has been confusion from the start, especially when crossing asset classes, on what is mean by “Physical” versus “Cash”. Which, in the case of commodities or other physical assets may have more clarity – but when dealing with currencies and derivatives of such, presents an issue.
First, ‘physical’ would seem to not apply when dealing only in cash – ‘Cash’ logically being the only way to settle. But again, trying to fit existing definitions onto something not exactly intended for the sake of preserving ‘standards’ (as opposed to re-examining decisions) we end up with a suit off the rack that doesn’t quite fit – a little baggy here, a bit too tight there.
Take a plain swap with USD one leg, and EUR the second leg. “Physical” is meant to now mean “Deliverable” – where both EUR and USD are exchanged for each leg. Meanwhile “Cash” is mean to not mean “Non-Deliverable”, to now mean that payment is is a currency other than the respective reference currencies.
The confusion: “Non Deliverable” in the marketplace has traditionally been used, specifically, to refer to a set of currencies that are actually non-deliverable (about 13 exist, give or take). So, we are impeding on that definition.
Further, what if settlement is in *one* of the currencies (say EUR)? Would that now be considered ‘Cash/Non-deliverable’ because USD is not exchanged as well? But what if both legs were EUR? Surely that would not be “Physical/Deliverable”?
It is clear what is intended, and the goal – but the tool being used does not fit the need. The confusion and resulting impact to data quality surely will be negative, and anything reporting will not really provide the accuracy needed, nor the transparency desired.
