Regtech: The 20-char code that only proves the past
I’ve been staring at the camt.053 schema for a while now, not building anything in particular, just curious about why a single message contains so many identifiers and what information they convey. In particular, my eyes were drawn to the LEI element sitting alongside AnyBIC, same parent, same level, both optional, neither one checked by anything in the schema itself.
That pairing is what sent me searching. I recognized AnyBIC immediately, the familiar BIC code stamped on nearly every payment message. LEI, sitting right next to it with the same weight, I couldn’t place. A BIC’s promise is backed by a network. SWIFT issues it, banks route real money against it every day, and if it’s wrong, the payment fails, loudly, immediately, in a way someone notices within minutes. I ran the tag LEI through the Navigator’s own schema explorer, scoped to camt.053, and got back 58 matches. Fifty-eight separate places inside a single message type where an LEI could show up, debtor, creditor, every agent in the chain, remittance parties, even a message receipt field most people scanning a statement would never think to look at.
Staring at that pairing for the tenth time, I realized I had no idea what actually validates the LEI, or when, or how often, or by whom. So I asked myself a simple question: what does that LEI field actually prove, at the moment someone reads that statement? I didn’t have a good answer. So I started digging into what an LEI actually is, and what it was ever built to promise in the first place.
Follow along as ISO standards get pulled apart field by field. The ISO Navigator publication is where that happens.
What LEI actually is
That digging led me, like it so often does, into yet another standard: ISO 17442.
LEI stands for Legal Entity Identifier, a 20-character code introduced to give regulators and counterparties a single, unambiguous way to identify who they’re dealing with, closing a real gap: national and proprietary identifiers were never designed to be reliably cross-referenced across borders. Under that standard, the code breaks into four fixed segments. Take this one as an example: 529900EXAMPLE0001043.
5299 -> LOU prefix (who issued it, not who holds it)
00 -> reserved, fixed, holds no information
EXAMPLE00010 -> the issuer's internal entity identifier
43 -> check digits using MOD 97-10 algorithm (ISO 7064)The first four characters identify the Local Operating Unit (LOU) that issued the code, not the entity itself. The next two are reserved, permanently set to 00, set aside for potential future use. Twelve characters after that are the issuer’s own internal identifier for the entity, and they carry no meaning of their own. They’re not a hash, not a hierarchy, not a classification, just a serial number the issuing LOU assigned. The last two are check digits, there purely to catch a mistyped character before the code gets used anywhere downstream.
Read that breakdown again and notice what’s missing. No country. No industry. No entity type. It would be a reasonable guess that a global standardized identifier encodes at least a jurisdiction somewhere in those twenty characters. It doesn’t. And only legal entities can hold one, which matters later when we get to who’s actually allowed to act on an entity’s behalf.
Issuance itself isn’t centralized. GLEIF, the Global Legal Entity Identifier Foundation, oversees the whole system, sets the rules, maintains the master data, but doesn’t issue a single code itself. That work is done by just under 40 accredited Local Operating Units spread across the world, and most of them aren’t limited to one country the way a tax authority only issues IDs for its own country. A company in nearly any jurisdiction can register through any LOU accredited to serve it. Coverage works more like a licensing map than a national franchise, and that’s a deliberate design choice, not an oversight.
The softer tier
Behind every LEI, GLEIF maintains two tiers of reference data, and most people who encounter the code never learn there’s a second one. Level 1 answers who this entity is: legal name, registered address, incorporation details, the kind of thing you’d find on a certificate of registration. Level 2 answers a much more interesting question, one GLEIF itself frames bluntly: who owns whom. Direct parent is whichever entity folds this one into its own consolidated financial statements. Ultimate parent sits at the top of that chain, the entity that consolidates everything beneath it and has no parent of its own. Stack enough of those relationships together and a subsidiary that looks independent on paper traces straight back to the group actually controlling it.
Here’s the part worth slowing down on. Level 2 data is self-reported by the entity, checked against public filings only where those filings exist and are accessible, and disclosed entirely at the entity’s discretion. An entity can choose not to report it, or can report an exception like NON_CONSOLIDATING or NO_KNOWN_PERSON and that’s accepted as-is.
A 20-character code with a check digit looks engineered to a rigorous standard, and structurally, it is, hard to fumble by accident. But the meaningful content behind it, especially the ownership layer, the kind of thing that actually matters for credit exposure, sanctions screening, and concentration risk, rests on a much softer foundation than the code’s clean, checksummed appearance suggests.
Back to that field in camt.053
None of this shows up when the code is just sitting in an ISO 20022 statement message. The field holds a string. It’s well-formed, it passes its check digits, and the message structure treats it as settled fact, no different from a name or an address.
But an LEI registration isn’t a one-time event. GLEIF requires entities to renew and re-validate their LEI data annually, and a registration that lapses doesn’t get deleted, it just gets marked LAPSED in GLEIF’s own records while the code itself keeps sitting, unchanged, in every message and every system that ever recorded it. A statement entry generated last week could be carrying an LEI whose underlying registration lapsed eighteen months ago, and nothing about the field itself would tell you that. The XML doesn’t know. The message schema doesn’t check. It just holds the string.
Get Manish Patel’s stories in your inbox
Join Medium for free to get updates from this writer.
Nothing confirms it still belongs to the entity it was issued to, entities do occasionally merge, restructure, or get acquired. And nothing confirms whoever generated the statement had any current relationship to that entity at all. An LEI proves registration happened, once, at some point in the past. It says nothing about right now. As we’ll see later, this isn’t just a theoretical gap, it creates real problems.
Well-formed is not the same as valid
All of this, the segments, the two tiers, the lapsed status nobody sees, was scattered across GLEIF’s own documentation and a handful of registrar sites, nowhere in one place that actually explained what any of it meant to someone who’d just found an LEI sitting in a message. So I built the LEI reference page on the Navigator, the same kind of plain-English breakdown as everything else on the app, and added a validator alongside it, since a page explaining the format without a way to actually check one felt incomplete.
When I built that validator, I wrote a caveat under it almost as an afterthought, one line, easy to skip past: checks format and check digits only, per ISO 17442, not live registration status. Search the Global LEI Index for that.
I wrote that line because it’s true, and because I didn’t want anyone assuming the validator does more than it does. A code can pass every check my validator runs and still belong to an entity that dissolved last year. But writing that caveat is what made me realize it’s the exact same gap I’d been circling in camt.053, just stated plainly on a webpage instead of sitting three levels deep in a message schema where nobody thinks to question it. A well-formed code and a currently valid, currently controlled, currently relevant code are not the same claim. Nothing in the standard, and nothing in my own validator, closes that distance. My validator doesn’t lie about what it does. It just makes visible a limitation that’s been sitting quietly inside every ISO 20022 message carrying an LEI field.
Want to understand what an LEI actually is, or check whether a specific one? The LEI Navigator breaks down the segments, the two tiers of registration data behind the code, and runs the format checks, free, no signup.
What vLEI actually changes
GLEIF built something aimed squarely at this gap: vLEI, the verifiable LEI. Same underlying 20-character identifier, but instead of sitting in a database as a lookup key, it’s wrapped in a credential that can be checked cryptographically at the moment it’s presented, not looked up later against a registry and hoped for the best.
Accredited Qualified vLEI Issuers, GLEIF calls them QVIs, issue a Legal Entity vLEI Credential directly to an organization, and that credential can be checked on the spot, cryptographically, by anyone it’s presented to.
That maps directly onto the gaps already covered here. A lapsed registration shows up immediately, because the check happens live, not against whatever the field said when someone typed it in. A dissolved entity’s credential can be revoked rather than just quietly forgotten in GLEIF’s records while its old LEI keeps sitting in a decade of statements.
What it doesn’t do is drop into the same OrgId/LEI field. A vLEI is a credential object, not a string, so it can’t be parsed out of a camt.053 or pacs.008 payload the way the plain code is. It has to be exchanged and verified through a separate presentation flow, and there’s no established way yet for that flow to attach to an actual payment or statement message, not from ISO, not from SWIFT, not from GLEIF itself. The 20-character code stays right where it is. What changes is what travels alongside it, once someone builds the plumbing to carry it.
That plumbing is still being built. GLEIF has started accrediting the issuers who’ll eventually be able to hand these credentials out, but the ecosystem is young, and there’s no regulatory mandate for vLEI itself anywhere yet. The standard exists. Using it in an actual payment message doesn’t, not yet.
From capital markets to camt.053
LEI isn’t optional everywhere, and it hasn’t been for a while. It’s long been required the moment an entity touches regulated capital markets activity, trading securities, entering derivatives, running a reportable fund structure, EMIR, MiFID II and MiFIR, existing regulatory plumbing that already leans on LEI as a mandatory field. In the US, SEC Form PF is catching up: LEI becomes mandatory there from October 2026.
But it’s not just securities and derivatives anymore, and it’s moving into payments faster than a single field buried in camt.053 might suggest. India has the most aggressive mandate so far: since October 2022, banks must obtain an LEI for resident entities on capital or current account transactions above roughly 500 million rupees, about $6 million, and once an entity has one, it has to be used on every subsequent transaction regardless of size, mandatory in both RTGS and NEFT, India’s core payment rails. The UK is closer to home for this article specifically: the Bank of England mandated LEI in CHAPS, the UK’s high-value payment system, for certain payments starting May 1, 2025, with an explicitly stated intent to widen that to all large-value payments over time, and reported LEI population ‘skyrocketing’ since the mandate took effect.
Beyond those two hard mandates, most major real-time and high-value payment systems now at least support optional LEI fields in their ISO 20022 messages: Australia’s HVCS, the EU’s Target2 and TIPS, Hong Kong’s CHATS, Singapore, and Fedwire in the US, which completed its own ISO 20022 migration in July 2025 and now supports LEI as an optional field too. The field sitting in camt.053 isn’t a stray leftover from derivatives regulation bleeding into payments messaging. It’s part of a genuine, actively growing push to get LEI into payment rails specifically, still voluntary in most corridors, but moving toward mandate, not away from it.
Correspondent banking has its own version of this problem. A bank onboarding a new corporate customer, or refreshing KYC on an existing one, still spends real time and real money confirming that the entity claiming an LEI is actually who they say they are. That verification work happens today through documents, calls, and manual checks, the exact overhead an instantly verifiable credential is built to remove.
What’s missing isn’t the requirement to have an LEI. It’s a way to check, at the moment a transaction or an onboarding step actually happens, that the requirement is still being met by the party standing in front of you right now, not just by whoever registered that code years ago and may or may not still control it.
The full camt.053 schema is searchable on the ISO 20022 Navigator, free, no signup.
A code that was once true
A field can be present in a message, well-formed, correctly checksummed, sitting exactly where the schema says it should, and still not prove anything about the moment you’re actually reading it. That’s not a flaw in ISO 20022, and it’s not a flaw in my validator either. It’s just what a 20-character code was always able to promise, and what it was never built to promise.
A code that was once true and a claim that’s true right now are not the same thing. Fifty-eight places in a single message, and not one of them can tell the difference.
References
- GLEIF, “ISO 17442: The LEI Code Structure” — https://www.gleif.org/en/about-lei/iso-17442-the-lei-code-structure
- ISO, “ISO 17442–1:2020” — https://www.iso.org/standard/78829.html
- GLEIF, “Level 2 Data: Who Owns Whom” — https://www.gleif.org/en/lei-data/access-and-use-lei-data/level-2-data-who-owns-whom
- CSSF, “Mandatory use of LEI under MiFID II/MiFIR and EMIR” — https://www.cssf.lu/en/2017/10/mandatory-use-of-legal-entity-identifier-lei-under-mifid-ii-mifir-and-emir/
- Bank of England, “Mandating ISO 20022 enhanced data in CHAPS” — https://www.bankofengland.co.uk/paper/2024/policy-statement/mandating-iso-20022-enhanced-data-in-chaps
- BIS/CPMI, “Fostering ISO 20022 Harmonisation — Follow-up Report,” February 2026 — https://www.bis.org/cpmi/pietf/iso20022_2026.pdf
