How to Choose a System for Remote Customer Identity Verification: 7 Selection Criteria

Remote identity verification system is a SaaS service that allows a company to confirm a customer's identity without his physical presence - over the Internet, in real time. The customer goes through the process from his or her phone or computer; the company receives the result, along with evidence to prove his or her identity.

It sounds simple. The problem is that the market for these solutions is not homogeneous, and the differences between vendors are not obvious at the demo stage - they only become apparent after implementation. One system supports three verification methods, another eight. One keeps data in Poland, another in a global cloud. One integrates in a week, with another IT spends three months mapping out edge cases.

This article helps you put together a list of requirements before you start talking to vendors. Seven criteria, specific questions for each.

Key findings

• An identity verification system (for KYC) is no ordinary SaaS tool - it touches regulation (AML, eIDAS, RODO), sensitive data and a process critical to onboarding. A selection error is costly to fix.
• Verification methods vary in the level of certainty of identity. Before evaluating bids, determine the required level of assurance from regulations or your own risk analysis.
• Compliance with eIDAS is not required always - but if your process requires a high level of assurance or legal implications, it is a prerequisite.
• Vendor lock-in in KYC comes into play when a vendor change requires full re-invention. Choosing a platform that aggregates multiple vendors through a single API eliminates this problem.
• The per-verification price from the offering is not the total cost - IT integration, maintenance, support and eventual migration add to the TCO.
• The UX of the verification path on the end-customer side has a direct impact on completion rate in onboarding. Always test on real users before purchase.
• Piloting on real data before signing an annual contract is standard - a vendor that refuses to do so is a warning sign.
  
  

What makes an identity verification system different from a typical B2B SaaS tool?

A customer identity verification system is different - and harder to replace than a typical operational tool - for three specific reasons.

First, it touches sensitive personal data and is subject to regulation - the AML Act, eIDAS, RODO, and often sector requirements (FSA, insurance regulations). A bad choice is not only an operational problem, but a potential regulatory risk.

Second, the result of verification is legal evidence. The identification report may end up in a case file, regulator's audit or legal proceedings. The quality and integrity of this document matter.

Third, the verification system is deeply woven into the customer onboarding process. Changing vendors involves technical reintegration, a change in the user path and, if no one has taken care of the right architecture at implementation, the risk of downtime.

Therefore, choosing a vendor for remote identity verification (for KYC procedures) is a decision worth taking the time to analyze before signing a contract.

7 criteria for selecting a system for customer identity verification

1. Available verification methods and their levels of assurance

Not every verification method gives the same level of assurance about identity. A selfie with a document is different from cryptographically reading an NFC chip from an e-card. Each method has different technical requirements on the client side, different process time and different cost.

Questions for the vendor:

• What methods are available - video verification, e-card, e-banking, mCitizen, qualified signature?
• What level of assurance (low, medium, high according to eIDAS) is assigned to each method?
• Can a method be matched to a specific process or customer segment?
• Are the methods independent of each other, or do they require a bundled purchase?

A practical starting point: first determine the required level of assurance for your process - this comes from regulations or your own risk analysis. Only then check whether the system offers methods that meet this level.

For a detailed comparison of methods available on the Polish market, see the article Customer identity verification methods: requirements, instructions and which method to choose.

2. Regulatory compliance and certifications

Compliance Manager has one key question when evaluating any supplier: "Will I be able to defend this choice to the regulator?" The answer does not lie in the supplier's declarations - it lies in the specific documents and data architecture.

Questions for the vendor:

• Is the platform compliant with eIDAS and the Polish AML Act of 2018?
• Where is the data physically stored - in Poland, in the EU, outside the EU?
• What certifications does the provider have (ISO 27001, SOC 2, other)?
• Does the verification report include an audit trail - who verified, when, by what methods, what result?
• Is the report in a legally effective form (e.g., bearing a qualified seal)?

Autenti eID in this area operates in full compliance with eIDAS and RODO - data is processed and stored in Europe. Verification reports are secured with Autenti's qualified electronic seal, which gives them evidentiary power in the event of a dispute or audit.

Example from practice: Grenke Polska, implementing AML-compliant remote leasing onboarding, points out explicitly that remote customer identification "minimizes the company's risks" - precisely because each verification ends with a documented report. It's worth asking the vendor what such a report looks like and whether you can see it before signing the contract.

3. Integration model and vendor lock-in risk

This criterion is most often overlooked at the selection stage - and most often becomes a problem after implementation.

Vendor lock-in in the context of KYC is that changing a verification vendor or adding a new method requires IT to re-integrate fully. If you've integrated directly with a particular biometrics provider and that provider raises prices, suspends service or drops out of your market - you're stuck or paying for re-integration.

Questions for the provider:

• Is the integration done through a single API that gives you access to multiple methods and providers?
• Does adding a new verification method require a new technical integration?
• What happens to verifications when one of the sub-suppliers (e.g., a biometrics provider) has a fallback? Is there an automatic fallback?
• Is the API versioned and what is the support policy for older versions?

Autenti eID solves this problem through a hub model - integration with a single API gives access to multiple verification providers (Identt, Veridas, Authologic, among others). If one fails, the system can be switched to the next without client-side intervention.

4. UX of the verification path on the end customer side

A good system is not just what you see in the admin panel. More important is what the customer sees during verification - and how many of them complete the process.

Companies often buy a system looking only at features and regulatory compliance. They ignore the UX. The result: conversion in the onboarding process drops, customers abandon the application halfway through, support gets "verification doesn't work" notifications.

Questions for the vendor:

• How many steps does verification take for the end customer?
• Does it work on mobile devices without installing the app?
• What is the average verification completion time?
• Does the vendor provide completion rate data on deployments to other customers?
• Is the interface visually customizable (white label, custom colors, logo)?

One test worth more than an hour demo: ask for a sandbox and do the verification yourself on your phone. Ideally, ask a few outsiders - people who don't know how the system works.

By comparison, BNP Paribas Leasing Solutions, after implementing remote verification, achieved identification completion times of tens of seconds - with requirements reduced to an ID card and a camera. Verification is available 24/7 without an employee on the company's side. Michal Porycki, managing director of TS at BNP Paribas Leasing Solutions, comments: "Automated identity verification solutions speed up the process considerably and increase customer satisfaction."

For its part , MHC Mobility - a company that manages a fleet of more than 13,500 vehicles in the CEE region - has collected 90% positive feedback from customers on its new signing process with identity verification after implementation. That's a number worth demanding from a vendor when evaluating offers: what are the actual completion rate and satisfaction scores with customers similar to your company?

5. SLAs, availability and incident handling

Identity verification is often a critical path in onboarding. A peak-hour outage means lost requests, upset customers and pressure on the operations department.

Questions for the vendor:

• What is the guaranteed system availability level (SLA) - 99.9%? 99,95%? 99,99%?
• What is the response time to a critical incident? What does escalation look like?
• Does the vendor publish availability history (status page)?
• What is the procedure for reporting problems - email, dedicated support, Slack?

99.9% uptime is 8.7 hours of unavailability per year. 99.99% is 52 minutes. In high-volume processes, this is a difference that matters - it's worth translating it into numbers before signing a contract.

6. Pricing model and total cost of ownership

The per-verification price that a vendor quotes is often only part of the actual cost. The rest comes out at implementation or at the first invoice.

Questions for the supplier:

• What is the billing model - per-verification, subscription, mixed model?
• Does the price include all verification methods, or is each billed separately?
• Are there additional fees for implementation, technical support, training?
• How does the price change with volume growth - linear, degressive, threshold?
• Are there fees for storing reports and data?

When comparing bids, it's a good idea to calculate TCO (total cost of ownership) for 12 and 24 months - including IT integration time, any additional licenses and support cost.

7. Implementation support and documentation

Integration time depends largely on the quality of documentation and availability of support on the vendor's side. A poorly documented API can turn a 2-week integration into a 2-month debugging edge case.

Questions for the vendor:

• Is the API documentation public and up-to-date?
• Is a test environment (sandbox) available before signing a contract?
• What is the average time to first call for the new integration?
• Who is on the vendor's side during implementation - dedicated engineer, general support, on their own with documentation?
• Does the vendor offer a pilot on real data before full implementation?
  
  

What to look for with specific industries

The criteria are universal, but their importance depends on the industry.

Finance and leasing - AML and FSA regulations are the strictest here. The criterion of regulatory compliance and audit trail is of paramount importance. Often a high level of identity assurance is required, limiting the available methods to e-card, e-banking or qualified signatures.

E-commerce and marketplaces - verification volume is high and customer tolerance for friction in the process is low. UX and completion rate matter most here. Per-verification costs at high volumes strongly affect economics.

HR and remote hiring - processes are less regulated than in finance, but there is growing pressure to verify the identity of candidates hired remotely. Matching methods to different countries is key if the company is recruiting outside Poland.

Hiring and sharing economy - high user turnover and fraud risk. What matters is the speed of the process on the client side and the ability to re-verify without reintegration.

When to start with a pilot rather than a full implementation

If the volume of verification in your company is still unknown or the onboarding process is just being designed - a pilot before full integration makes sense.

Piloting allows you to verify three things that you can't assess from a demo: actual completion rate on your customers, system behavior with edge cases specific to your process, and real API response times under load.

A good vendor will allow piloting on real data with limited scope. If a vendor refuses to sandbox or pilot before signing an annual contract - that's a signal.

The most common mistakes when choosing an identity verification system

1. Choosing by price on single verification. The cheapest per-verification option may be the most expensive when considering integration, maintenance and eventual migration costs. It's the TCO that counts, not the bid price.
2. No UX testing on the part of the end customer. Decisions are made in the boardroom based on demos for buyers - not for those who will undergo verification. The result: lower completion rate than expected, higher acquisition cost, dissatisfied customers at the registration stage.
3. Overlooking vendor lock-in issues. Direct integration with a single biometrics or document provider looks simple at first. The problem arises when the vendor changes pricing, reduces availability or goes out of business. Then the cost of the change is the same as the cost of a new implementation.
4. Underestimation of audit requirements. The system meets regulatory requirements "on paper," but the verification reports are not in legally effective form, there are no timestamps, and there are no details about the method and result. At the first audit or dispute, this is a problem that can't be fixed quickly.

For more on mistakes throughout the KYC process:  5 most common mistakes in the KYC process and how to avoid them.

Frequently asked questions

What is the difference between an identity verification system and an identity verification service provider?

It is the company that offers the service - it can be an online platform, API integration or an "on site" model. A verification system is the specific software that a customer's identification path goes through. Some providers offer their own biometric engines, some aggregate methods from multiple sources through a single API. When choosing, it's important to understand whether you're buying direct access to a verification method or to an orchestration layer that manages multiple methods.

How much does it cost to implement a system for remote identity verification?

The cost depends on the methods you choose, the volume of verification and the billing model. A typical model is a per-verification fee (from a few to a few tens of zlotys, depending on the method and provider) plus an optional implementation or subscription fee. IT integration time, possible maintenance and support costs should be added to the total cost.

Does an identity verification system need to be eIDAS compliant?

Not every process requires eIDAS compliance - it depends on the required level of assurance and sector regulations. The obligation stems from specific regulations: the AML Act imposes it on mandatory institutions, EU directives - on financial market entities. However, if your process requires a high level of certainty of identity or legal effect (e.g., signing a contract), eIDAS compliance is a prerequisite.

How long does it take to implement a system for remote identity verification?

Not every implementation requires API integration. Some identity verification systems work through an online panel - in such a time-to-market model it is a few hours from service setup, without IT involvement. With integration via API - with good documentation and dedicated support - the time ranges from a few days (proof of concept or MVP) to a few weeks (full integration with backoffice systems and onboarding path). The main variable is the complexity of the technical environment on the client side: the number of systems to connect, the data model, the interface requirements. The verification system itself is rarely the bottleneck.

What is vendor lock-in in the context of remote identity verification systems and how to avoid it?

Vendor lock-in in occurs when a change of verification vendor requires a full technical re-invention - a new API, new tests, new process certifications. It is avoided by choosing a platform that aggregates multiple vendors through a single API. In such an architecture, changing or adding a verification method does not require a new integration - just a configuration change.

What regulations should be invoked to justify the choice of a KYC system within an organization?

In Poland, the key acts are the Anti-Money Laundering and Countering Financing of Terrorism (AML) Act of 2018, the eIDAS Regulation (EU 910/2014), RODO, and sector regulations (EU directives for banks, insurers, investment companies). When arguing internally, it is worth pointing to the specific article imposing the verification obligation and showing that the chosen system meets the requirements for the level of assurance and audit trail.

Next step

If you are at the stage of evaluating remote identity verification solutions and want to compare your requirements with what the market offers, arrange a free consultation with an Autenti expert. We'll help you lay out your list of requirements and evaluate your options - regardless of whether you ultimately choose Autenti.