You verified them in Berlin. Now prove it in Singapore.

A person can be verified to the highest standard a regulator recognises, and cross one border, and be a stranger again. The reason is not that the formats are incompatible. The formats are converging nicely. The reason is that no institution has agreed whose word to take, and that is a governance problem wearing a technical costume.

Meera has been verified nine times in fourteen months.

Twice in Bengaluru, when she opened a salary account and later a brokerage account. Once when a Dutch client onboarded her as a contractor and needed to satisfy their own anti money laundering obligations. Once by the payroll intermediary that same client used, which is a different company with a different vendor. Twice more in Berlin, after the relocation: the bank, then the mobile operator, who wanted the passport again because the bank's confirmation letter was not something they could act on. Once by a landlord's agency. Once by a coworking operator with a badge system. And once, most recently, by a Singapore brokerage that wants her business and cannot accept a single artifact from any of the eight verifications that came before.

Every one of those checks was competent. Several were excellent. The Berlin bank ran a video identification session against a live agent, checked the passport's machine readable zone, confirmed the chip, and satisfied a supervisory standard that most of the world would consider strong. That verification is now approximately six months old, it is sitting in that bank's records, and it is worth precisely nothing to the brokerage in Singapore. Not because the brokerage doubts German banks. Because the brokerage has no way to receive the fact, no legal basis on which to rely on it, and no method of confirming that the person filling in the form today is the person the German bank looked at in March.

So Meera uploads her passport for the ninth time, holds it next to her face for the ninth time, and waits three days.

Why does a verification done in Germany not count in Singapore?

There is a comfortable assumption, common among engineers who have not worked inside a compliance function, that this is a plumbing problem. Different countries use different file formats and different signature algorithms, and if everyone would just adopt one standard the problem would dissolve. It is a reasonable assumption. It is also wrong, and the way it is wrong is the single most useful thing to understand about cross border identity.

Break the failure into its parts. When the Singapore brokerage receives some artifact asserting that a German bank verified Meera in March, it has to answer four separate questions before it can act.

Can I read this? That is the format question. It is the easy one, and it is the one the standards bodies have spent fifteen years solving. It is close to solved.

Is it authentic? That is the cryptography question. Did the entity that claims to have signed this actually sign it, and has it been altered since. Also close to solved, given a way to obtain the right public key.

Do I accept this issuer? That is the governance question. There are tens of thousands of institutions in the world capable of issuing an identity assertion. The Singapore brokerage has a relationship with none of them. It has no list, no accreditation scheme that spans jurisdictions, and no way to distinguish a German bank subject to serious supervision from a shell company in a permissive jurisdiction that will attest to anything for forty euros. Nothing in the format helps here at all.

May I rely on it? That is the regulatory question, and it is the one that stops the conversation. A regulated firm carries the obligation itself. If it accepts a third party's verification and that verification turns out to be wrong, the firm is answerable, not the third party. Regulators in most jurisdictions permit some form of reliance on third parties, under conditions, with the liability staying put. A compliance officer weighing a small reduction in onboarding cost against personal and corporate liability for a bad customer will re verify, every time, and be right to.

Notice the shape. Questions one and two are technical and are being solved well. Questions three and four are institutional and are barely being addressed outside of single jurisdictions. A perfect format delivered into a world with no answer to question three is a beautifully addressed envelope with nowhere to send it.

The cost of answering the same question nine times

It is difficult to put a defensible global number on repeated verification, and this piece is not going to invent one. Published per customer onboarding cost estimates vary enormously by sector, jurisdiction and methodology, and the widely circulated figures tend to be vendor produced with unstated assumptions, so treat any single number you see with suspicion, including ones that flatter this argument.

What can be said with confidence is structural. Every regulated relationship a person forms triggers its own verification. Every product within an institution can trigger another. Every jurisdiction adds a layer. A multinational bank operating in twenty markets runs twenty variants of the same process with different vendors, different document libraries, different retention rules and different audit trails, and maintains all of it. The cost is not one line item, which is exactly why it survives: it is distributed across vendor contracts, compliance headcount, engineering maintenance, and the customers who abandon the process partway through and are recorded as a conversion problem rather than an identity problem.

The consumer side is measurable in at least one place. When the United Kingdom's Online Safety Act age assurance duties took effect in July 2025, Ofcom's first statutory report on age assurance, published in July 2026, found more than 69 million age checks completed across a sample of 32 regulated services in the second half of 2025 alone. Almost none of those checks produced anything the person could carry to the next service. The same humans proved the same fact to different companies, tens of millions of times, and kept nothing. That duplication is the consumer face of the same failure, examined in how to verify age without collecting an ID.

What actually travels today, and what does not?

The prior art here is serious, and anyone arguing about cross border identity without engaging with it properly is not worth listening to. Four bodies of work matter, and each one solves a real part of the problem.

eIDAS 2.0 and the European Digital Identity Wallet

Regulation (EU) 2024/1183, in force since May 2024, amends the original eIDAS framework and obliges every one of the 27 member states to make an EU Digital Identity Wallet available to citizens and residents, with the regulation setting a deadline at the end of 2026 and acceptance obligations on large platforms and regulated sectors phasing in afterwards. It is the most ambitious coordinated identity programme in a generation, backed by an Architecture and Reference Framework that specifies the technical shape in detail.

It is genuinely important and it deserves to succeed. It is also, by construction, a European answer. The wallet carries attestations issued by European authorities under European law and derives its trust from European supervisory structures. A Singapore brokerage receiving an EU wallet presentation is exactly where our earlier questions leave it: it can read the presentation, it can verify the signature if it can obtain the trust anchors, and it still has to decide, on its own, as a private firm outside the European legal order, whether to accept it and whether its own regulator will let it. eIDAS answers questions one and two brilliantly for Europeans and does not attempt question four outside the union, because it cannot.

ISO 18013-5 and the mobile driving licence

ISO/IEC 18013-5 specifies the mobile driving licence, and it contains an idea that deserves more attention than it gets: a well designed offline presentation model. A verifier can check an mDL presentation without contacting the issuing authority, which matters enormously because the alternative, calling home on every check, hands the issuer a log of everywhere the holder goes. The standard also supports selective release of individual data elements, so a bar can learn that the holder is over the legal age without receiving an address.

It is deployed in a growing number of US states and accepted at some airport checkpoints. It is a driving licence, which means it is issued by a subnational authority, which means the acceptance question is fractal: a verifier in one state has to decide about issuers in forty nine others before it even reaches a border. That is not a criticism of the standard. It is an illustration that the hard part sits above the standard.

W3C Verifiable Credentials, SD-JWT and the presentation protocols

The W3C Verifiable Credentials data model gives a general shape for an issuer to make a signed statement about a subject that a verifier can check. Selective Disclosure JWT, developed at the IETF, provides a compact and pragmatic way to issue a credential from which the holder can reveal individual claims later without revealing the rest, an idea covered in more depth in what is selective disclosure. OpenID for Verifiable Presentations gives a protocol for requesting and delivering them, and the emerging browser level Digital Credentials API aims to make presentation something a web page can request without a bespoke integration.

This stack is the closest thing to a universal format the field has, and it is progressing quickly. Every part of it is about expression and exchange. The specifications are careful to say, correctly, that deciding which issuers to trust is out of scope. That sentence appears in some form in nearly every credential specification ever written, and it is the sentence this entire article is about. For how this family of standards compares with a receipt based approach, see Manav and W3C Verifiable Credentials and the plain English primer in self sovereign identity without the crypto headache.

Aadhaar and the deployed reality of population scale verification

India's Aadhaar system is the largest deployed identity infrastructure of its kind, and it has demonstrated something the rest of the field mostly theorises about: that verification at population scale can be made cheap enough to change the economics of financial inclusion. It also supports offline verification modes that let a person share a signed extract of their record without the relying party querying the central system in real time.

It is also, precisely, a national system. It serves residents of one country, under one legal framework, with the political settlement that framework required, which was and remains contested domestically in ways worth taking seriously. Its offline KYC extract is not a thing a Dutch client can meaningfully evaluate. Meera's Aadhaar based verification, whatever its quality, did not travel with her.

FATF and the rules that decide what a bank may accept

Sitting above all the technology is the Financial Action Task Force, whose guidance on digital identity shapes how national regulators think about whether a firm may rely on a digital identity system, and under what conditions. FATF's framing is assurance based: firms should understand the assurance level of the identity system they rely on, and reliance is permitted where the system is appropriately reliable and independent. That is a sensible position, and it is also an invitation to a question nobody has answered at scale, which is how a firm in one country determines the assurance level of a system in another.

What is a trust registry, and why is it the real bottleneck?

Here is the analogy. Imagine every restaurant in the world agreed on a single format for a gift voucher: same paper size, same layout, same tamper proof printing, same signature block. Beautiful. Universal. Now walk into a restaurant in Lisbon holding a voucher issued by a restaurant in Osaka. The Lisbon restaurant can read it perfectly. It can confirm the signature is a real signature. And it will not give you dinner, because it has no idea whether that Osaka restaurant exists, whether it honours its vouchers, whether it will settle up, or whether the whole thing is a scheme. What is missing is not the voucher format. What is missing is a list of restaurants that have agreed to honour each other's vouchers, and a settlement arrangement behind it.

That list is a trust registry. In identity, a trust registry is the machine readable answer to question three: which issuers do I accept, for which claim types, at which assurance level, as of when. It sounds administrative. It is the entire problem.

The reason it is hard is not that lists are difficult to publish. It is that a registry encodes a set of decisions that nobody wants to own. Who admits an issuer? On what criteria? Who audits? Who removes an issuer that fails, and how fast does removal propagate to verifiers who cached the list? Who is liable when a listed issuer turns out to have been negligent? Each of those questions has been answered before, inside single jurisdictions and single sectors. Card networks answered them for payments over decades, with rulebooks and arbitration and member liability. Certificate authorities answered them for the web, and the answer required browser vendors to act as de facto regulators, remove authorities that misbehaved, and absorb the political consequences.

Both of those took a long time and both required someone with enough concentrated power to enforce a rulebook. Cross border identity has no equivalent actor, and the closest candidates, governments, are precisely the parties least able to bind each other.

The thesis, stated plainly

Formats interoperate long before institutions agree whose attestations they will accept. That gap, between technical readiness and institutional agreement, is where cross border identity actually lives, and it is a governance problem wearing a technical costume. Every year that the field spends refining the costume without addressing the governance is a year of excellent specifications and unchanged onboarding queues.

Is this just an argument for a national identity system?

No, and this deserves a careful answer rather than a rhetorical one, because readers hold genuinely different and genuinely defensible views here.

Some countries have population scale identity systems that work well and command broad public support. Estonia is the standard example, India is the largest, and several others operate schemes their citizens use daily without controversy. Arguing that such systems cannot work is empirically silly.

Other countries have decided, repeatedly and through legitimate democratic processes, that they will not have one. The United Kingdom abandoned an identity card scheme. The United States has no national identity document and shows no sign of wanting one, which is why the mDL effort runs through state licensing authorities. In several countries the objection is rooted in specific historical experience of registries being used against populations, and it is not a preference to be engineered around.

The design consequence is simple and constraining. Any infrastructure that requires a national identity system to function is not a global answer. It is a national answer, valuable inside its borders, unavailable outside them. Since the whole problem here is what happens at the border, that rules out the approach by definition.

The same logic cuts against the opposite fantasy, which is a single global identity provider. Nobody is going to accept one, no jurisdiction would permit it, and concentrating that much of humanity's identity data in one place would be a spectacularly bad idea even if everyone did.

What remains, once both of those are excluded, is an approach where the person carries the evidence and the verifier checks it without needing a relationship with the issuer. Not because that is elegant, but because it is the only shape left standing.

What does a human carried receipt actually add?

Start with what it does not add. It does not create legal reliance, it does not accredit issuers, and it does not make a Singapore regulator accept a German bank's judgement. Anyone claiming otherwise is selling something.

What it adds is three specific properties that the current arrangement lacks, and it is worth being precise about each.

The verifier does not have to call anyone

A receipt is a signed statement that verifies against a published key. The verifier fetches the key once, caches it, and checks signatures locally afterwards. No call to the issuer, no call to us, no availability coupling, and critically no disclosure to the issuer of where the holder is presenting. That last property is the one that killed real time revocation checking in web browsers, and it is the reason ISO 18013-5 built offline presentation in deliberately. The full history of that tradeoff is worked through in can you verify a credential without phoning the issuer. The privacy argument and the resilience argument point the same way, which is rare and worth exploiting.

The evidence moves without the underlying data moving

A receipt asserts that a check of a stated kind happened, to a stated standard, at a stated time, by a stated party. It does not need to carry the passport image, the video session, or the document library match scores. That distinction matters legally as well as technically: moving a signed assertion about a check across a border is a materially different act, under most data protection regimes, from moving the underlying biometric and document data. For a multinational trying to reduce what crosses jurisdictions, this is not a side benefit, it is often the main one.

The person presenting today is bound to the proof

This is the part that credential formats consistently leave open, and it is the part that has become urgent. A verifiable credential proves an issuer said something about a subject. It does not prove that the human operating the browser right now is that subject. Holder binding mechanisms exist in the specifications, and they are typically key based, which means they prove possession of a key rather than presence of a person. Given how cheap synthetic video and injected camera feeds have become, a proof of key possession and a proof of a live human are no longer the same thing, and any cross border design that conflates them is building on 2019 assumptions. The mechanics of that shift are set out in the camera is no longer evidence.

A presence signature closes that specific gap: at the moment of presentation, the human confirms on an enrolled device, and the resulting assertion is bound to the presentation. What the verifier gets is not just a carried credential but a carried credential plus a fresh statement that the enrolled human is here, now, presenting it deliberately.

What that looks like on the wire

Here is the shape of a carried verification receipt. It is deliberately dull. Dull is the security property.

{
  "typ": "manav.receipt.verification.v1",
  "sub": "hk_9f2c...",              // one-way subject key, not an identity
  "check": {
    "kind": "kyc.identity_document",
    "standard": "eu.aml.cdd.enhanced",
    "performed_by": "iss:de-bank-4417",
    "performed_at": "2026-03-14T09:22:11Z",
    "expires_at": "2027-03-14T00:00:00Z"
  },
  "presence": {
    "signed_at": "2026-09-11T04:18:52Z",
    "method": "passkey+liveness",
    "nonce": "5d1a...c7"            // verifier-supplied, prevents replay
  },
  "sig": "ed25519:..."
}

Read it as three claims stacked. A German institution performed an identity document check to a named standard on a named date. The subject of that check is identified by a one way key rather than a name or a document number. And the holder of that subject key proved presence just now, against a nonce the Singapore verifier supplied a few seconds ago, which is what stops the whole object from being replayed by someone who copied it.

The verification is unremarkable, which is the point:

pub = fetch_once("https://issuer.example/.well-known/manav-keys")

def accept(receipt, my_nonce, policy):
    assert verify_ed25519(pub[receipt.sig.kid], receipt)   # authentic
    assert receipt.presence.nonce == my_nonce              # fresh, not replayed
    assert now() < receipt.check.expires_at                # not stale
    assert receipt.check.performed_by in policy.accepted_issuers  # governance
    assert receipt.check.standard in policy.accepted_standards    # assurance
    return True

Look at the last two lines. Four of the six checks are cryptography and can be done by anyone, anywhere, offline, forever. Two of them are a policy object that somebody has to populate, and populating it is the governance work that no format can do for you. That honest asymmetry is the whole lesson, and it is why the code is worth printing.

How do the cross border models compare?

Four broad approaches exist, and they trade off differently. None dominates.

The bottom row is not magic. Its honest claim is narrow: it removes the technical and privacy obstacles cleanly, so that what remains is the governance question by itself, where it can be argued about openly instead of being hidden inside vendor integrations. That is a smaller claim than the field usually makes and a more defensible one.

What this cannot do

Five limits, stated plainly, because a piece arguing that everyone else overclaims does not get to overclaim.

Legal reliance is not a cryptographic property. A perfect signature does not discharge a regulated firm's obligation to know its customer. If a supervisor says a firm must perform its own check, the firm must perform its own check, and a receipt is at best supporting evidence and a reduction in the work, not a replacement for the duty.

The registry problem does not disappear, it relocates. Making verification offline and issuer neutral removes the technical coupling. Somebody still has to decide which issuers count. This piece argues that separating that decision from the plumbing is progress, not that the decision goes away.

A receipt is only as good as the check behind it. If an issuer performs a weak check and attests to it accurately, the receipt faithfully conveys a weak check. Assurance levels have to be expressed and honoured, and issuers who misrepresent them have to be removed, which is the registry problem again wearing a different hat.

Some people have no issuer at all. Refugees, stateless people, and populations in jurisdictions with poor civil registration cannot carry a receipt from an institution that never verified them. Any design that only improves life for the already documented has solved the easier half of the problem and should say so.

Selective disclosure at Manav is not shipped. The architecture described here uses offline verifiable receipts and presence signatures, which exist today. Selective disclosure using SD-JWT, zero knowledge predicates, and issuer trust list distribution are proposed work, not shipped features. Where this article describes the target architecture rather than current capability, it is arguing a design, and it should be read that way. Interoperating with eIDAS attestations would require a bridge that does not exist yet.

What to do this week

Concrete steps, for the person who has to make progress before the standards settle.

1. Count your repeats. For one product line, count how many times the same customer is verified across your own organisation. Most firms discover the duplication is internal before it is international, and internal duplication is fixable without anyone's permission.
2. Write down your acceptance policy as data, not prose. Even if it currently contains one entry, which is "ourselves". A policy object with issuers and assurance levels is the thing a future registry plugs into, and producing it forces the governance conversation into the open.
3. Separate the check from the evidence of the check. Most systems store the passport image and treat it as the record. Start emitting a signed, minimal assertion about each check you perform, alongside your existing storage. It costs little and it is the artifact everything else needs.
4. Add presence to presentation, not just possession. Wherever you accept a credential, ask what proves the holder is present rather than merely holding a key. If the answer is nothing, that is your deepfake exposure, and it is unrelated to which credential format you chose.
5. Read the eIDAS Architecture and Reference Framework if you operate in or sell into Europe. The 2026 and 2027 obligations are not distant, and the acceptance requirements will land on product teams, not only on compliance.
6. Ask your KYC vendor what happens to a verification when the customer leaves. The answer tells you whether you are buying a check or renting a hostage. It is a fair question and the response is informative.
7. Stop treating abandoned onboarding as a conversion problem. Instrument where people drop out of verification. In most consumer products the document upload step is the cliff, and every repeat of it is a cost you are paying for the absence of portability.

If you want to see what presence bound presentation feels like before designing around it, the walk up demo runs the enrolment and presence flow in a browser with no signup, and the developer documentation covers the receipt format and offline verification.

Frequently asked questions

Can a KYC verification done in one country be reused in another? Rarely today, and only where a specific legal reliance arrangement exists between the parties. Technically it becomes possible when the proof is issuer independent, verifiable offline against a published key, carried by the person rather than sent between institutions, and presented with a fresh presence signature. Even then the relying party's regulator decides whether reliance is permitted, so the technical work removes the obstacles without removing the duty.

Will the EU Digital Identity Wallet work outside the EU? A non EU verifier can technically read and cryptographically check an EU wallet presentation if it obtains the trust anchors. Whether it should accept it is a separate question that eIDAS does not answer, because the regulation binds member states and EU relying parties rather than firms in other jurisdictions. Expect strong acceptance inside the union from 2027 and ad hoc, firm by firm decisions outside it.

What is reusable KYC? Reusable KYC is the idea that an identity verification performed once can be presented to other institutions instead of being repeated. Today it mostly exists inside closed vendor networks, where the vendor performs the check and its other customers accept it under contract. The open version, where any institution can accept any competent issuer's check, requires an issuer trust registry that does not yet exist across borders.

What is a trust registry in digital identity? A trust registry is a machine readable list stating which issuers a verifier accepts, for which types of claim, at which assurance level, and as of when. It answers the question that credential formats deliberately leave out of scope. Building one requires deciding admission criteria, auditing, removal procedures and liability allocation, which is why it is a governance problem rather than an engineering one.

Does an mDL or a verifiable credential prove the person presenting it is the right person? Not on its own. It proves an issuer made a statement about a subject and, with holder binding, that the presenter controls the subject's key. Key control and human presence diverged once synthetic video and injected camera feeds became cheap. Adding a live presence signature at the moment of presentation is what closes that gap, and it is separate from the credential format.

Why not just put identity on a blockchain? A distributed ledger does not answer either hard question. It does not tell a verifier which issuers to accept, and it does not establish legal reliance. It also makes the privacy position worse by publishing correlatable material, and a signature verified against a published key already gives you offline verification without any of that. The unsolved parts are institutional, and no consensus mechanism has an opinion about them.

Sources

1. Regulation (EU) 2024/1183 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. eur-lex.europa.eu
2. European Commission, EU Digital Identity Wallet programme and Architecture and Reference Framework. ec.europa.eu
3. ISO/IEC 18013-5, Personal identification, ISO compliant driving licence, mobile driving licence application. iso.org
4. W3C Verifiable Credentials Data Model 2.0. w3.org
5. IETF, Selective Disclosure for JWTs (SD-JWT). datatracker.ietf.org
6. OpenID Foundation, OpenID for Verifiable Presentations. openid.net
7. Financial Action Task Force, Guidance on Digital Identity. fatf-gafi.org
8. Unique Identification Authority of India, Aadhaar offline verification. uidai.gov.in
9. Ofcom, report on age assurance under the Online Safety Act, July 2026. ofcom.org.uk
10. W3C, Digital Credentials API. w3.org

Formats interoperate long before institutions agree whose attestations they will accept, and no specification has ever fixed a governance problem by being better written.