RegTech Intelligence 
JWG analysis.
In late October, the European Banking Authority (EBA) released a consultation on the use of the Legal Entity Identifier (LEI) for CRD IV’s risk reporting requirements. Now that the consultation phase has been concluded, firms may only have around 60 days to register LEIs for all their entities that report under CRD IV.
The EBA’s recommendation is that all entities required to report under the EU Basel III rules (COREP) must obtain a pre-Legal Entity Identifier (pre-LEI) code for reporting purposes:
“for institutions for which information is required to be transmitted to the EBA in the context of the ITS and in accordance with EBA Decision No 90/2013 on reporting to the EBA by 31 March 2014 at the latest.”
While this development is not necessarily unexpected, the timeline in which to register the required entities is short. This may cause problems. The number of entities required to register for risk reporting is a considerable increase over the number required for EMIR, i.e., trading entities. Some estimates place this increase in the region of 900%, i.e., a firm that is required to register 500 LEIs for EMIR will need to register 5,000 for risk reporting (See our article on operational risk issues for the LEI).
This is not the only problem however. Through mandating the use of the LEI, the EBA is introducing a new use-case for the LEI, which adds fresh complexity to an already complex issue.
There is still a lot of uncertainty over which entities can, and should, be registered for an LEI. The protocol for the registration of certain entities, such as funds or branches, is still uncertain as the ROC has yet to set guidance. The global LEI system is still a work in progress and there are a number of steps that have to yet to be taken before we have a ‘final’ LEI. LOU portability standards, the Central Operating Unit’s (COU) embedded hierarchy standards, and the list of entities which are in scope for the LEI (e.g., funds, branches, legal personality etc.) have yet to be defined.
As a result of the EBA’s decision, firms now have to make judgement calls on what is appropriate when implementing the LEI into their risk reporting systems. Examples such as whether sub-funds should be registered in addition – or instead – of the umbrella fund may mean the difference between compliance and non-compliance. Additionally, a protocol will be required in the (hopefully unlikely) event that the ROC’s final standards for the LEI conflict with the EBA’s requirements for its use.
Whilst definitely a positive step towards a single standard, the utility of the LEI for risk management is still in question. Pre-LEIs don’t yet contain the hierarchical reference data required to make it truly useful. For example, ultimate parent/immediate parent data fields have yet to be defined meaning that in use-cases such as tracking counterparty exposure, the key potential benefit of the LEI to risk analysis is missing. This type of information is a cornerstone for the utility of the LEI, and while the ROC has endorsed the accounting consolidation hierarchy approach as a ‘first step’ for development of the LEI relationship data, there is still much work to be done.
In order to prioritise what needs to happen, when and for what purpose, clarity on individual scenarios is required, which the EBA does not provide. For example, will all entities that need an LEI for risk reporting purposes need to register at a European LOU? Are sub-funds, branches, market venues and trade repositories going to be assigned LEIs? Will large exposure reports require firms to register their counterparties for LEIs? Will hierarchy be required for risk management purposes?
Without answers to these types of questions, there is significant risk that regulators will inadvertently produce conflicting requirements for its use across risk, trading and other 2014 regulatory initiatives (e.g., Solvency II, AMLD IV etc…), forcing firms to implement yet another mapping column.
Without guidance from the EBA we run the risk that reported data will be undermined by lack of referential integrity of the data and result in ‘Garbage In, Gospel Out’ (GIGO).