How do you choose identity verification methods for each country? | Trust Infrastructure Explained

Key takeaways

• Verifying a user requires at least a first name, a last name and a unique number. Sometimes the law specifies the number (for example, an identity document number); sometimes the business can use another unique element of the available data.
• In cross-border authentication, a notified eID always transmits the current last name, first names, date of birth and a unique identifier. Address is optional in the eIDAS minimum data set, while the AMLR requires obliged entities to establish a customer’s usual place of residence.
• In the EUDI Wallet, the “document number” in the person identification data (PID) is the number of the PID itself. It is not the number of an identity card or passport.
• When the method users prefer in a country does not return the full data set, it can stay on the list. Missing data can come from another source or, where the law allows it, be collected at a later stage or accepted as a user declaration.
• Popularity at a given moment is a weak criterion on its own. A safer start is a simple proof of concept (POC) on generic solutions, followed by investment in the methods that work for the business’s own users.

Where do you start when choosing identity verification methods for a country?

Choosing methods starts with the business’s constraints. Businesses entering a new market often ask first for the most popular and easiest method.

The most popular method does not always meet the business’s needs. It may not be notified under eIDAS, or it may not return the full set of required data.

Before choosing a method, the business needs to answer 3 questions:

1. Which regulations apply to the business in that country?
2. What does its compliance team expect?
3. Which data does it need after verification, and at what level of assurance?

The answers show whether a method that is popular with users fits the business’s process.

A method that misses some requirements does not drop off the list straight away. The gaps can sometimes be closed with documentation describing how the method works, or with an additional, independent check of part of the data, carried out by the verification provider or by the business itself.

What data does a regulated business need?

The scope of data depends on the regulations that apply to the business. To verify a user effectively, it needs at least a first name, a last name and a unique number.

Sometimes the law specifies the number directly, for example an identity document number. In other cases the business has more freedom and can use another unique element of the available data as the unique number.

Obliged entities in the EU will apply the AMLR from 10 July 2027. Article 22(1)(a) AMLR lists the information an obliged entity obtains for a customer who is a natural person: all names and surnames, place and full date of birth, nationalities (or statelessness and refugee or subsidiary protection status, where applicable), the national identification number, where applicable, the usual place of residence and, where available, the tax identification number.

How this data is to be collected and verified remotely will be set by AMLA’s regulatory technical standards on customer due diligence (CDD RTS). AMLA submitted the draft to the European Commission on 1 October 2026, and it does not apply yet. What the draft changes is explained in How to verify customers remotely under AMLR.

Businesses outside the scope of the AMLR, such as online retailers checking age, usually need a much narrower data set. The data minimisation principle in Article 5(1)(c) GDPR requires personal data to be limited to what is necessary for the purpose of processing.

What data do eIDs and the EUDI Wallet return?

In cross-border authentication, eIDs notified in the EU transmit at least the minimum data set defined in Implementing Regulation (EU) 2015/1501. For a natural person, the mandatory attributes are the current family name, current first names, date of birth and a unique identifier. The optional attributes are first names and family name at birth, place of birth, current address and gender.

Address and nationality are therefore attributes a notified eID does not have to transmit in this data set. National versions of the same methods may return a broader or narrower data set.

If a method does not return data the business needs, the business has to obtain it from another source. The draft CDD RTS provides that an attribute an eID does not provide is obtained and verified by other means.

The EUDI Wallet presents person identification data (PID) as defined in Implementing Regulation (EU) 2024/2977. The mandatory PID attributes are family name, given name, birth date, birth place and nationality. Resident address and the personal administrative number (such as a national identification number) are optional, and each Member State decides whether to include them.

The “document number” in the PID is a number the PID provider assigns to the PID itself. It is not the number of an identity card or passport. If the law requires an identity document number, the EUDI Wallet may not provide it.

AMLR data requirements compared with eID and EUDI Wallet data

The table shows the legal frameworks. Specific methods may return more data than the minimum data set requires.

Bank-based identification methods (bank IDs) return a data set defined by the bank or the scheme they operate in, with no common EU standard. The same type of method can therefore return different data in 2 countries.

Assurance levels (low, substantial, high) are explained in the EUDI Wallet & eIDAS 2.0 Glossary, part 4. Other eIDAS terms used in this article are defined in the Digital Identity Glossary.

Where do several methods return an equivalent data set, and where is there only one?

The European verification market is fragmented. In many countries, several equivalent methods operate side by side: government eIDs, bank IDs and identity wallet apps.

For a business, this means a series of separate integrations. For users, it means a choice, and users have their own habits about which method they use. How many people actually use each method is shown in the eID Adoption Race H1 2026 report.

The table below gives examples from Authologic’s list of methods by country.

Examples of electronic identification methods in selected countries

The table covers selected electronic identification methods marked as supported on Authologic’s list, without EUDI Wallets, which are still being rolled out. Method types follow the categories used on that list. Document verification and biometrics are also available in each of these countries. The assurance level of each method is shown in the list of methods by country.

Outside Europe, the only available method is often a biometric check or a check against a government database. Digitalisation is reaching every market, though, so the market will become more complex and users more demanding about the method they want to verify with.

Several methods returning comparable data in one country also provide a backup route. When one method or its provider stops working, the user can complete verification with another method. How this works is explained in What happens when an identity verification provider goes down?

What do you do when a method does not return all the data you need?

When users in a country prefer a method that does not return the full data set, the business needs to ask 3 questions:

1. Does it really need such a broad data set, or is part of the data collected “just in case”?
2. Does all the data have to be provided at the same moment?
3. Can part of the data be collected as a user declaration?

The answers make it possible to build the solution from several elements. The most common are:

• a second method or a document check for data the first method does not return (for example, address);
• collecting part of the data at a later stage of the relationship, where the law does not rule this out;
• a user declaration for data the law does not require the business to verify.

How do you handle countries with their own digital ecosystems, such as China and India?

The biggest challenge comes from countries with extensive, closed digital ecosystems, such as China and India. Methods in these countries are closely tied to local infrastructure and rarely have equivalents among global solutions.

In these countries, 2 needs have to be reconciled. The business usually expects one solution for everything, while the market requires connections specific to that country.

An orchestration platform can use completely different connections for one country than for all the others, without changing the business’s integration. Routing and orchestration are defined in the Identity Orchestration Glossary.

What mistakes do businesses make most often when choosing methods?

Mistake 1: choosing a method only because it is popular

A business entering a market is often ready to invest heavily in integrating the method that is popular at that moment. This can be a dead end for 3 reasons:

1. The method may not meet regulatory requirements.
2. It may soon lose popularity.
3. It may not appeal to the niche in which the business operates.

Mistake 2: collecting data “just in case”

Requiring a broader data set than necessary narrows the list of methods that return it and can lower conversion in the verification process.

Mistake 3: investing in a full integration before seeing the data

A safer start is a less demanding integration: a simple proof of concept (POC) on generic solutions. Based on the statistics, the business can then invest in refining the process for the methods that actually work for its users. How to avoid rebuilding the process when adding the EUDI Wallet is explained in The simplest way to implement the EUDI Wallet.

How does Authologic choose methods with its customers?

Customers often come to Authologic without full knowledge of verification in a given country. In the first conversation, the Authologic team establishes the business’s constraints: which regulations apply, what its compliance team expects and which data it needs. Only then does it select the methods.

Authologic and the customer share one goal: an effective solution. Not every element of that solution has to sit with Authologic, but Authologic is a partner in discussing and analysing which route works best.

Behind a single Authologic API sits a network of aliases and redirects. This makes it possible to use completely different connections for a selected country than for all the others.

Depending on its needs and how much control it wants, a customer can choose individual connections to specific methods or a generic, global solution in which Authologic manages the details and availability of the methods.

Authologic usually proposes starting with a simple POC on generic solutions. After observing the statistics, the customer invests in refining the process for the methods that work for its users. Authologic provides 150+ identity methods in 250+ countries and territories.

What should you ask a provider before choosing methods for a country?

1. Which methods in my countries return the data set I need, and which data does none of them return?
2. What level of assurance does each method operate at, and is it notified under eIDAS?
3. How will I fill in missing data (for example, address), and can I do it in the same process?
4. Is there more than 1 method returning comparable data in a given country, and can I add methods without changing my integration?
5. Can I start with a generic solution and later narrow it down to the methods that work for my users?
6. Which success and drop-off statistics will I get per method and per country?

Which certifications and test reports to ask the same provider for is covered in Which certifications should an identity verification provider hold in the EU?

FAQ

Is one verification method enough in a country?

Sometimes, but rarely for long. In many European countries, several equivalent methods operate side by side, and users have their own habits. A second method returning comparable data also provides a backup route when the first one stops working.

Does an eID return the user’s address?

Not always. In the eIDAS minimum data set (Implementing Regulation (EU) 2015/1501), current address is an optional attribute, as is resident address in the EUDI Wallet PID. If a business needs the address and the method does not return it, the business has to obtain it from another source.

Will the EUDI Wallet return an identity card number?

Not necessarily. The “document number” in the PID is a number the PID provider assigns to the PID itself, and it is not the number of an identity document. The personal administrative number is an optional PID attribute, included at the Member State’s discretion.

Does a verification method have to be notified under eIDAS?

It depends on the regulations that apply to the business. Article 22(6) AMLR recognises 2 routes for identity verification: an identity document and, where relevant, information from reliable and independent sources, or electronic identification means at assurance level substantial or high and the relevant qualified trust services. The provision refers to the assurance level and does not mention notification directly. What this means for KYC processes is explained in the briefing How Will the EUDI Wallet Change KYC?

Does all user data have to be collected at once?

Not always. Part of the data can be collected at a later stage of the customer relationship, where the regulations that apply to the business do not rule this out. Splitting collection this way makes it possible to use the method users prefer, even if it does not return the full data set at once. Under the AMLR, obliged entities verify the customer’s identity before establishing a business relationship. Article 23 AMLR allows verification to be completed later only in limited cases, for example where a lower risk justifies postponement, or where this is necessary so as not to interrupt the normal conduct of business and there is little risk of money laundering or terrorist financing.

Sources

• Regulation (EU) 2024/1624 (AMLR), Article 22.
• Commission Implementing Regulation (EU) 2015/1501, Annex: minimum data set.
• Commission Implementing Regulation (EU) 2024/2977 on person identification data and electronic attestations of attributes issued to European Digital Identity Wallets.
• Regulation (EU) 2016/679 (GDPR), Article 5(1)(c).
• Authologic, list of methods by country.