When non-EU service providers lack a LEI: the identifier workaround

if you're working with non eu ict service providers that don't have a legal entity identifier, you face a practical compliance challenge the https //eur lex europa eu/legal content/en/txt/html/?uri=oj\ l 202402956 requires lei for all legal persons established outside the eu, but many providers simply don't have one this article explains the regulatory workaround that prevents submission failures the referential integrity problem identifier fields in template b 05 01 are key values in the register's data model you cannot leave them empty why empty fields cause rejection the data model uses identifiers as key values to link information across different templates if you leave field b 05 01 0010 (identification code of ict third party service provider) empty, the entire submission file fails referential integrity checks the esas' validation system will reject your file before it even reaches the quality review stage this creates an impossible situation the regulation requires lei for non eu legal persons, but the provider doesn't have one you cannot submit without an identifier, but you cannot obtain the required identifier never use false placeholders some financial entities consider entering placeholder values like "999999999999999999xx" or fabricated lei codes to bypass the validation this violates data quality principles and creates false regulatory records that undermine the register's supervisory purpose the esas need accurate information to assess concentration risk and map dependencies in the financial system the regulatory solution use available identifiers faq question 40 in the register of information faq provides the pragmatic solution when lei is not available for non eu ict service providers (or their ultimate parent undertakings), you should populate the identifier field with any relevant value that is actually available in practice, this means using other identifiers such as corporate registration numbers from the provider's jurisdiction tax identification numbers other official registration codes that uniquely identify the legal person the key principle provide actual, verifiable information about the provider rather than invented codes how the esas handle alternative identifiers the validation system recognizes that not all non eu providers have lei using alternative identifiers triggers a data quality flag, but your submission will not be rejected based on this issue alone the esas acknowledge this approach in faq question 40 "the use of such identifiers will be highlighted as a data quality issue, but the files will not be rejected whether the esas will be able to use the entries with such missing or invalid lei will depend on the overall quality of the relevant entries and any other data quality issues identified in the checks " this means your submission proceeds through validation, and the esas can still use the information you provide even without a valid lei the data quality flag simply indicates where identifier gaps exist reporting the alternative identifier when you use an alternative identifier for a non eu provider without lei, you need to report it correctly in template b 05 01 field b 05 01 0010 identification code enter the actual identifier you have available this could be the corporate registration number, tax id, or other official code from the provider's jurisdiction field b 05 01 0020 type of code select the appropriate code type from the closed list of options crn for corporate registration number vat for vat number other codes as specified in the template instructions note according to faq question 47, you should choose only from the closed set of options without including country codes, despite some inconsistencies in the published its text additional practical considerations ultimate parent undertaking identifiers the same pragmatic approach applies to field b 05 01 0110 (ultimate parent undertaking identifier) this field is critical because the esas use it to group all providers belonging to the same corporate family when analyzing concentration risk when the ultimate parent undertaking lacks an lei, use whatever identifier is available the esas note in faq question 42 that they will use reference data sources like gleif where possible, but they recognize that not all identifiers will be in these databases lapsed lei status if your non eu provider has an lei but it shows as "lapsed" in the gleif database, there's additional flexibility during 2025 faq question 44 clarifies that while the its requires active lei status, the esas will not enforce strict status checks during the initial reporting period validation will verify the lei exists in gleif, but lapsed status won't cause rejection where to find detailed guidance the pragmatic approach for unavailable lei is documented in the register of information faq https //www eba europa eu/activities/direct supervision and oversight/digital operational resilience act/preparation dora application key faq questions faq question 40 what identifier should be reported if the lei for the ict third party provider registered in a third country is not available? faq question 39 which identifiers can be used in the registers? (provides context on normal requirements) faq question 42 how do esas intend to aggregate ict tpps when lei is not available? faq question 44 will lapsed lei identifiers be accepted? faq question 47 how to report the type of identification code in data field b 05 01 0020? the https //eur lex europa eu/legal content/en/txt/html/?uri=oj\ l 202402956 establishes the baseline requirement that non eu legal persons should use lei in article 3(5) avoid common dora reporting errors handling unavailable identifiers is just one of many pitfalls in dora register of information reporting our comprehensive dora compliance checklist helps you identify and prevent common errors before they impact your reporting mailto\ info\@dora solutions com?subject=request%20for%20dora%20compliance%20checklist\&body=hi%20dora%20solutions%20team,%0d%0a%0d%0ai%20read%20your%20article%20about%20handling%20unavailable%20lei%20for%20non eu%20providers%20and%20would%20like%20to%20receive%20your%20dora%20compliance%20checklist %0d%0a%0d%0abest%20regards