Embed Size (px)
Citation preview
BBA
EMIR Counterparty Classification Project Final Report, 15th March 2013
Version Comment Author
1.0, 15/03/2013 Final Report from Counterparty Classification Project, March 2013
Barry Smith
1
Table of Contents 1. Background 2. Objectives, Scope and Requirements
2.1. In scope 2.2. Out of scope 2.3. Constraints 2.4. Key requirements for an effective solution
3. Project Approach and Deliverables 3.1. Industry code mapping 3.2. Report
4. Approaches to Counterparty Classification 4.1. Protocol-driven approach 4.2. Data-driven approach 4.3. Hybrid Approach 4.4. Legal Certainty
5. Counterparty Classification Methodology 5.1. Types of industry code 5.2. Versioning of industry coding schemes 5.3. Comparison between NACE, SIC and NAICS. 5.4. Principles used in defining mappings 5.5. Mapping rationale
5.5.1. Third country entities 5.6. Principles for applying mappings
5.6.1. Using legal entity level data 5.6.2. Mapping where more than one coding scheme is available 5.6.3. Mapping where more than one industry code is available 5.6.4. Certainty
5.7. Overview of the mappings 5.7.1. NACE/SIC 5.7.2. NAICS
6. Implementation Scenarios and Action Plan 6.1. Data Sharing 6.2. Publication 6.3. Implementation scenarios
6.3.1. Tactical implementation 6.3.2. Strategic implementation options
6.4. Action plan 7. Disclaimer 8. Appendix 1: Draft client communication letter 9. Appendix 2: Workbook User Guide
9.1. NACE/SIC mapping sheet (SIC-07) 9.2. NAICS mapping worksheet (NAICS-12) 9.3. NACE structure worksheet (NACE-R2 Structure)
2
1. Background The European Market Infrastructure Regulation (EMIR)1 entered into force on 16 August 2012. The Regulation introduces a reporting obligation for OTC derivatives, a clearing obligation for eligible OTC derivatives, risk mitigation measures aimed at reducing counterparty credit roperational risk for non-cleared OTC derivatives, common rules for central counterparties (CCPs) and for trade repositories (TRs), and rules on the establishment of interoperability between CCPs.
isk and
The Commission Delegated Regulations2 were published in the Official Journal on 23 February 2013 and enter into force on 15 March 2013. The implementing technical standards were published in the official journal dated 21 December 2012 .
EMIR distinguishes between financial counterparties (FCs) and non-financial counterparties (NFCs). OTC derivative counterparties must classify their counterparts according to the EMIR definition, and this classification bears on the requirements for timely confirmation and risk mitigation of non-cleared trades, trade reporting, and eventually the clearing via an authorised CCP of classes of derivatives for which the Commission has made a clearing determination. Firms classified as NFCs are obliged to aggregate their positions and test them against the clearing threshold to determine whether they are subject to the clearing obligation: such firms are known as NFC+. An NFC+ firm is under no obligation to notify its counterparties, and NFCs in general are under no obligation to ensure that all counterparties classify them in the same way.
The ISDA Protocol initiative attempts to solve the second problem in a legally certain fashion, but the prior question, whether a firm is to be classified as an NFC in the first place is not addressed.
The timely confirmation rules are in effect from March 15th. Moreover, compliance with the remaining requirements that depend upon the requirements will require many operational changes and also re-papering of legal relationships to support compliance. Firms will need time to make these changes, and so counterparty classification becomes a matter of urgency. The first problem, a one-time exercise, is to classify all existing counterparties. The second is to make arrangements so that new counterparties are properly classified as part of the normal on-boarding process.
One approach to the primary FC/NFC classification that has been suggested is to make use of industry classification codes - which firms already apply to their counterparties - to make an initial data-driven classification. This could in principle accelerate the client interaction that leads to an agreed classification. Clearly there is potential for streamlining this process by agreeing a common approach aimed at consistent client interactions and minimising disputes and redundant communication.
In order for firms to apply such an approach they will need to agree:
which of the industry classification codes used for client on-boarding can be used for classification purposes;
how those codes should be mapped to the EMIR definitions of FCs and NFCs;
whether there are any codes that will be difficult to map, and if so, how these “outlier” cases should be addressed;
what should be done in the event that there are multiple classifications for a single entity;
how third country institutions should be addressed;
1 The Regulation (EU) No 648/2012 of the European Parliament and of the Council of 4 July 2012 on OTC
derivatives, central counterparties and trade repositories. 2 EU No 148/2013 to 153/2013 of 19 December 2012 supplementing EMIR
3
how clients should be informed about the classification that has been assigned to them and on what basis.
2. Objectives, Scope and Requirements The EMIR counterparty classification project is intended to establish the feasibility of and enable an industry-code driven approach to classifying counterparties as FC or NFC. It does not attempt to solve the NFC+ classification problem, which is primarily an NFC obligation and which is being addressed via the ISDA Protocol route.
The primary project objective is to identify industry classification codes used by firms and map them according to the definitions of FC and NFC,3 and to do so in sufficient time to allow firms to implement the classification promptly from 15th March 2013.
Given the very short timeline, the solution will need to be a pragmatic one. It should be developed over time into a robust strategic solution: a secondary objective of the project is to investigate ways in which this could be done.
The project was commissioned under the auspices of the BBA’s Data Management User Panel and endorsed by 10 member firms, in order to create a common deliverable on behalf of the industry. The participating firms have immediate access to the deliverables, but the intention is to provide an industry-wide solution. The deliverables will be made publicly available, and no intellectual property resulting from the project will be retained by the BBA, the firms or their agents.
The project is resourced by representatives of the member firms and a small team from the risk management consultancy Avantage Reply.
2.1. In scope
Business: All counterparties subject to EMIR.
Regulations: EMIR and the associated RTS.
Validation: Apart from participating firms, approach to be validated with the FSA, and with ESMA and BaFin if possible.
Industry classification schemes: NACE, UK SIC and NAICS.
Analysis: Likely implementation scenarios and industry reactions; rules for “outliers”; socialisation of the classification approach across firms; approach for client communication.
2.2. Out of scope
Extraterritoriality.
Third country institutions.
Other regulations.
Formal regulatory endorsement.
Other coding schemes apart from NACE, NAICS, SIC.
NFC+ classification and the clearing threshold.
Independent legal verification.
3 EMIR, Article 2
4
Other longer term issues.
2.3. Constraints
The project is primarily a short-term tactical solution, constrained by regulatory timelines, though it may evolve into a longer-term solution;
Given the timelines, the output cannot constitute legal advice, and nor can it result by itself in legal certainty;
Formal regulatory endorsement will not be obtainable;
Regulatory uncertainty, since the EMIR Level 2 legislation is incomplete and no Level 3 guidance is available;
Uncertainty about classification of third country entities and the effect of extraterritorial provisions in EMIR and in overlapping legislation originating in other jurisdictions, such as the US Dodd-Frank Act (DFA) Title VII.
2.4. Key requirements for an effective solution
The solution must allow firms to begin undertaking classification activities by the effective date of the RTS.
The solution must be based on the regulatory FC/NFC definitions in EMIR4.
The solution should be cost effective.
The solution should promote consistency of approach and client communications, and also of classification outcome;
The solution should take account of the requirement for client relationships to remain confidential.
Any tactical solution that can be implemented immediately will meet some of these requirements only to a limited extent. For example, consistency of classification outcome will require a more strategic approach to data sharing.
3. Project Approach and Deliverables There are two agreed project deliverables: a set of industry code-based mappings in the form of an Excel workbook and a report that addresses the feasibility of the approach, provides an overview, rationale and user guide for the mappings and addresses both short-term and strategic implementation scenarios. A draft client communications letter is included with the report as Appendix 1.
The approach to constructing the deliverables includes (i) desk-based analysis of the candidate industry classification schemes and their fitness for classifying counterparties under EMIR, (ii) interviews and group conference calls to discuss mappings, rules for using mappings, and exceptions or “outlier” industry codes, (iii) meetings with key regulators; (iv) delivery of drafts of each deliverable for comment and eventual signoff.
The purpose of the regulator meetings is not to secure formal endorsement but to ensure that regulators are broadly comfortable with our proposed approach during the transition process. We will be expected to move to a more robust strategic solution over time, and therefore this report sets 4 EMIR Article 2(8) and (9). See the section on Mapping Rationale below under Counterparty Classification
Methodology
5
out some options for achieving that.
3.1. Industry code mapping
The industry classification code mappings from NACE, NAICS and UK SIC to the EMIR counterparty classification are provided in the form of an Excel workbook. Two worksheets contain the mappings that are the main project output: these are the SIC-07 and NAICS-12 sheets at the front of the workbook. The workbook also contains structural and descriptive information derived from publicly available NACE, NAICS and UK SIC sources5. For more information on the workbook, see the user guide6.
3.2. Report
The final project report, the present document, includes
background, objectives and scope of the project;
requirements that should be met by the proposed solution;
a rationale for the chosen industry-code based approach to meeting the requirements;
an overview of the proposed methodology for building, maintaining and making use of the mapping tables, including the classification rules;
scenarios showing how the approach can be applied, firstly, in the short-term as a tactical route to timely compliance with EMIR and, secondly, as a longer-term strategic solution: for the latter, various options are presented and assessed;
a draft client communication pro forma letter that can be used and adapted by member firms;
an action plan for implementing the short-term solution;
a short user guide to the first deliverable, the Excel workbook.
4. Approaches to Counterparty Classification In order to classify counterparties under EMIR reliably and consistently there are three main alternatives:
a protocol-driven approach, which relies on client outreach to arrive at agreement between the parties and to reflect this in standard legal documentation;
a data-driven approach, which relies on counterparty reference data captured during the customer on-boarding process; and
a hybrid approach, combining aspects of the other two.
4.1. Protocol-driven approach
The protocol-driven approach was used in the US for implementing aspects of Title VII of the Dodd-Frank Act (DFA), based on the ISDA DFA Protocol. This approach has the clear advantage that, correctly executed, it results in legal certainty and clear responsibilities under the EMIR legislation.
In practice it suffers from the disadvantage that the take-up rate, especially among non-financial 5 Some of this is subject to copyright, but appears to be reproducible with acknowledgement 6 The user guide is included as Appendix 2
6
counterparties and among smaller counterparties generally, tends to be low. The process is likely to be correspondingly protracted. In the case of EMIR, even though the timelines for implementing the clearing and risk management requirements are quite long, given the fact that timely confirmation rules are already in effect from 15 March 2013 onwards, this slow take-up rate has very significant disadvantages.
4.2. Data-driven approach
A data-driven approach, making use of counterparty reference data already captured by institutions offers an attractive alternative. The greatest potential lies in industry classification data. Although there are many different classification schemes, in practice they can usually be mapped to one or more of the standard schemes that are used for financial and regulatory reporting in the EU and North America. All institutions must capture industry classification data in order to manage concentration risks and meet various reporting obligations.
The key advantage is that a data-driven approach has the potential to accelerate counterparty classification and reduce the risks of non-compliance. Industry code to EMIR classification mappings can be implemented initially as a pragmatic step to classify rapidly the bulk of existing counterparties. Mappings can be improved over time on the basis of experience with mis-classifications. Finally, it is possible to integrate this approach into the main counterparty on-boarding process to ensure that, in future, all new counterparties are classified promptly.
The drawbacks of this approach are as follows.
By itself, it cannot result in legal certainty and full agreement with the counterparty. This is the key issue with data-driven approaches and is discussed below under Legal Certainty.
It is vulnerable to data quality issues with institutions’ own counterparty reference data (although this is a relatively minor objection, since these issues must in any case be addressed by firms).
Any standardised data-driven approach must rely on a limited set of industry coding schemes, essentially, SIC 2007, NACE 2 and NAICS 2012, since to maintain more than this core set of mappings would be unduly burdensome and error-prone, and would lead to inconsistencies among the mappings. Where institutions use other schemes, such as earlier versions of the three standard schemes, or proprietary or internally-developed coding schemes, ambiguities can result from bridging from these codes to the coding scheme used for EMIR classification.
It is therefore clear that, though it has clear advantages, a purely data-driven approach will be insufficient by itself.
4.3. Hybrid Approach
The US experience of slow take-up of the ISDA DFA Protocol by counterparties has convinced participating BBA member firms of the need for a more proactive approach. A data-driven approach allows us to be proactive. This is particularly important during the transition phase where institutions have a short period of time to classify many counterparties, but even after transition it can still have benefits by making the classification process more timely and efficient in the majority of cases.
Since the result of applying the data-driven approach will always fall short of legal certainty, the approach that is proposed is a hybrid one in which the data-driven classification is the first step. The step results in a counterparty classification in which either (i) we have a very high degree of confidence or (ii) we are uncertain - but in that case we almost always know why we are uncertain
7
and what kind of issues (e.g. directive de minimis exemptions) are at stake.
After that first step, the next step would be for firms to communicate the classification to the counterparty, asking them to respond if they do not agree, and thereby placing the onus on counterparties to respond quickly where the classification could be wrong7.
Following this, the normal on-boarding or documentation change processes can be followed to ensure that in the end the legal agreements are fully aligned with the counterparty’s status. For example, where bilateral margining obligations may apply, it will be necessary to ensure that the proper documentation will be in place to facilitate this.
The drawbacks of the purely data-driven approach mentioned above will be addressed by the resulting interactions with counterparties. But by starting with a proactive data-driven classification the process is likely to be more efficient, leading to accelerated compliance timelines.
Firms participating in the project agreed that this hybrid approach is the preferred solution.
4.4. Legal Certainty
Any classification scheme based purely on industry classifications cannot provide full legal certainty: this is the reason for preferring the hybrid approach.
The fundamental reason for this is that the basis for allocating industry codes lies in the nature of the various economic activities carried out by a firm - there may be several such activities and not all of them are necessarily captured in the form of industry codes. On the other hand, the EMIR classification8 is strictly a binary matter of fact, based on regulatory status under a fixed set of EU directives9.
Some institutions allocate multiple industry codes to reflect the diversity of activities undertaken by a given firm, but there will typically be one code to reflect the “principal” activity, and even when more than one is provided, the codes may not capture all types of economic activity undertaken by the firm.
Legal and regulatory status on the one hand and economic activity on the other are not the same thing. In principle, it is possible for a firm to be (for example) a “credit institution” when lending is not its main economic activity. In practice, though, it may be so uncommon that it is never, or almost never, encountered. To establish whether this kind of statistical confidence applies, it is necessary to put the mapping into practice with real counterparties and counterparty data and keep track of the frequency with which misclassifications are encountered.
Most of the EU directives in question provide for exemptions. For example, MiFID defines the concept of an “investment firm” but it provides a number of exemptions applying to certain types of commodity trading firms and own-account traders. AIFMD in principle defines Venture Capital Funds as Alternative Investment Firms (AIFs), since they are Collective Investment Undertakings but they are not UCITS. However, AIFMD also includes de minimis exemptions for VC funds, and to make matters even more complex, allows potentially exempt VC funds to opt in to AIFMD to gain the benefit of EU-wide passporting (marketing rights). No industry code by itself can allow us to deduce with certainty whether a given VC fund will be an AIF or not.
Third-country counterparties throw up another type of problem. For purposes of the clearing obligation we have to establish whether a firm would be an FC or NFC if it were, counterfactually, established in the Union. This adds to uncertainty when classifying third-country entities.
7 See Appendix 1 for a draft client communication letter that could be used or adapted by members 8 At least in the case of EU entities. 9 See the section below on Mapping Rationale for a detailed explanation of the relevant criteria
8
In practice, these uncertainties are largely confined to a subset of industry codes relating to financial services including especially funds and investment firms. Industry codes outside the financial services sector can, in almost every case, be reliably mapped as EMIR NFCs. The chance that, say, a manufacturer of agricultural machinery will be an FC is virtually nil10.
While some industry codes in the financial sevices sector lead to uncertainty, many of them can also be mapped reliably. We can be reasonably certain that a commercial bank or a life insurer will be a financial counterparty. It turns out that in only a small number of cases - less than 10% of industry codes - do we know that we are uncertain in principle. For this reason, we use a certainty ranking for each individual industry code mapping. This allows us to distinguish the vast majority of cases, where the level of certainty is very high, from the cases where we know that some form of case-by-case checking is definitely required.
Where the level of certainty is very high, this still does not equate to complete a priori legal certainty. It can nevertheless result in counterparty classifications with a statistical probability so close to 100% that we do not in fact encounter any misclassifications.
On the other hand, where we have mappings that are known to be uncertain, we can focus our case-by-case attention on achieving legal certainty through a focussed dialogue with the counterparty. By encoding the reasons for the mapping in the mapping itself, we can know in advance the issues that are at stake when using a given mapping that is known to be uncertain.
5. Counterparty Classification Methodology This section outlines the core of the proposed classification approach. It:
identifies the specific industry coding schemes that have been selected;
outlines the principles that have been applied in constructing the mapping from industry codes to the EMIR counterparty classification;
provides an overview of the resulting mappings sector-by-sector, and identifies the mapping issues and outliers;
outlines the classification algorithm - that is, the rules describing how the mapping data should be used in practice to classify counterparties.
5.1. Types of industry code
There are in essence three main types of industry classification schemes used in the financial services industry.
1. Internal classification schemes developed by financial institutions themselves.
2. Proprietary schemes developed usually by data service providers, often with a view to classifying issuers of instruments for which they typically also hold reference data and market data. These include, for example:
The Global Industry Classification Standard (GICS), developed by Morgan Stanley Capital International (MSCI) and S&P.
Industry Classification Benchmark (ICB), owned by FTSE.
Thomson Reuters Business Classification (TRBC).
10 Non-financial groups that also carry out trading or lending activities will not generally lead to exceptions, since they
will usually have regulated subsidiaries, and it is the subsidiary legal entities that we will classify: see the section on Principles for applying mappings below.
9
Bloomberg Industry Classification Scheme (BICS) currently being re-developed.
3. National and Supranational schemes developed and typically mandated for particular firm reporting and/or statistical reporting purposes. These include, for example:
International Standard Industrial Classification (ISIC) developed by the UN and used for aggregating and reporting economic data internationally.
The NACE scheme used by the EU - which is mandated for COREP reporting by firms as well as for producing economic statistics.
The Standard Industrial Classification, used now mainly by the UK and known as UK SIC11.
North American Industry Classification System (NAICS) developed jointly by the US, Canada and Mexico.
Clearly the first two types of coding scheme, internal and proprietary, are widely used in the industry. But they suffer from three flaws as a foundation for an industry-wide standard aiming at consistency of classification approach across institutions. Firstly, there are many such schemes and it would be difficult to support enough of them to gain buy-in across the industry from market participants and regulators. Second, if we did support a large enough subset of them, it would cost a significant effort and would compromise consistency and overall quality. Third, it would be difficult to require counterparties, especially non-financials, to agree on classifications based on proprietary or internally developed coding schemes to which they might not have access, and where different institutions would be applying different, possibly inconsistent, mappings.
Based on these considerations, it was decided to focus on developing mappings for NACE, NAICS and UK SIC. Member firms participating in the study indicated that they were using at least one of these coding schemes either as their main industry classification, as a secondary classification, or could derive the classification from their internal coding scheme.
5.2. Versioning of industry coding schemes
All three of the schemes are updated from time to time. All three attempt to remain aligned with the international ISIC scheme. ISIC is a high level coding scheme based on four-digit codes. NAICS and SIC are more granular. The fact that NACE, NAICS and SIC are all updated periodically in alignment with ISIC helps to promote a degree of consistency across the industry coding schemes, which can be used to support an assessment of mapping consistency.
The current versions of the schemes have been used in each case for mapping purposes. Concordances from earlier versions of SIC, NAICS or NACE that may be in use at particular member firms are available, although in some cases they are far from being straightforward one-to-one mappings. The versions that have been used for direct mapping to EMIR classification are as follows:
NACE release 2. See the release 2 manual at http://epp.eurostat.ec.europa.eu/cache/ITY_OFFPUB/KS-RA-07-015/EN/KS-RA-07-015-EN.PDF.
NAICS 2012. See http://www.census.gov/eos/www/naics/, which contains downloadable Excel versions of NAICS, and the manual: http://www.census.gov/eos/www/naics/2012NAICS/2012_Definition_File.pdf
11 SIC was previously used in the US, but was replaced by NAICS in 1997. Other SIC-based classification schemes are
still in use elsewhere e.g. Australia and New Zealand, where the ANZSIC 2006 is broadly in line with UK SIC 2007
10
UK SIC 2007. See http://www.ons.gov.uk/ons/guide-method/classifications/current-standard-classifications/standard-industrial-classification/index.html, which contains downloadable Excel sheets and the manual in PDF format.
5.3. Comparison between NACE, SIC and NAICS.
NACE release 2 is the least granular of the three schemes, being based like ISIC on four-digit codes.
UK SIC 2007 is based on five digit codes, and is thus more granular, but it is built upon NACE and the first four digits are exactly consistent in the coding itself and in the meaning of the coding across the two schemes. The same conceptual framework, terminology and descriptions are applied as in NACE. As a corollary, a SIC code can be rolled up without ambiguity to NACE level, e.g. for COREP reporting purposes. The additional fifth digit in SIC, known as a subcode or subclass, sometimes contains additional information. In many cases, SIC contains no more detail than NACE, and in this case the subcode is always equal to zero. Where SIC breaks out a NACE code into two or more SIC codes with more granular definitions, the subcodes always lie between 1 and 9. In that case, the four-digit code corresponding exactly to the matching NACE code represents a hierarchical roll-up of the underlying SIC codes.
NAICS 2012 is based on six digit codes and in general (though not in every single case) it is thus more granular than either NACE or SIC. Although the underlying ISIC framework provides for a certain degree of correspondence between NAICS and the NACE/SIC schemes, they differ at the detailed level to a considerable extent.
5.4. Principles used in defining mappings
This section outlines the principles that have been used to develop the industry code to EMIR classification mapping tables. To ensure consistency these should be followed in future when maintaining the mappings.
The principles address two attributes that can be derived from any given industry code: (i) the proposed classification as FC or NFC; and (ii) the certainty of the proposed classification, where certainty is set either to 1 or 2.
A certainty of 1 does not mean that the mapping is in the full sense 100% certain, but that there is no known reason why the proposed classification might be wrong, and moreover that no misclassifications have in fact been recorded so far: thus, empirically, we can say the probability of a misclassification appears to be close to zero. A certainty of 2 means that it is known that misclassifications could in principle occur (and usually why they might occur) and/or that exceptions have in fact been recorded.
Where the certainty is set to 2, firms using the mapping approach should check on a case-by-case basis to try to resolve the uncertainty. There are several reasons why a certainty level of ‘2’ may have been assigned:
the relevant EU directives themselves contain exemption arrangements or give optionality to firms (e.g. MiFID and AIFMD);
firms are not yet in fact regulated under the relevant directive, since the relevant authorisation process is not yet implemented or is incomplete during a transition period (e.g. AIFs);
a given industry code applies both to firms that are very likely to be regulated under a given directive, and also to firms that are not likely to be regulated under the relevant directives. For example, a single industry code that applies to unit trusts might refer either to a UCITS
11
fund, implying FC, or to an AIF, which during transition implies an NFC.
The principles followed are:
1. The most probable classification for any given industry code, as implying a non-financial or a financial counterparty, is assigned in each case.
In practice, this turns out to mean that all industry codes for firms outside the financial services sector map to NFC. Almost all of them map to NFC with certainty 1 (e.g. food retailers); a very few of them map to NFC with certainty 2 (e.g. gas trading firms).
Many industry codes inside the financial services sector imply a mapping to FC - but not all of them. For example, industry codes for firms whose principal business is providing insurance ancillary services are mapped to NFC. Consider a firm whose principal activity is to provide insurance claims adjustment services. Such a firm is unlikely to be an insurance undertaking, even if it is the captive subsidiary of such an undertaking; if it were, it would have been classified as an insurer rather than a claims adjuster.
2. If there are known exemptions or optionality in the relevant directive(s) the certainty level is set to 2.
3. If there are recorded cases of misclassification, the certainty level should be set to 2.
5.5. Mapping rationale
The EMIR FC and NFC definitions are contained in Article 2 of the Regulation. Article 2(8) defines an FC as:
an investment firm authorised in accordance with Directive 2004/39/EC12
a credit institution authorised in accordance with Directive 2006/48/EC13
an insurance undertaking authorised in accordance with Directive 73/239/EEC14
an assurance undertaking authorised in accordance with Directive 2002/83/EC15
a reinsurance undertaking authorised in accordance with Directive 2005/68/EC16
a UCITS and, where relevant, its management company, authorised in accordance with Directive 2009/65/EC17
an institution for occupational retirement provision within the meaning of Article 6(a) of Directive 2003/41/EC18
an alternative investment fund managed by AIFMs authorised or registered in accordance with Directive 2011/61/EU 919
If a firm is authorised under any one or more of these EU directives, then it is an EMIR Financial Counterparty. If it is an entity established in the EU that is neither a Financial Counterparty so defined, nor a CCP as defined in Article 2(1), then it is a Non-Financial Counterparty.
For entities established in the EU, these definitions are relatively clear. Uncertainties arise for a 12 MiFID 13 CRD 14 General Insurance Directive 15 Life Insurance Directive 16 Reinsurance Directive 17 UCITS Directive 18 IORP Directive 19 AIFM Directive
12
number of reasons, including:
Most of the directives itemised in Article 2(8) contain exemptions: for example, some investment firms are MiFID-exempt and CRD-exempt, and are thus NFCs for EMIR purposes.
One of the directives, AIFMD, is effective but the authorisation process is not yet under way. Transitionally, firms that will be AIFs are not technically FCs but will become so when they are authorised.
Following the definition of FC given above, there turn out to be nine possible reasons for associating a given industry code with FC status. There are eight directives mentioned, seven of them identifying one regulatory status and the eighth two (UCITS and UCITS Manager).
In carrying out the mapping, the definition of each industry code was examined to see whether it was possible, likely or very likely that a firm with its main economic activity as defined would be regulated according to one or more of these regimes. Where it seemed unlikely that any of the regimes would apply, the code was mapped to NFC. If it seemed likely that one or more of the regimes would apply, then the code was mapped to FC. These likelihoods at the level of the individual regulatory regimes were combined into a single certainty flag. For example, if one or two of the regimes would possibly apply but neither were likely, then the mapping certainty level was set to 220.
5.5.1. Third country entities
For entities established outside the EU, it might appear from EMIR Article 2 that classification is not necessary. Unfortunately this is not the case. Article 4 establishes that clearing obligations will apply to transactions between an EU FC or NFC+ entity and an “entity established in a third country that would be subject to the clearing obligation if it were established in the Union”, and even between two third country entities that would be FCs or NFC+s where “the contract has a direct, substantial and foreseeable effect within the Union or where such an obligation is necessary or appropriate to prevent the evasion of any [EMIR] provisions”21.
Similar language appears in Article 11 in relation to risk mitigation obligations for non-cleared OTC derivatives involving third country entities22.
These requirements are not particularly clear, which is why they are formally out of scope of this initiative. It is likely that further guidance from the regulators will eventually be forthcoming. In the meantime, the working assumption is that for transactions with third country entities, when we come to classify them we will be able to apply a broadly similar approach.
5.6. Principles for applying mappings
This section sets out the key rules to use when applying the mappings in order to classify counterparty status. The overall classification algorithm consists of the mapping tables plus the rules given here for using the tables.
5.6.1. Using legal entity level data
The data-driven part of the classification process must be carried out using industry codes that apply to the actual legal counterparty. In general, using codes applying to parent companies will produce results that are likely not to be compliant with the EMIR legislation. For example, a food retailer 20 See under Certainty below 21 EMIR Article 4.1 (iv) and (v) 22 EMIR Article 11.12
13
may establish a banking subsidiary. The banking subsidiary will have an industry code that leads to an FC classification, which is correct since the subsidiary will be a CRD credit institution. Using the parent company industry code will lead to an incorrect NFC classification.
Particularly in the case of fund counterparties, it is common for the fund manager to execute umbrella legal agreements on behalf of many underlying funds. Furthermore, when actual orders to trade are placed and executed, this will often be done by the manager and booked by the executing firm as if the manager were the true counterparty. Since most funds are likely to be FCs and so are most managers this will often produce the right result. But best practice will be to ensure a sub-account identifying the true derivative counterparty is in place, and classify using the correct codes: this will produce more accurate initial classifications.
5.6.2. Mapping where more than one coding scheme is available
It may be that in a given institution, multiple industry coding schemes are used in parallel, such that a given legal entity may have codes for more than one of the standard coding schemes, e.g. NAICS and SIC. The following rules should be followed.
1. If NACE and SIC codes are both available, use the SIC code and not the NACE code. (This is because the SIC code has an exact mapping to NACE but contains more information leading to more certain classifications. Using a NACE code together with a SIC can actually reduce the level of certainty.)
2. If NAICS and SIC are both available, use both, and classify as FC if either one (or both) implies an FC; otherwise, classify as NFC.
3. If NACE and NAICS are both available, use both, and classify as FC if either one (or both) implies an FC; otherwise, classify as NFC
4. If all three are available, ignore the NACE.
5.6.3. Mapping where more than one industry code is available
If a given legal entity has multiple industry codes from any given coding scheme, classify it using them all and if any one (or more) lead to an FC classification, then classify as an FC.
5.6.4. Certainty
Each single mapping entry (i.e. a mapping from a single industry code to NFC or FC status for that code) has a certainty level of either 1 or 2 attached to it. A certainty level of 1 means that there is no known reason to doubt the mapping23.
Where the certainty level is 2 rather than 1, it is necessary to look at the mapping rationale and the comments columns in the relevant mapping worksheet to understand why. The certainty level is mainly based on the rationale columns, where the reason for the proposed classification is captured in the form of flags indicating that the firm is likely to be subject to one or more of the regulatory regimes defining FC status.
In these uncertain cases, it may be wise to tailor the counterparty communication to deal with the uncertainty - perhaps to initiate a telephone call in advance of sending out a classification notice.
5.7. Overview of the mappings
This section provides a walkthrough of the NACE/SIC and NAICS mappings, and discusses the uncertain classifications, or “outliers”. 23 As discussed above, this still falls short of full legal certainty
14
5.7.1. NACE/SIC
Under the NACE and SIC schemes, all codes are mapped to NFC except the codes in section K, Finance and Insurance Activities, which begin with the digits 64 through to 68. Almost all of the codes outside this range are assessed as having NFC status with certainty level 124.
In section K, most of the entries are assigned FC, or in some cases NFC with certainty 1. The main areas of uncertainty lie within the NACE/SIC classes 64.30, Trusts, Funds & Similar Financial Entities; 64.99, Other Financial Services Activities including own-account dealing and factoring.
The following paragraphs discuss the main outliers in more detail.
Gas and electricity trading Two NACE/SIC codes, 3514/0 and 3523/0, relate to electricity and gas trading. These entities are probably not FCs but could be. The codes mainly apply to sales to end-users through the transmission networks; but they also apply to the activities of electric/gas power brokers/agents and the operation of capacity exchanges. If these activities extended to OTC derivative contracts referencing electric power or gas, then the trading firm could be subject to MiFID. They are therefore assigned as NFC with certainty level 2.
Holding companies NACE 64.20 (holding companies) and especially SIC 6420/5 (financial services holding companies) - these are defined as companies whose principal activity is owning the equity of group companies, and not managing them or extending credit. These companies are mapped to EMIR NFC. They are unlikely to be direct counterparties in any case. If a banking group’s parent has a banking license it should have been coded as a bank rather than a holding company, given the formal definition of ‘holding company’.
VC funds SIC 6430/3 refers to VC funds. VC funds satisfying de minimis criteria qualify for exemption from AIFMD but on the other hand can opt in to obtain EU-wide marketing rights. They are NFC in any case during transition, since they are not yet authorised. Once the bulk of AIFs are authorised, the mapping for AIFs should probably be changed to FC, but in the case of VC funds in particular this mapping will be uncertain. So for both reasons this mapping is assigned they are classified with certainty level 2.
Securitisation vehicles such as conduits. The entities in question are by definition not credit institutions (although their sponsors are likely to be credit institutions). Securitisation entities are not subject to regulation under most of the relevant regulatory regimes, but could be subject to MiFID in that they engage in “placing of financial instruments without a firm commitment basis”. The correct division code under NACE and SIC seems to be 64.9 - financial activities other than by monetary, pension or insurance institutions. The NACE class code, 64.99, will be mapped to FC since it also includes many types of entity that will be subject to MiFID, such as dealing, brokerage and investment other than by CIUs. SIC is more granular and includes 6499/9 which applies to “securitisation activities” but also to “writing of swaps, options and other hedging arrangements”, underwriters and settlement companies. Such a firm is quite likely to be regulated as an investment firm under MiFID, and therefore this code is mapped to FC. But this mapping will only be correct for securitisation vehicles if they are subject to MiFID, so the classification is marked as uncertain.
Financial markets SIC /NACE 66.11 - administration of financial markets - is an uncertain mapping. Under MiFID, an operator of an MTF may be an “investment firm” or a “market operator” that is not an investment firm. Operators of regulated markets are usually not MiFID investment firms. This code is currently mapped to FC with certainty level 2, but an
24 The are just two exceptions, assessed as probably NFC but with certainty level 2 - see the entry below on Gas and
Electricity Trading.
15
NFC mapping could also be considered.
Funds Trading with funds is frequently carried out under umbrella agreements, normally with one fund management firm responsible for many funds. However, in these cases the legal counterparty to actual derivative transactions will normally be the fund itself under the umbrella documentation, and not the manager that administers the documentation and places orders. For the best results, especially in the case of SIC, which is more granular in classifying funds than NACE, it is important to use the industry code associated with the actual fund that is the true counterparty, and not the fund manager. But the fund manager is likely to be a MiFID IF and/or UCITS Manager in any case, so the result will often be the same.
Ancillary services SIC/NACE 66.19 includes transaction processing, settlement activities, investment and mortgage advisory, trustee, fiduciary & custody services. These are mainly ancillary services under MiFID, and do not in themselves imply that a firm is an investment firm. However, a firm providing these services as its main activity, might also provide MiFID investment services or even act as a CRD credit institution as a secondary activity. Hence we assigned NFC with certainty 2.
Insurance ancillary services We have classified activities ancillary to insurance/ assurance/ reinsurance e.g. claims settlement, claims adjusting, insurance broking/intermediation (SIC/NACE 66.21, 22 and 29) as NFCs since if this is the primary activity of the entity it is highly unlikely to be an Insurance/Assurance/Reinsurance Undertaking under the EU directives. It may be a captive vehicle or a third-party specialist service firm, but if it were underwriting insurance policies it would surely be classified with non-ancillary insurance industry codes from the SIC/NACE division 65 rather than division 66.
Own account dealing Various categories of own-account dealing are subject to MiFID exemptions. Hence industry codes for own-account dealing are classified as FC with a certainty level of 2.
5.7.2. NAICS
The NAICS codes beginning 52 represent Finance and Insurance. In the same way as the equivalent section K in NACE/SIC, these codes contain many industry codes that are classified as FC with certainty 1 and some NFCs with certainty 1. All of the mappings classified as uncertain are in this section. All the other NAICS codes are classified as NFC with certainty 1.
The following paragraphs highlight the main outliers.
Credit Unions are marked as uncertain as they currently have exemption from the CRD regime in some jurisdictions.
Financial Transactions Processing, Reserve and Clearinghouse Activities are marked as uncertain because firms engaged in some of these activities could involve credit granting. They have been classified as FC but NFC might be more appropriate.
Other Activities Related to Credit Intermediation - these firms could potentially be subject to the CRD regime for credit institutions.
Securities and Commodity Contracts Intermediation and Brokerage firms could be subject to MiFID or be MiFID exempt.
Miscellaneous Intermediation - firms classified with this code could qualify for own-account trading MiFID exemption.
16
Trust, Fiduciary and Custody Activities - firms classified under this code may provide credit, but are probably more likely to be NFCs.
Other Financial Vehicles - this code covers mainly funds (closed-ended, unit investment trusts, REITs) but also SPVs and CMOs; hence it is classified as FC but uncertain.
6. Implementation Scenarios and Action Plan This section discusses implementation issues and outlines scenarios for implementing the classification methodology both in the short-term, as an interim measure, and strategically. It addresses a number of issues, including actions required in the near future, ownership, maintenance, publication of the mapping tables, and approaches to more comprehensive data sharing in the longer term.
6.1. Data Sharing
It would be possible for each financial institution to implement the kind of approach discussed here without sharing any data at all. But the objectives of the present project include promoting consistency in approach. The aim is to minimise repetitive, redundant and conflicting communications with clients. Furthermore the intention is to chart a course so that the interim implementation starting in March 2013 can evolve over time into a robust and strategic counterparty classification solution.
This will necessarily involve a measure of data sharing among institutions. The project identified three levels of data sharing that could be considered:
1. Sharing industry code mapping tables only
This is the level of data sharing that is involved in the immediate implementation beginning on March 15th 2013. It has the advantage that it raises no issues of confidentiality about client relationships.
2. Sharing industry code mapping tables and classification statistics
Since EMIR classifications based on industry codes do not yield certain results in all cases, it is necessary to monitor classification success and failure rates, based on each individual industry code, and to maintain the mapping tables accordingly. If institutions pool absolute numbers of data-driven classifications that ultimately lead to reclassifications after interaction with clients, then the data can be aggregated across firms and lead to statistical estimates of certainty in place or in addition to of the a priori certainty flags provided in version 1.0 of the mapping.
The reclassifications would not identify the actual firms involved, so that confidentiality issues would not arise. The effort involved ought not to be very large. Without this monitoring and maintenance it is not likely that the mapping approach would retain the confidence of market participants and regulators.
Nevertheless the drawback is that either a working group or service provider would need to be appointed to aggregate classification statistics, agree changes with sponsoring/participating firms, and control versioning and releasing of the updated mapping workbook. In principle a cross-firm working group with limited donation of resources by the largest firms could implement such a process. Alternatively an industry body such as the BBA could undertake or outsource the work and provide releases on a subscription basis.
The action plan below suggests what the key steps would be to implement such an approach.
3. Sharing industry code mappings and counterparty-level classifications
17
The most ambitious approach to data sharing would be to establish an industry-wide utility whereby the actual classifications, perhaps including NFC-/NFC+ as well as FC/NFC, could be shared at legal entity level.
The advantages of this approach would be very significant. It would bring firms closer to legal certainty based on a single legal entity lookup, and eliminate duplicate and redundant communication with clients. Most of the time, client communications and legal negotiations would be based on matters of fact rather than judgement.
One approach would be that the first institution to on-board a specific legal entity would provide classification data to the utility based on the outcome of its interaction with the client. Subsequently, other firms would implement the same classification without needing lengthy interaction. In a similar way status changes could be reported by the first firm to process the change. In the long run, this would create greater legal certainty for firms, and more consistent compliance with the regulations than other approaches.
But a number of issues arise. Firstly, a model that preserves the confidentiality of a new client relationship would have to be devised. The identity of the firm that first provided the classification should not be known to others, and nor should the identity of subsequent users of the classification or of firms providing status updates.
Secondly: what would be the motivation of the first firm to on-board the client in providing the classification data? Or of other firms providing updates in the case of disputes or status changes? The advantage of being able to look up regulatory status and avoid disputes with clients is real - but it would be necessary to avoid “free-rider” incentives to use but not provide information. One possibility would be a fee-based model in which information providers received a rebate against fees. But another incentive would be that a firm applying and publishing an FC classification rather than NFC, or NFC+ rather than NFC-, could eliminate or at least significantly reduce the chance of commercial arbitrage by competitors over EMIR status.
Thirdly: there is a dependency on having a shared legal entity identifier, ideally the Global LEI or perhaps in the shorter term the CICI. In some cases, registration of a new legal entity would be needed before a classification could be submitted.
Fourthly: an established data service provider, perhaps one authorised under EMIR as a Trade Repository, would have to be appointed and the service would require funding.
No data service provider is immediately able to offer such a service. However, Avantage has identified around ten firms that could be approached via a tendering process. Informal meetings were held with some of these vendors and it appears that there would be appetite for such an initiative, providing it could be funded.
These considerations imply that, given the dependencies and the business model issues noted, this approach would need wider engagement among industry associations, firms and regulators.
6.2. Publication
The BBA intends to publish industry code mapping information on its website, including industry code to EMIR classification tables and all or parts of the present Report.
The code-to-classification information by itself and the contents of the Report are clearly new intellectual capital, but much of the information in the workbook provided is copyright material. This includes the description texts associated with the industry codes and roll-up codes, and the structural information. The following assessment has been derived by reference to the websites from which this information was obtained, but has not been reviewed by legal counsel and it is not to be construed as legal advice.
18
NACE. The NACE manual is marked “(c) European Communities 2008”. The material included in the workbook is based on this manual. There was no obvious information on the website indicating under what conditions information about NACE could be reproduced, but on the other hand several third-party websites republish the information in various forms, indicating that it is EU copyright. It might be safest to include a statement like “NACE information adapted from copyright material, (c) European Communities 2008”.
UK SIC 2007. This is obtained from the UK ONS website. The website states that all material on the site is Crown Copyright, and it grants the right to reproduce subject to source accreditation. The required text in this case is: “Adapted from data from the Office for National Statistics licensed under the Open Government Licence v.1.0”. Interestingly, given that SIC is an overlay on NACE, we seem to have (probably unintentionally) two overlapping and conflicting copyright claims.
NAICS 2012. Information was obtained from US Census Bureau. Neither the website itself, the NAICS manual nor the downloadable Excel worksheets themselves appeared to contain any copyright claim.
6.3. Implementation scenarios
6.3.1. Tactical implementation
Firms need to make rapid progress in classifying counterparties from March 15th 2013 onwards so that they can:
comply with timely confirmation rules; and
begin work on making changes to legal agreements with counterparties to facilitate compliance with the various EMIR obligations, including clearing, risk management and reporting.
Each implementing firm will have distinct processes and distinct implementation issues. What follows is a high-level checklist of the process steps that will have to be integrated into firms’ existing processes.
The key steps in a minimal tactical implementation of the proposed approach, for the backlog of existing counterparties and for take-on of new counterparties, follow.
A. Classification of existing counterparties
1. Ensure that counterparty reference data includes one or more of the supported industry classification schemes, enriching reference data if necessary via bridge mappings from other classification schemes.
2. Make provision for recording both initial automated classifications and final agreed classifications. This is so that statistics can be collected on how often the two differ.
3. Apply the mapping tables from the workbook and derive proposed FC and NFC classifications and the associated certainty levels.
4. For classifications with certainty level 1, generate standard client communication letters and issue them to clients25.
5. For classifications with certainty level 2, group by source industry code and identify the issues at stake before determining whether to go ahead with a standard client letter, or focus
25 See proposed draft client communication letter in Appendix 1
19
the communication more closely on specific issues, by making use of the additional mapping information available in the rationale columns of the worksheets.
6. In the case of NFCs, the draft client communication letter also supports the option to propose an NFC+ or NFC- status. Implementing firms may want to include a process step whereby they actively seek a response on that point.
7. Consider the implications of the expected counterparty classification for compliance with the timely confirmation rules.
8. Where applicable, begin the process of upgrading legal documentation to faciliate compliance with forthcoming clearing, risk mitigation and reporting obligations.
9. Record any status changes agreed with the client as a result of the interaction. Record the new status separately from the original assignment for tracking purposes.
B. Classification of new counterparties
For new counterparties, essentially the same steps should be followed client-by-client, but they should be integrated into the institution’s existing client on-boarding process.
6.3.2. Strategic implementation options
Discussions with regulators suggest that they will be broadly supportive of the proposed approach, but that they will expect to see evidence that it is working and leading to robust classifications and to timely compliance. Two potential approaches are suggested, based on the discussion above under Data Strategy. The first involves sharing only mapping data and pooling reclassification information to validate and also to improve the performance of the mappings based on practical experience. The second is a much longer term approach where actual counterparty level information is shared while preserving the confidentiality of client relationships. It is likely that the regulators will look for the first approach as a minimum over the coming months.
A. Share mappings and reclassification information
This option builds incrementally on the initial implementation approach recommended above under Tactical Implementation. It does not give rise to material confidentiality issues.
Since regulators and market participants will want to be sure that the mapping approach is working, resulting in timely compliance, and causing minimal disruption to client relationships, some level of feedback from the practical classification process must be incorporated into the maintenance of the mapping tables. The level of feedback could vary from informal and partly anecdotal, to submitting periodic detailed information on actual numbers of classifications and reclassifications. The latter could be aggregated to give industry-wide empirical probabilities. Various more or less labour-intensive approaches could be devised. What follows is a description of two potential approaches, a low-effort and informal option and a more labour-intensive option:
Sharing informal information. Informal quantification of reclassifications and anecdotal descriptions of the issues that lead to reclassification could be shared in working group meetings and preserved in the workbook comments columns. This would be useful to support decisions on specific change requests received from members.
Sharing statistical information, where members would submit either reclassification rates per mapping line item, or even absolute numbers of classifications and reclassifications. The latter would allow industry-wide quantification of empirical success rates, but would involve more effort than the previous approach.
In either case, a working group would need to assess the available information and agree on
20
mapping change requests. From time to time members could agree that several mapping and/or certainty level changes should result in a new release of the mapping workbook.
Whenever a mapping is altered, the reclassification state should be reset to show zero reclassifications in order to properly assess the revised mapping. This could be done either
at the level of a workbook release, resetting all mapping entries; or
at the level of a single mapping per industry code.
Clearly these alternatives represent a trade-off between effort and accuracy. The second alternative will preserve all information about the long-run usefulness of each mapping entry up to the point it is revised, if it is ever revised.
B. Share counterparty-level classifications
In the longer term, it would be advantageous to move to an industry-wide counterparty-level EMIR classification utility, as discussed in the section on Data Sharing above.
Key advantages:
Achieve consistent and compliant classification;
Reduce volume of redundant client communications;
Improve on-boarding process efficiency and timeliness;
Remove classification arbitrage opportunities.
Such an approach could be extended to include NFC+ status26.
6.4. Action plan
Following completion of the project deliverables, the following key actions will need to be taken to complete the tactical implementation and chart a course for a more robust approach in the future.
Member implementation. Run initial classifications and review results in working group meeting. Determine whether any immediate mapping revisions need to be made.
Publication. Decide on approach and timeline for publication. Execute.
Ownership and maintenance. Establish short-term ownership and maintenance responsibilities. Should they lie with the BBA Data Management group, some other working group established for the specific purpose, or a third party?
Reclassification data. Define the approach and process for collecting reclassification information. How formal or informal should this be?
Change management and releasing. Define the approach for managing workbook change requests and releasing updated workbook versions.
ESMA meeting. Being organised.
National supervisor meetings. BaFin meeting organised.
FSA meeting. Prepare for and organise review of the approach with FSA for June/July 2013.
26 Note that due to the exact wording of EMIR, notification of an NFC clearing breach to ESMA is based on a single
daily breach, and does not mean that a counterparty is certainly an NFC+. Also ESMA is not bound to publish the notifications in any case.
21
Strategic solution. Evaluate the approaches for a long-term strategic solution and consider whether other industry bodies should also be involved, if so which should be approached and how such an initiative should be organised.
Data management requirements for strategic solution. If a hosted data sharing solution is selected, data management requirements must be defined covering: data quality management, liability, data protection, business continuity and data communication technical solutions.
Common process standards and communication protocols. Consider whether common process standards could be established for the main use cases, and which process steps should trigger interactions such as client communications.
Tendering process for strategic solution. Run a tendering process, if a hosted solution is planned.
7. Disclaimer The assessments and methodology proposed in this report are not intended as legal advice and the methodology will not result in legal certainty about client status.
8. Appendix 1: Draft client communication letter The following draft letter is a standard form that can be used to notify clients of their proposed classification under EMIR. It could be adapted to address only the FC/NFC classification or used as below to include a provisional assessment of NFC+ status, either defaulting to NFC+ or NFC-, or making a determination based on information already available.
Dear [client]
As you may know, EMIR (the Regulation on OTC derivatives, central counterparties and trade repositories) came into force on 16 August 2012. The first set of Regulatory Technical Standards (RTS) necessary to bring certain aspects of EMIR into effect come into force on Friday, 15 March 2013. Of these RTS, the only ones which may affect you immediately are those covering your classification as a counterparty, notification, the timely confirmation of uncleared trades and daily valuations (not required for non-financial counterparties).
We have been working with the British Bankers Association (BBA), and a number of other major banks, to produce a methodology which is separate and distinct from the ISDA Protocol but which works alongside the Protocol to determine our customers’ classification for the purposes of EMIR.
We have used the standard industry classification code [pick one NACE/NAIC/SIC] which we assigned to [you or specify legal entity name?] as part of your original on-boarding process, having mapped it according to the industry agreed solution referred to above, in order to determine that you should be classified as a [pick one financial counterparty/non-financial counterparty] for the purposes of EMIR.
[If NFC add] Additionally, as a non-financial counterparty , we need to know whether this entity is above or below the EMIR clearing threshold. Unless you notify us differently, we propose to classify you as [NFC+ (above the threshold) / NFC- (below the threshold)], which [requires/does not require] you to comply with the clearing obligation and stricter risk mitigation measures for uncleared OTC derivative contracts. Therefore, it is in your interests to notify us if you are NFC-. It will also be your responsibility thereafter to notify us if your classification changes.
If you disagree with your classification as a [financial counterparty/non-financial counterparty above the clearing threshold/non-financial counterparty below the clearing threshold], please email
22
us promptly using the following address: [insert firm specific email address]. If we do not hear from you, we will proceed to apply the relevant articles of EMIR and the RTS to you as a [financial counterparty/non-financial counterparty above the clearing threshold/non-financial counterparty below the clearing threshold].
9. Appendix 2: Workbook User Guide This section provides a guide to the structure and contents of the NACE-SIC-NAICS mapping workbook. The workbook contains nine worksheets. All are set up to be printable, but some of the worksheets (indicated below) will lead to printouts of hundreds of pages. To print only the cover and core mapping tables, select Print Entire Workbook, and print pages 1 - 4027.
The worksheets in the workbook are as follows.
Cover, containing the contents page and version control information.
SIC-07, the main mapping worksheet for both NACE and SIC. This worksheet contains the database defining the mappings for both SIC and NACE. To look up a NACE code, either look up the xx.yy format in column D, or add a trailing zero to give the format xxyy0 and look up in column A. The columns to edit to maintain mappings are Q (FC/NFC flag), R (certainty - set to 1 or 2), the rationale columns S to AA, and the comments column AB. See below for more details.
NAICS-12, the main mapping worksheet for NAICS. This worksheet contains the database defining the mappings for NAICS 2012. The columns to edit to maintain mappings are K (FC/NFC flag), L (certainty - set to 1 or 2), the rationale columns M to U, and the comments column V. See below for more details.
NACE-R2 Structure, which provides the NACE structure and description text. This is used in lookups from the SIC-07 sheet, and should not be updated unless converting to a new NACE release. For convenience, columns N and O contain the NACE-implied NFC/FC and certainty data, looked up from the SIC-07 sheet. Do not edit these directly. Furthermore, because this is a structure sheet it contains roll-up lines with NFC/FC and certainty flags set to “n/a”. It is probably best to use SIC-07 directly for both SIC and NACE lookups. See below for more details.
NACE-SIC-07 Sect is a lookup table for the NACE sections. It applies to both NACE and SIC.
SIC-07 Structure contains the UK SIC 2007 structure and description text in an indented layout. Down to Class level this is identical to NACE R2.
SIC-07 Alpha Index contains an alphabetical index of SIC 2007 by description text. BEWARE: very large printout.
SIC-03-07 maps from SIC-2003 to SIC-2007. BEWARE: very large printout.
NAICS-12 Structure contains the NAICS 2012 structure and description text. BEWARE: large printout.
9.1. NACE/SIC mapping sheet (SIC-07)
The workbook contains many sheets. The key one to look at is SIC-07, which contains the full mapping data for both SIC 2007 and NACE revision 2. There is also a NACE-R2 tab containing
27 This is correct for Release 1.0 of the workbook.
23
only the NACE mappings, but this is constructed using lookups into the main SIC worksheet. The reason for this approach is that the NACE and SIC mappings are thereby guaranteed to be consistent, and they can be maintained in parallel by updating only the one worksheet. Excel filters are available on all of the columns. Some columns are folded away using Excel outlining. The + icons at the top of the sheet can be used to unfold and refold them.
The mapping lookup key in the NACE/SIC worksheet is the 5-digit UK SIC code (or for NACE, a 4-digit NACE code plus a trailing zero).
The SIC 2003 code has not been separately mapped, but a concordance is available (see worksheet SIC-03-07). The first four digits of SIC 2007 correspond exactly to the 4-digit NACE release 2 code, and at that level of granularity the SIC and NACE codes and definitions are exactly identical: SIC 2007 is built on top of NACE 2. The latter is the current EU standard, which will be mandatory for COREP reporting. The UK SIC has one extra digit, the subcode, not present in NACE. The SIC subcode can also be found separately in column O of the worksheet.
Where the SIC subcode is equal to zero, SIC has no more granularity than NACE and the meaning of the two codes is identical. Where SIC breaks the NACE code down by two or more SIC subcodes, the subcodes lie in the range 1-9. Where there are 5-digit SIC codes with non-zero subcodes, the SIC code ending in 0 is a roll-up (called a “Class”) and it should not be directly applied to a counterparty - the more detailed subcodes should be used instead. Nevertheless, column A contains entries for SIC roll-up classes ending in subcode 0. These are distinguished by red italic formatting. There is also a “Valid SIC?” flag in column B: where this is “N”, the spreadsheet line represents a NACE code that should be used under NACE but not under SIC: the data here is used only when a counterparty has a known NACE but no known SIC.
Clearly, when both SIC and NACE codes are available the SIC should be used in preference to the NACE since it will sometimes contain more information, and in the case of the outliers in the Financial Services section, SIC is very often more detailed in a useful way. A NACE code can be looked up in this sheet by adding a “0” to the 4 NACE digits to make a 5-digit code. This lookup will succeed whether the resulting code is a valid SIC (no further drilldown) or an invalid SIC (SIC has further drilldown). In this way, the worksheet can contain the full dataset for both SIC and NACE.
The true 4-digit NACE code in “XX.YY” format can be found in Column D. The separate NACE worksheet can be also used directly with 4-digit NACE codes, but note that it is derived from the main SIC dataset.
UK SIC 2007: Column A contains the 5-digit UK SIC 2007 code.
Valid SIC and Valid NACE flags: Columns B and C contain flags to indicate whether the given row represents a valid SIC only, a valid NACE only, or (the most common case) both a valid NACE and a valid SIC. Where SIC contains entries with subcodes between 1 and 9, the resulting codes do not correspond directly to a valid NACE, and in this case a “dummy roll-up SIC” is included as an extra row, with a subcode 0, to represent the NACE. This entry will be flagged “Valid NACE” but not “Valid SIC”. Where SIC contains only subcode 0 for a given 4-digit class, then the codings and their meanings are identical in both schemes. This is the most common case. Both flags will then be set to “Y”. It is a significant maintenance and data quality benefit to have only one entry to maintain in these cases.
NACE code: the true NACE code is contained in column D, but only for codes that are valid NACE codes. Where this column is blank, this indicates that there is a SIC drill-down with subcodes other than 0; for the less granular NACE code corresponding to a given SIC, you can look at the first preceding row with a subcode of 0.
24
Description: Column E contains the UK SIC description. Where the row represents a valid NACE and a valid SIC, the descriptions (and the underlying guidance) are exactly the same in both cases. Where the row represents a UK SIC that is more granular than the rolled-up NACE, the SIC description is provided. Where the row represents a NACE code but the SIC code is a dummy roll-up line (with red italics in column A) the description is derived from NACE, but the SIC description for the rolled-up class is exactly identical. Some NACE or SIC descriptions contain the acronym “n.e.c”. This stands for not elsewhere classified.
Section: The one letter section code is provided in column G and the associated description in column H. These are identical in both schemes. Almost all outliers lie in Section K, Financial and Insurance Activities.
Division: The two digit division code is provided in column I and the associated description in column J. These are identical in both schemes.
Group: The three digit group code is provided in column K and the associated description in column L. These are identical in both schemes.
Class: The four digit class code is provided in column M and the description in column N. In NACE, the class is the lowest level code. In SIC, there is one more level represented by the subcode. The 4-digit class level code and descriptions are identical in both schemes.
SIC-sub: Column O contains the one digit SIC subcode. If the subcode is equal to zero, there can be two reasons: (i) SIC is no more granular than NACE at this point, and the resulting 5-digit code is a valid SIC or (ii) SIC is more granular than NACE at this point, and the row represents a valid NACE code and a dummy SIC (i.e. a SIC roll-up class). To distinguish between these cases refer to the flag in column B: this is set to Y in case (i) and N in case (ii).
FC/NFC: This column (Q) contains the proposed EMIR mapping, either FC or NFC. Note that in no case is the mapping absolutely 100% certain, but most of the mappings have a very high probability. We may discover empirically in future either that no member institution has any exceptions at all to a given mapping row, so that the empirical probability is close to 100%, or it may be lower in other cases. See Certainty below.
Certainty: The overall degree of confidence in the mapping is provided in column R. The confidence level is an a priori assignment. If a regulatory regime permits exemptions, opt-outs or supervisory discretion, then a high degree of confidence is unattainable, although we may find that we are close to 100% in empirical terms: this can be discovered over time as we apply the mappings. There are two possible a priori confidence levels, either 1 or 2.
1. This implies a very high degree of confidence – we are almost certain of the resulting mapping.
2. This implies that there are known reasons for uncertainty - for example de minimis exemptions - or otherwise that exceptions have been encountered in practice. Because the mapping could result in misclassifications, it should be checked on a case by case basis.
Mapping Rationale: Columns S to AA indicate the basis of the classification in the case of codes assigned as FCs. They contain no information in the case of codes mapped to NFC. The possible reasons for an FC classification, based on the text of the EMIR regulation, are ninefold. Each reason corresponds to regulatory status under one or other of the EU regulatory frameworks. There is one column for each possible reason:
MiFID Investment Firm, column S. This column contains flags that indicate that the
25
industry code implies that an entity is likely to be or possibly an Investment Firm under the MiFID regime.
CRD Credit Institution, column T. This column contains flags that indicate that the industry code implies that an entity is likely to be or possibly a Credit Institution under the Capital Requirements (CRD) regime.
Insurance Undertaking, column U. This column contains flags that indicate that the industry code implies that an entity is likely to be or possibly an Insurance Undertaking under the Non-Life Insurance regime.
Assurance Undertaking, column V. This column contains flags that indicate that the industry code implies that an entity is likely to be or possibly an Assurance Undertaking under the Life Insurance regime.
Reinsurance Undertaking, column W. This column contains flags that indicate that the industry code implies that an entity is likely to be or possibly a Reinsurance Undertaking under the Reinsurance regime.
IORP, column X. This column contains flags that indicate that the industry code implies that an entity is likely to be or possibly a Pension Fund under the Institutions for Occupational Retirement Provision (IORP) regime.
UCITS, column Y. This column contains flags that indicate that the industry code implies that an entity is likely to be or possibly a UCITS fund under the UCITS regime.
UCITS Manager, column Z. This column contains flags that indicate that the industry code implies that an entity is likely to be or possibly a UCITS management firm under the UCITS regime.
AIF, column AA. This column contains flags that indicate that the industry code implies that an entity is likely to be or possibly a Alternative Investment Fund under the AIFMD regime.
Note that there is no separate column for AIFMs, even though there is a column for UCITS management firms. This is based on the definition in the EMIR regulation. It is unlikely to make a difference because an external AIFM is in any case very likely to be also a MiFID investment firm and/or a UCITS management firm. An internal, i.e. self managing AIFM is of course in any case itself an AIF.
In these nine columns, only the rows where an FC mapping is proposed should contain entries. The possible entries are:
VL: this indicates that an entity with this code is very likely to be regulated under the applicable regime for that column.
L: this indicates that an entity with this code is likely to be regulated under the applicable regime for that column.
P: this indicates that an entity with this code may possibly be regulated under the applicable regime for that column, but this is very uncertain.
Note that blank entries in any column indicates that the entity is not at all likely to be regulated under this regime.
Comments: Column AB contains explanatory comments to assist with review and maintenance. This can be updated over time to record the results of discussions and the principles that should be applied in resolving issues.
26
27
9.2. NAICS mapping worksheet (NAICS-12)
The NAICS worksheet is structured in the same way as the SIC worksheet.
NAICS 2012: Column A contains the 6-digit NAICS code. Earlier versions have not been separately mapped, but a concordance is available.
Title: Column B contains the NAICS description.
L1 - L2 - L3 - L4: Columns C, E, G, I contain the Level 1, 2, 3 and 4 roll-up codes. The intervening columns, D, F, H, J, contain the associated descriptions. All outliers lie in the range of the Level 1 code 52, Finance and Insurance.
FC/NFC: This column (K) contains the proposed EMIR mapping, either FC or NFC. Note that in no case is the mapping absolutely 100% certain, but most of the mappings have a very high probability. We may discover empirically in future either that no member institution has any exceptions at all to a given mapping row, so that the empirical probability is close to 100%, or it may be lower in other cases. See Certainty below.
Certainty: The overall degree of confidence in the mapping is provided in column L. The confidence level is an a priori assignment. If a regulatory regime permits exemptions, opt-outs or supervisory discretion, then a high degree of confidence is unattainable, although we may find that we are close to 100% in empirical terms: this can be discovered over time as we apply the mappings. There are two possible a priori confidence levels, either 1 or 2.
3. This implies a very high degree of confidence – we are almost certain of the resulting mapping.
4. This implies that there are known reasons for uncertainty - for example de minimis exemptions - or otherwise that exceptions have been encountered in practice. Because the mapping could result in misclassifications, it should be checked on a case by case basis.
Mapping Rationale: Columns M to U indicate the basis of the classification in the case of codes assigned as FCs. They contain no information in the case of codes mapped to NFC. The possible reasons for an FC classification, based on the text of the EMIR regulation, are as documented in the previous section on the SIC/NACE mapping worksheet.
Comments: Column V contains explanatory comments to assist with review and maintenance. This can be updated over time to record the results of discussions and the principles that should be applied in resolving issues.
9.3. NACE structure worksheet (NACE-R2 Structure)
The NACE-R2 Structure worksheet contains one row for each NACE Section, Division, Group and Class; it encodes not only the 4-digit class codes but the hierarchical structure of NACE. The Class, or Level 4, codes are the most granular NACE codes.
This worksheet is primarily used by the main SIC-NACE database (sheet SIC-07) to look up the hierarchical roll-up codes and their descriptions. The SIC-07 sheet holds the mapping data for both the SIC and NACE schemes.
The NACE-R2 Structure worksheet should not be used to maintain industry code mappings data, but for convenience it does include them in columns N and O respectively. These are derived via lookups from sheet SIC-07, and are only provided for Level 4 NACE codes. (Roll-up codes are classified as “n/a”.)
