Camels are horses: the problem of identifiers under MiFID II

This article was first published by Thomson Reuters Accelus (a subscription only service) on 21 November 2016. 

We seem to be surrounded by questions of identity these days; a problem that was recognised and typified by the story of Theseus’s ship by the early Greeks. When Theseus and his young crew returned to Athens from Crete they did so in a ship with 30 oars. The ship was preserved by the Athenians down the ages by renewing the timbers as they decayed. Is this renewed ship, where none of the original timbers actually made the journey from Crete, still Theseus’s ship or has it become something different?

Today we face this question of identity in a slightly different form in terms of nationality. Whether we are European or British, British or Scottish, and what determines nationality in any case. The topic “Mistaken identities” is the title of this year’s Reith Lectures by Professor Kwame Anthony Appiah. In his lectures, he looks at what gives people their national identity, a question firms will be faced with when trying to categorise their clients.

In the regulatory sphere as well, questions of identity appear in several forms.  The Know Your Client (KYC) and Politically Exposed Persons (PEP) mean firms need to know that the person they are looking to deal with is who they say they are.  In reporting, firms need to identify who we are trading with; both individuals and companies. We also have to identify the traders within the firms themselves, and we need a way to identify the products being traded.

This piece will focus on the question of nationality and the use of identifiers for individuals and companies under MiFID II and some of the challenges that this will bring. We will deal with identifiers for instruments at another time.

MiFID II transaction reporting requirements seek to provide regulators with greater visibility of who is trading and who is making the investment decisions. This contrasts with MiFID where financial firms can often be identified with a global identifier (BIC or FRN codes) whilst other companies, partnerships and individuals are identified at a firm level using each firm’s internal identifiers. The lack of global identifiers makes it much more difficult for regulators to see what is going on across the market.

Identifying individuals under MiFID II

Under MiFID II ESMA has opted to use a suite of identifiers for individuals where the identifier to be used is to be based on the individual’s nationality. To my mind, it is unfortunate that they took a fragmented approach because it introduces an additional problem of what type of identifier to use, making reporting much harder. I presume this was a 28-country committee decision. As they say, a camel is a horse designed by committee!

The requirements for identifying individuals are specified in the Regulatory Technical Standards (RTS) 22 and a table of the required identifiers by nationality is illustrated in annex II of the RTS. The annex tells you which identifier should be used for each nationality. The table in annex II tells you what to use once you know the nationality of your client or trader.

Six of the countries opted to use the CONCAT approach as their only identifier. Other countries have elected to use national identifiers, passport numbers or tax numbers.

What is CONCAT?

As the name suggests CONCAT is a method to generate an identifier for individuals based on the compression or concatenation of four data elements:

1. Country code (2 characters: ISO 3166-1)
2. First name (first 5 characters padded with # where required)
3. Surname (first 5 characters padded with # where required)
4. Date of birth (YYYY-MM-DD)

The CONCAT is comprised of these elements in the order shown.

There is an argument that the four elements lack an important feature of an identifier, that of uniqueness. The cost of clashes, where two individuals are allocated the same CONCAT code, will be dependent on the frequency with which clashes occur.

The process doesn’t end there. Before creating the CONCAT, the names need to be subject to a transliteration process to convert them into a common Latin alphabet by removing punctuation marks: apostrophes, hyphens, accents, and umlauts. Titles should also be removed as well as prefixes such as “Van” or “De” or “De la”. I am sure there will be questions where individuals treat the prefixes as part of a single surname: or example, where Delarue is used by the individual rather than De La Rue.

What is the client’s nationality?

“Firms must ask both new and existing clients whether they have multiple nationalities and to notify their firm if they acquire or lose a nationality.”

Returning to the philosophical and social question of identity and nationhood: what is your client’s nationality? Rather than getting everyone embroiled in conjectures, ESMA has happily provided a waterfall approach to be used where individuals have multiple nationalities:

1. For EEA countries use the first country ISO country code when it is sorted alphabetically
2. Where there are EEA and non-EEA countries, the EEA countries take precedence.
3. Non-EEA countries use the first country ISO country code when it is sorted alphabetically

That means firms must ask both new and existing clients whether they have multiple nationalities and to notify their firm if they acquire or lose a nationality.

Even then, we need to know each client’s list of nationalities which might not be so easy to determine. In my case, which I am sure is not unusual, I was born in Guernsey but have Italian and Irish parents which may complicate things. I am living in the UK but I have never been through any citizenship process. So in all honesty, I’m not sure what my nationality is.

If I am a UK national, I would be identified using my national insurance number according to the table in RTS 22. But is it so simple?  I think I may have been registered as an Italian citizen and allocated a codice fiscal or Italian tax code.  So perhaps I would be classified as Italian, but I also used to have an Irish passport and I now travel on a Guernsey passport. So what nationalities do I have? I  have been told that anyone who has Irish parentage is eligible for an Irish passport. The problem is I am not actually sure what nationalities I have. As a client completing a form where I am requested to state all my nationalities I would have to do a significant amount of research just to determine how to fill in the form.

To help address this, it might be an idea to provide industry guidance for the public on how to determine your nationality. ESMA has not, however, provided any guidance regarding what constitutes nationality for transaction reporting purposes. Does citizenship, tax residence, domicile, place of birth, a passport, all qualify? We need to know the answer to be able to arrive at the appropriate identifier to put in the transaction report.

So taking my example, and assuming I am a national of the respective countries, you would get a table along the lines of something like this:

Nationality	Country code (ISO 3166)	Identifier to use per annex II RTS 22	Priority	Basis
British	GB	National Insurance number	1	First EU country alphabetically based on country code
Guernsey	GY	Passport	4	Not an EU state.  EU states take precedence.
Irish	IE	CONCAT	2	Second EU country alphabetically based on country code
Italian	IT	Codice fiscale	3	Third EU country alphabetically based on country code

In a post-Brexit world, the identifier to be used would change because the UK would switch from being an EU state to a non-EU state. Whilst my nationalities haven’t changed, the status of the UK has.  Reapplying the logic to compute the appropriate identifier to use would produce the following:

Post-Brexit implications
If there are any EU nationalities, they take precedence over non-EU nationalities. The first EU nationality of the country code when sorted alphabetically is used in that scenario. In this case it would be GB.  Looking at the table in RTS 22 annex II then shows that the UK requires a national insurance number, as its primary identifier.

Nationality	Country code (ISO 3166)	Identifier to use per annex II RTS 22	Priority (post Brexit)	Basis
British	GB	National Insurance number	3	Not an EU state.  EU states take precedence.
Guernsey	GY	Passport	4	Not an EU state.  EU states take precedence.
Irish	IE	CONCAT	1	First EU country alphabetically based on country code
Italian	IT	Codice fiscale	2	Second EU country alphabetically based on country code

The table above shows that this is not going to be a simple process. It however, will go beyond just clients.

Beyond clients

Within the MiFID II transaction report there are a number of fields which may require an individual to be identified. Not all of these will be clients.

Field no.	Field name	Type of individual
7	Buyer identification code	Client
12	Buyer decision maker code	Client or representative
16	Seller identification code	Client
21	Seller decision maker code	Client or representative
57	Investment decision within firm	Trader
59	Execution within firm	Trader

Where there is some sort of power of representation in place, that party will also need to be allocated an identifier using the same process if they are to place trades on behalf of the account. Traders within the firm are also caught.

Identifying businesses under MiFID II

A much simpler identifier is in place for businesses. MiFID II requires all parties operating a business to be identified with a Legal Entity Identifier (“LEI” code). I say “operating a business” and not “companies” because any party eligible for an LEI under the LEI allocation rules must be identified with an LEI. Under these rules an individual operating a business as a sole trade or as a local is eligible for an LEI.

“The regulations require firms to have an LEI in their possession before entering into a trade with a client or counterparty or on behalf of their client.”

No LEI no trade

This gives rise to the ‘no LEI, no trade’ rule. At present, the regulations require firms to have an LEI in their possession before entering into a trade with a client or counterparty or on behalf of their client. This can be extended to the decision maker fields for representatives under a mandate or power of attorney.

A legal firm operating for an account will need to register for an LEI. Registration can be made on behalf of a third party or client where they give authority and the information needed to do so. Costs are currently around £100 per LEI and £55 for renewals – required after two years depending on the number of LEIs being registered.

LEI status

There are several statuses that an LEI can have. Reporting firms must use an “active” LEI in the executing entity field which are: “Issued”, “Pending transfer” or “Pending archival”. For clients and representatives, they must have registered for an LEI which can be one of the following statuses: “Issued”, “Lapsed”, “Pending transfer” or “Pending archival”.

Branches

Branches should be identified with the LEI of their head office, certainly until such time that the proposed branch level LEIs are issued.

What should firms be doing now?

Firstly, firms need to test their existing client and counterparty static data (including representatives) to check they have correctly captured LEIs that are already in issue. Then they need to conduct a reach-out exercise encouraging them to obtain an LEI. If you have a lot of clients, you may not want to shoulder the cost of registering an LEI for them. This however could be deemed to be an inducement and may be considered contrary to the inducement rules set out in MiFID II so firms should tread carefully.

For individuals, a reach-out exercise is needed to collate nationalities and associated identifiers, then the appropriate identifier needs to be determined.

Mapping client and counterparty accounts to the LEI dataset is a complex activity. At Kaizen, we have been working on LEIs for more than two years, developing solutions that address the challenges associated with mapping identifiers for both individuals and businesses. The LEI dataset itself is not without its problems as it uses multiple alphabets and contains duplicate records and entities with common legal names within its dataset. Building this assessment capability in-house will be an expensive and time-consuming exercise. In addition, this will need to be carried out on a recurring basis as new LEIs are being registered daily.

As with all regulations, the philosophical and the practical collide, leaving firms with the challenge of accommodating the two.

• Our reference data testing (part of our ReportShield™ quality assurance service) executes a range of checks to ensure that client and counterparty reference data is accurate and complete.