Transaction Reporting and ISO 22

by Alan McIntyre

I’m doing the industrious people at the International Organization for ISO ImageStandardization a disservice as it’s really ISO 20022. But ISO 22 is catchier and requires far less effort than ISO Twenty Thousand and Twenty Two. And let’s face it, if we need to get our heads around yet another machine readable language then let’s economise on effort where we can. So that’s settled (and please forgive me ISO people) but ISO 22 it is then. 

A non-technical technical overview

In non-technical terms ISO 22 is an XML (Extensible Markup Language) schema that defines a set of rules for encoding documents in a format that is readable by both humans and machines. In other words, a map of which fields need to be populated in what sequence, and a data dictionary prescribing which data elements can be used.

Let’s look at an example. In the MiFIR Transaction Reporting ISO 22 spec that ESMA published earlier this year, The XML block for the fields relating to the ‘Buyer’ are defined as follows:

MESSAGE ITEM XML TAG
Buyer <Buyr>
Account Owner <AcctOwnr>
Identification <Id>
LEI <LEI>
MIC <MIC>

If a valid LEI code or MIC code is populated, the Buyer section is completed, as the entity that is buying is adequately described.

The XPath (path through the XML) is shown below where an LEI is used to identify the Buyer:

<Buyr>

     <AcctOwnr>

          <Id>

               <LEI>54930030CBHVCO154L54<LEI>

In the example above, because the XML path starts at the <Buyr> tag and ends with <LEI> tags populated, we know an LEI is being used to identify the Buyer.

If the buyer is a person, and not an entity, the ISO 22 schema lists the fields required to identify that individual:

MESSAGE ITEM XML TAG
Person <Prsn>
First Name <FrstNm>
Name <Nm>
Birth Date <BirthDt>
Identification <Id>

The Xpath for Buyer when the buyer is a person is illustrated below:

<Buyr>

     <AcctOwnr>

          <Id>

               <LEI>

                    <MIC>     

                         <Prsn>

                              <FrstNm>Joe<FrstNm>

                              <Nm>Bloggs<Nm>

                              <BirthDt>1985-12-25<Birthdt>

                              <Id>IE19800113JOE##BLOGG<Id>

The location of the populated fields indicate that it’s a person and that they are the Buyer because, again, the XPath begins with <Buyr>.

As well as defining the location and order of the fields, the schema can also be used to define the acceptable data elements or formats for any given tag. Some of the above tags are defined as:

<LEI>                             LEI Identifier

<MIC>                          MIC Identifier

<FrstNm>                    Max 140 Text

<Nm>                           Max 140 Text

<BirthDt>                    ISO Date

The clear and often strict definition around how the tags must be populated leads to the ability to quickly determine if messages are ‘schema valid’. Herein lies one of the benefits that the regulators are seeking to take advantage of, namely, that by using an XML schema such as ISO 22, firms will need to utilise messaging software that will immediately detect and flag when a field is incorrectly populated. <BirthDt>Tuesday <BirthDt> for example will immediately fail as the ISO Date scheme requires the format yyyy-MM-dd in order for the message to be schema valid.

Other fields can be defined to an even greater precision, for instance only permitting two or more exact values.

<MiFIDInvestmentParty> for example is defined as True False Indicator so that only values of ‘TRUE’ or ‘FALSE’ are permitted.

<DerivativeNotionalChange> is defined as Variation Type 1 Code which is a bespoke XML variable defined to permit only ‘DECR’ or ‘INCR’ for decrease and increase respectively.

This ability to define what fields come in which order, the relationship between different fields, and the formats or values that are acceptable is a methodology well suited to transaction reporting. Such clearly defined standards harmonize the data and provide better, more complete data. That’s the theory driving why we are seeing the increased usage of ISO 22 by regulators.

Regulatory demand for ISO 22

ESMA has stipulated in RTS 22 of MiFIR/MiFID 2 that ISO 22 is the only format in which the NCAs (the National Competent Authorities in each EU member state) will accept MiFIR transactions reports. Therefore, the ARMs (Approved Reporting Mechanism – the MIFID II equivalent of a Trade Repository) must send ISO 22 formatted reports to the regulators. Any firms that choose to report directly to an NCA must also do so using ISO 22.

MiFID II also supports the concept of a firm reporting directly to its chosen ‘home’ NCA and the NCA then having the obligation to share these reports with the other member state NCAs that are entitled to that data, based on factors such as the branch location where the trade was executed. This transmission of data between the different NCAs in Europe is similar mandated to be done in ISO 22. The aim is clearly to have a common standard across the various NCAs from the 28 EU member states (including the UK for the time being until agreement and clarity emerges on the UKs post-Brexit regulatory landscape).

Raising the bar

ESMA currently has a consultation open – until 30th November – on transaction reporting under SFTR (Securities Financing Transactions Regulation). This consultation along with the previous one back in March take the adoption of ISO 22 to a whole new level. ESMA is mandating that within SFTR all the reporting, “by all actors without exceptions”, to the Trade Repositories along with all the reporting from the Trade Repositories to the NCAs will be done using ISO 22. In the current consultation paper the Paris-based regulator has gone further and stipulated that even the TRs exchanging trade data for the purposes of the Inter TR Reconciliation must do so using an ISO 22 format. This soup-to-nuts prescription of a single schema across the reporting firms, TR infrastructure, and regulators is a first for this type of legislation. It’s also a very interesting trend for the industry.

The objectives of this approach are that by mandating the use of a clearly defined schema across the entire SFTR reporting spectrum discrepancies, inconsistencies and interpretive issues will be avoided. The whole concept of schema valid means that some quality controls are baked-in from the very outset.

Is all this really necessary?

The need for clearly defined fields might seem self-evident and obvious but the EMIR experience was that some of this wasn’t defined clearly enough and it lead to a lot of issues. If we take the field Price Notation for example, the original EMIR RTS defined it as:

  Field Format
13 Price notation E.g. ISO 4217 Currency Code, 3 alphabetical digits, percentage.

 

At first glance this seems straight forward. A 3 character ISO currency code, 3 alphabetical characters or percentage. Ok got it.

Wait, hold on. Is that ‘E.g.’ as in for example? So if these are only examples then what else is permitted? Also what are these 3 alphabetically digits? Come think of it isn’t ‘alphabetic digits’ a contradiction? Does that mean 3 alphanumeric characters or does it mean ‘3 alphabetical characters’?

If we take ‘percentage’, even that simple looking concept led to many issues. Is that the word ‘percentage’? Is that ‘PCT’ for a three letter code? Is ‘Percent’ ok? I saw many different populations of this field intended as percentage including the % sign and ‘100’ –  and that’s before we consider Basis Points, BPS or all the other related concepts. That “E.g.” at the start of the RTS definition for this field led to all sorts of different interpretations of what was required. Since this is a field required to match within the Intra/Inter TR reconciliation, these issues were not confined to the regulators’ ability to aggregate the data.

When I raised this in a Roundtable session between the TRs and ESMA, they explained that they were unable to change the RTS definition at the time under the EMIR legislation. The EMIR Q&As and the ESMA Level 1 and Level 2 validations that were subsequently implemented were therefore not able to resolve the confusion around this field and it was left to the individual firms and TRs to try to resolve the issues. The EMIR Article 9 RTS rewrite that is currently going through the European Commission process ESMA has finally rectified this by redefining the field as:

    Field Format Applicable types of derivative contracts
18 Price notation U = Units,

P = Percentage

Y = Yield

All contracts

EMIR doesn’t currently have ISO 22 as a reporting schema, but if it did then this sort of clear list of three acceptable values would be perfect for being defined with the schema. The equivalent field within MiFIR is defined accordingly with the MiFIR ISO 22 schema with acceptable values to indicate Percentage, Yield or Basis Points:

<Pric>

     <Pctg>

     <Yld>

     <BsisPts>

Wrapping up and what next

Whilst EMIR itself has no official required usage of ISO 22, it’s clear that the EMIR experience is one of the main drivers for why ESMA is increasingly adopting this schema. The EU supervisory authority is clearing hoping that the usage of a common ISO 22 standard in reporting will improve the quality and consistency of reporting. The transaction reporting under RTS 22 of MiFIR/MiFID II is one such example. The front to back adoption throughout SFTR is another one. It will be interesting to see whether the EMIR review currently being undertaken by the EU legislators determines that there is a sufficiently strong argument to enforce ISO 22 for EMIR reporting as well.

Outside the EU it will be interesting to see whether other regulators decide to follow suit. The CFTC has commented on the lack of a common standard in their consultation paper earlier this year. The US reporting model is predominantly FpML based though so it would arguably be a controversial move to suggest changing from FpML to ISO 22. As I noted recently in The OTC Space, as ASIC similarly to EMIR has dual-sided reporting, it’s more than likely that the Australian regulators are watching the developments in Europe with interest. I guess we’ll see where the journey takes us.