Three functions that are constantly confused
In the payment chain, identity covers everything an institution does to establish who its customer is, confirm that the account holder is the one acting, and check a specific fact about them. These steps happen at three different points, each governed by different law, carrying different risk, and served by different providers. Identifying a customer at account opening falls under anti-money laundering rules. Authenticating the account holder during a transaction falls under payment security. Verifying an attribute falls under a third regime, whether the check is on age, on address, or on the payee name for a credit transfer. A single national scheme often handles all three, but that does not make them interchangeable.
| Function | Question it answers | Applicable regime | What happens if it fails |
|---|---|---|---|
| Identification (KYC/CDD) | Who is this person, and is their identity genuine? | National AML law, FATF Recommendations | Account refused, or opened in breach of the rules and sanctioned by the regulator |
| Authentication (SCA) | Is the person acting really the account holder? | Payment security rules (PSD2 in the EEA, scheme rules, central bank requirements) | Transaction declined, or fraud liability shifted |
| Attribute verification | Is this specific attribute correct? | Sector-specific law: age, residence, authority to act, name–account match | Illegal sale, misdirected transfer, unenforceable mandate |
| Signature | Is this person making a legally binding commitment? | Trust services law (eIDAS in the EU, national equivalents elsewhere) | Contract, direct debit mandate, or consent open to challenge |
The cost of this confusion shows up at integration. A national ID chosen because it “does KYC” may not provide qualified signatures at all, which forces the institution to redo all its direct debit mandates. A successful authentication is not an age check either: the first confirms the account holder, the second verifies one attribute of their civil status. Identity providers charge per service, and the contract defines exactly what they attest to.
Aadhaar: e-KYC for a billion people
Aadhaar is a 12-digit identifier issued by the Unique Identification Authority of India (UIDAI). It is backed by biometric and demographic data and governed by the 2016 Aadhaar Act. India treats it as public infrastructure, just like a payment rail. A licensed institution queries UIDAI online and gets a response. The registry covers almost the entire adult population, and cumulative authentications since launch run into the hundreds of billions, a scale no other system comes close to.
The Reserve Bank of India’s Master Direction on Know Your Customer, issued on February 25, 2016, and updated on August 14, 2025, spells out exactly what e-KYC allows. An account opened with a one-time passcode alone remains capped: its aggregate balance cannot exceed ₹1 lakh, and total credits in a year cannot exceed ₹2 lakh. If full due diligence is not completed within a year, the account can no longer be used. The customer must also declare that they have not opened any other account this way.
The Video-based Customer Identification Process (V-CIP) is a remote identification procedure carried out through a video interview. The RBI standardized it so these limits can be lifted without a branch visit. Its requirements are more prescriptive than in most jurisdictions. The infrastructure must be hosted on the institution’s own premises, on a secure network, with end-to-end encryption between the customer’s device and the hosting site. The video recording carries GPS coordinates and a timestamp. Liveness and spoofing detection are mandatory, and the setup must pass penetration tests by auditors empaneled by CERT-In.
An Aadhaar number also works as a payment address. NPCI’s National Automated Clearing House, through the Aadhaar Payment Bridge System, delivers direct benefit transfers to hundreds of millions of recipients. Recipients are identified by their Aadhaar number instead of an account number, so the identity registry acts as a routing directory to the linked bank. No advanced economy has replicated this setup at anything like the same scale.
BankID and MitID: identity issued by banks
In the Nordic model, the national electronic ID is issued by banks and then used by both government and the private sector. That is the reverse of the usual sequence elsewhere, where the government rolls out an electronic ID and banks connect to it later. Residents use the same credential to file their taxes, sign a lease, approve a transfer, and enroll in a wallet. A new entrant in these markets cannot open a single customer account until it has integrated with it.
| Framework | Country | Operator | Since | Governance |
|---|---|---|---|---|
| BankID | Sweden | Finansiell ID-Teknik BID AB | 2003 | Fully private, owned by the banks |
| BankID Norge | Norway | Stø AS | 2004 | Owned by Norwegian banks. The same company owns BankAxept |
| MitID | Denmark | Digitaliseringsstyrelsen / Finans Danmark | 2021 | Joint public-private ownership. Replaced NemID; operated by Nets, then taken over by IN Groupe |
| Finnish Trust Network | Finland | Bank and telecom providers, supervised by Traficom | 2017 | Regulated market of providers and brokers, under Act 617/2009 |
Who owns these systems determines how well they align with domestic payment rails and how exposed they are to a change of ownership. In Norway, Stø AS owns both BankID and the domestic card scheme BankAxept, so identity and card acceptance share the same bank owners. That explains why the country’s resilience arrangements hang together so well. In Denmark, public co-ownership of MitID keeps identity out of reach of any infrastructure sale, whereas Dankort followed Nets all the way to Nexi. In Sweden, identity remains fully private, and reliance on a single provider is now a matter of public debate.
The Finnish Trust Network, set up in Finland in 2017 under the supervision of Traficom, creates a market for electronic identification rather than a single system. Banks and mobile operators issue the credentials, and brokers aggregate them and resell access to online services under a standard contract. A merchant that signs with one broker reaches every bank in the country through that single connection. The previous protocol, TUPAS, has been obsolete since September 30, 2019. Any integration documentation that still mentions it has not been updated in six years.
itsme, Smart-ID, and iDIN: three consortium models
An identity consortium is a joint venture of banks, often telecom operators, and sometimes the government, that runs a national electronic ID. Several European markets have chosen this middle ground between a state-issued ID and a purely bank-issued one. The three cases below share that structure but differ in who is liable for the attestation and which legal regime applies.
Smart-ID’s SplitKey architecture splits the signing key between the user’s device and the operator’s server. The PIN is not stored anywhere. It unlocks the device’s share locally, and that share alone cannot produce a signature. The server holds the other share and activates it only when the first one is presented. Compromising one side alone yields nothing usable. That property is what earned the system qualified signature status without any dedicated hardware on the user’s side.
eIDAS 2 and the European Digital Identity Wallet
Regulation (EU) 2024/1183 of April 11, 2024, published in the Official Journal on April 30, 2024, amends Regulation (EU) No 910/2014 to establish the European digital identity framework. It requires every member state to provide its residents with at least one European Digital Identity Wallet, built on common specifications. Some private companies will have to accept it. The regulation phases in the transition and sets the deadlines that go with it.
The deadlines run from the regulation’s implementing acts, not from the regulation itself. The first batch was adopted on November 28, 2024, published on December 4, 2024, and entered into force 20 days later. It includes Implementing Regulation (EU) 2024/2979, which covers the wallet’s integrity and core functions. Article 5a(1) then gives member states 24 months to provide a wallet. Article 5f(2) gives the private relying parties it covers 36 months to accept it.
Six large-scale pilot consortia are testing the specifications ahead of the deadline: POTENTIAL, NOBID, DC4EU, EWC, APTITUDE, and WEBUILD. They are funded by European Commission grants. Payments are among the use cases being tested, along with travel, education, driver’s licenses, public services, banking, telecoms, signatures, and organizational identities. What these pilots deliver will set the attestation formats actually implemented, which the regulation leaves open.
| Topic | Before | With the European wallet |
|---|---|---|
| Proof of identity at account opening | Scanned ID, document verification, or a national ID not recognized across borders | Electronic attestation of attributes presented by the holder, legally valid across the EU |
| Geographic reach | One contract per country with the local identity provider | Common specifications, and a single integration designed to work in all 27 member states |
| Data disclosure | The full identity record passes through the verification provider | Selective disclosure: the wallet attests the requested attribute without revealing anything else |
| Relying party status | Bilateral contract, no public registration | Relying parties must register and declare the attributes they request |
Singapore, Australia, Canada, Nigeria, and Latin America
Outside Europe and India, the identity systems that payments rely on fall into four groups. The first is state-issued identity exposed through APIs, with Singapore as the textbook case. The second is an identity broker tied to payment rails, the Australian and Canadian model. The third is a biometric bank identifier mandated by the central bank, the Nigerian model. The fourth reuses a tax or civil ID number as the key to opening an account, a very common practice in Latin America. None of these models carries over unchanged from one market to another.
In Latin America, account opening usually relies on the civil ID number residents already have. In Chile, a CuentaRUT account can be opened just by showing a national ID number, with no income requirement. BancoEstado has offered it since 2006, and it reported 15.5 million customers at its 20th anniversary. In Costa Rica, the central bank’s SINPE handles settlement, transfers, direct debits, check clearing, and digital identity services under one roof. The same combination of roles shows up outside the region in Bahrain, where BENEFIT runs the national switch, the Electronic Fund Transfer System, the credit bureau, and the country’s e-KYC.
Account opening: registry, document, liveness
Remote identity verification has to prove two separate things. The first is that the person claimed exists and that their civil status data is accurate. The second is that this same person is actually in front of the camera at the time of the request. Existence is checked by querying a registry or reading a document. Presence can only be established by a liveness check. A system that covers only one of the two leaves the attack vector for the other wide open.
| Method | What it proves | What it does not prove | Where it dominates |
|---|---|---|---|
| Registry lookup (Aadhaar, BVN, Singpass, Myinfo) | That the data matches an official record | That the applicant is the registered person, if the only factor is a code sent by SMS | India, Nigeria, Singapore, Bahrain |
| Reuse of online banking credentials (BankID, itsme, iDIN, ConnectID, Interac Verified) | That the bank has already completed due diligence and vouches for it | That the bank’s due diligence meets the relying party’s regulatory requirements | Nordic countries, Belgium, the Netherlands, Australia, Canada |
| Document verification and liveness detection | That the document is genuine and the person is physically present | That the document was not obtained fraudulently in the first place | Anywhere there is no registry to query |
Liveness detection covers the techniques used to confirm that a captured face belongs to a person who is physically present. It has to deal with two very different attack vectors that a standard video capture cannot tell apart. A presentation attack holds a screen, a photo, or a mask up to the lens, and it can be caught through image analysis. An injection attack replaces the camera feed with synthetic video before it reaches the sensor. No image analysis can catch it, because the feed that arrives is perfectly clean. Detecting it requires an integrity attestation for the device and the channel. Many products sold as “anti-deepfake” only cover the first vector.
The last hurdle in multi-country projects is making due diligence portable across borders. No due diligence record is automatically valid across a border. A customer verified in Nigeria with their BVN is not verified in Ghana, and a Swedish customer authenticated with BankID is not identified in Denmark. The European wallet is built precisely to make this portable within the EU, which is what sets it apart from earlier systems. Everywhere else, verification has to be redone in each jurisdiction, at a cost.
Strong authentication built on national identity
Strong authentication is defined the same way everywhere: at least two independent factors drawn from knowledge, possession, and inherence. In the European Economic Area, the rule comes from Article 97 of PSD2 and Delegated Regulation (EU) 2018/389. Where a trusted national electronic ID exists, banks do not build a second system. They delegate SCA to that ID. The customer then uses the same app to log in to the tax portal and to approve a payment.
Dynamic linking ties the authentication proof to the amount and the payee of the transaction in progress. Strong authentication for a payment therefore proves two things: that the account holder is present, and exactly what transaction they are approving. A system that only shows a generic login confirmation screen, without the amount, does not meet this requirement. The Nordic and Baltic electronic IDs display the transaction details in the app, which makes them usable for payments as is.
Payee verification applies the same identity requirement to the recipient of the funds. In the euro area, Regulation (EU) 2024/886 has required it for euro credit transfers since October 9, 2025. The name the payer enters is checked against the actual holder of the receiving account, and the payer is warned before confirming. The mechanism is a tool against credit transfer fraud, not an AML requirement. It shifts the identity question from the customer to the recipient of the funds.
What breaks, and what to negotiate
Identity integration projects fail for a handful of reasons, which recur from one market to the next in a fairly consistent order. They are rarely technical. Most of the problems come from the license the applicant needs, the contract terms, and the exact scope of what the provider attests to.
| Symptom | Root cause | What should have been done |
|---|---|---|
| The project slips by several months before the first request | Access to the identity provider requires an authorization or a license, not an API key | Treat getting the identity contract as a critical-path dependency from the scoping stage |
| Direct debit mandates are challenged | The system used authenticates but does not produce a signature valid under local law | Check authentication, signature, and the assurance level separately |
| Conversion collapses in one country | The flow requires a national ID that nonresidents do not have | Offer foreign buyers an alternative, document-based path |
| An outage looks like a performance drop | Authentication failures do not distinguish a customer decline from a provider outage | Log failure causes by code, and track provider uptime separately |
| The compliance submission is rejected | Recognized, qualified, and notified schemes are confused | Get the provider to state in writing the exact legal regime of each service you sign up for |
| An account is opened but cannot be used | The light onboarding flow opens a capped account with no path to the next tier | Design the upgrade path to full due diligence at the same time as the entry tier |
- Map the identity layer before the payment rail. You can switch rails, but not the national identity provider.
- Separate the four services in the contract: identification, authentication, attribute verification, and signature. They are priced separately, and the provider’s liability differs for each.
- Use an identity broker when several providers coexist in a country (Finland, Australia), unless your volume justifies direct integrations.
- Require dynamic linking from any system used to authenticate a payment: the amount and the payee must appear in the identity app.
- Treat liveness detection as two problems: presentation attacks in front of the lens, and feed injection before the camera. The second requires a device integrity attestation.
- Track the eIDAS 2 timeline by implementing act, not by the date of the base regulation. The implementing acts start the 24- and 36-month clocks.
- Never assume due diligence carries across borders unless a specific regime says so. A customer verified in one country is just a prospect in the next.