The legal entity identifier in cross-border payments: what an LEI settles that a name cannot

A cross-border payment names its parties in free text. A legal entity identifier names them once, in a code that means the same thing in every system that reads it. The LEI is a twenty character code attached to a legal entity. It is not attached to an account, and not to a payment. It moves no money and clears nothing. What it does is take the guesswork out of the question that screening, reconciliation and ownership analysis all have to answer first: which company is this?

What is a legal entity identifier, and who issues it?

The standard is ISO 17442. It defines the code and the reference data behind it. A code is twenty alphanumeric characters. The last two are check digits, so a mistyped LEI fails validation instead of pointing at the wrong company. The code itself is not readable. Everything useful sits in the public record attached to it.

The Global Legal Entity Identifier Foundation, known as GLEIF, runs that record. Codes are issued by accredited Local Operating Units, usually exchanges, registries or financial data firms. The system came out of G20 and Financial Stability Board work after the 2008 crisis, when supervisors found they could not add up exposures across firms because nobody agreed on who the counterparties were.

The reference data comes in two levels. Level one answers who is who: legal name, legal form, registered address, and the entry in the home company register. Level two answers who owns whom. It records the direct parent and the ultimate parent where the entity reports them. Both levels are public and free to download.

Where does the LEI sit in an ISO 20022 payment message?

ISO 20022 gives it a dedicated element, so the code does not have to be squeezed into a name field. In a pacs.008 customer credit transfer, the debtor and the creditor each carry an organisation identification block, and the LEI is a named element inside it. The same holds for the debtor agent and the creditor agent. It holds again for the financial institutions in a pacs.009 interbank leg.

That placement matters more than it sounds. A structured element can be validated, indexed and matched. A name buried in four lines of address text can only be compared as a string. Swift's CBPR+ usage guidelines allow a party to be identified by LEI alongside its name and postal address. The Committee on Payments and Market Infrastructures, in its October 2023 final report on harmonised ISO 20022 data requirements for enhancing cross-border payments, treats a legal entity identifier as an acceptable way to identify a party.

What the standard does not do is make it mandatory. In most cross-border flows the element is optional. A receiving institution cannot assume it will be populated. Sending a code is a choice the sender makes, and asking for one is a choice the receiver makes at onboarding.

What does an LEI fix that a name and address cannot?

Four problems, and all of them are familiar. The first is the same company written four ways. A screening engine matching on name alone throws false positives on common words and misses transliterations. A code removes that ambiguity for the parties that have one.

The second is ownership. Level two data points at the parent, so a reviewer can open an ownership and control analysis from a public record rather than from a client questionnaire. The third is reconciliation. A treasury team matching incoming credits to expected counterparties can key on the code instead of a name the paying bank truncated.

The fourth is onboarding reuse. A code with current reference data gives you a verified legal name, legal form and registered address on day one. That is a starting point for know your business work. It is not a replacement for it, and it says nothing about what the client does or who controls it in practice.

An LEI is not a credential and it is not a clearance. It says a named legal entity exists and has kept its record current. Everything you then decide about that entity is still yours to decide, and still yours to evidence.

Does an LEI replace the Travel Rule and originator information?

No, and treating it as a substitute is the common mistake. FATF Recommendation 16 requires required and accurate originator information, and required beneficiary information, to travel with a transfer. For a legal person that means the name, the account number and an address or an equivalent identifier. An LEI is not on that list.

The honest reading is that the code supports those fields without meeting them. It makes the name verifiable and it settles which entity the name points at. It carries no account number and no natural person. A Travel Rule payload for a stablecoin transfer still has to be built from the underlying data.

Sanctions work behaves the same way. Lists are published against names, aliases and identifiers, and a code appears on some entries and not others. A match on a code is a strong hit. The absence of a code from a list entry proves nothing, so name and alias matching stays exactly where it is.

What does a lapsed LEI mean for a payment in flight?

An LEI never expires, but its reference data has to be revalidated every year. A record that is not renewed moves to lapsed status. The code still resolves and the history is still public. What has gone is the assurance that the name, the address and the parent are current.

That distinction decides what payment operations should do. A lapsed record is not a sanctions hit, and it is not a reason to reject a payment. It is a data quality finding. The right response is to refresh the client record, not to stop the money. Firms that wire lapsed status straight into a payment block tend to reverse the rule within a quarter.

Two other states are worth knowing. A record can be merged when entities combine, and retired when an entity ceases to exist. A retired code on an incoming payment is a question for the sender. It is not, by itself, a finding against your client.

How should a bank or MSB build the control?

The work is small and mostly done once. A workable sequence looks like this.

• Decide where a code is required and write it down. Every payout partner, every correspondent and corporate senders above a size you choose is a defensible starting policy. A small supplier with no code is then a documented exception rather than an argument.
• Capture the code at onboarding, validate the check digits on entry, and store it in its own field. A code inside a name line or a free text note is not a control.
• Pull the public reference data and compare it with what the client told you. A mismatch on legal name, legal form or registered address is a question to ask before the first payment, not after it.
• Populate the element when you send. Map the stored code into the organisation identification block of the pacs.008 or the pacs.009 so the receiving institution can actually use it.
• Read it when you receive. Where an inbound message carries a code, resolve it, store it against the counterparty and reconcile on it rather than on the name.
• Check status monthly. Treat lapsed as a refresh task with an owner and a date. Treat merged or retired as a client event that needs a review.
• Keep the policy, the exceptions and the monthly status run in one file. A reviewer asking how you know who your counterparties are wants to read that, not a screenshot of a lookup.

One decision is worth making deliberately. Requiring a code the client does not hold creates friction, because obtaining one means a registration and an annual fee paid to a Local Operating Unit. The Financial Stability Board's July 2022 report on options to improve adoption of the LEI, in particular for use in cross-border payments, pressed for wider take up rather than an immediate blanket mandate. A policy that requires a code where the counterparty almost certainly has one, and allows a recorded exception where it does not, holds up better than a rule that applies to everyone.

There is also a reason to want the code on the way in. A settlement leg that is final in minutes leaves no time to ask the sender who a party was. Resolving the counterparty before release is cheaper than reconstructing it afterwards.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. It is ISO 20022 native, generating pacs.008 customer credit transfers and pacs.009 interbank legs inside head.001 envelopes and tracked end to end by UETR, so the organisation identification block that carries a party code is part of the message the platform already builds rather than a field bolted onto it. KYB and KYC onboarding, KYT, sanctions and PEP screening, Travel Rule data under IVMS101 and a tamper evident audit trail sit in the same flow, and settlement in regulated stablecoins on public blockchains completes in minutes with on chain auditability. That combination is what makes resolving a counterparty before release practical rather than aspirational.