A customer signs up to a new account at nine in the evening. They want to move money or open a wallet. Before any of that, they have to prove who they are. The next sixty seconds decide whether they finish or close the tab. That window is what identity verification software has to handle, and it is where onboarding revenue is most often lost.
For the team building the flow, the decision sits a layer up. You are choosing a piece of software and an integration that has to satisfy two readers at once: the compliance lead who needs the check to stand up under the Money Laundering Regulations, and the customer who just wants to be let in. Get the selection right and both are served. Get it wrong and you either fail an audit or lose the sign-up.
This page covers what identity verification software does, how an API fits into a KYC flow, the integration choices in front of you, and the criteria worth scoring providers against before you commit engineering time.
Identity verification software confirms a person is who they claim to be during onboarding or know your customer (KYC) checks. It gathers evidence about their identity, checks that the evidence is genuine and valid, confirms it belongs to the person presenting it, and returns a verified result with an evidence trail. Modern services deliver this through an application programming interface (API) and run several methods behind one integration.
The work breaks into five jobs, set out in the UK government’s Good Practice Guide 45 (GPG45). Get evidence of the claimed identity, then check that evidence is genuine and valid. Confirm the identity has existed over time and is at low risk of fraud. Last, confirm it belongs to the person presenting it. Software automates those jobs so the result comes back in seconds rather than days.
An identity verification API connects your onboarding to a verification service. Your product sends a request, the service runs its checks, and it returns a pass or fail with verified attributes and supporting evidence. The API handles the identification and verification step that the Money Laundering Regulations require, while your firm keeps responsibility for the wider customer due diligence around it.
In practice the call sits at the point in your sign-up where you need to know the person is real before you grant access or move money. The response gives your systems a clear, machine-readable result to act on, plus the record you will want if a regulator ever asks how the check was done. Behind the single call, the service can run more than one method to reach a decision.
There are three integration patterns. Hosted sends the user to a provider-run flow and returns them to you with a result, which is the fastest to ship. Embedded keeps the flow inside your own product using an API and software development kits (SDKs), giving you more control over look and feel. Orchestration sits above both, routing each user across methods by rule from a single integration.
Most providers offer a REST API, web and mobile SDKs, and drop-in components, so you can mix patterns by journey. A hosted redirect might handle a low-volume back-office flow while an embedded SDK carries your main consumer sign-up. The pattern you choose sets your engineering effort, the degree of control you keep over the experience, and how quickly you reach production.
For the person being verified, the integration pattern is the difference between a few taps inside the app they already trust and a jarring bounce to an unfamiliar page. That gap shows up directly in completion rates, so it is an experience decision as much as a technical one.
GPG45 sets four levels of confidence in a verified identity: low, medium, high and very high. The level is the assurance level you need, chosen from your service’s own risk assessment. The higher the risk that someone could impersonate a customer or commit identity fraud, the higher the level you set. Most regulated onboarding sits at medium, and good software lets you set the level per use case.
A current-account opening and a low-risk newsletter sign-up do not need the same level of confidence, and paying for the highest level everywhere wastes money and adds friction. The point of choosing a level deliberately is that you match the strength of the check to the risk of the journey. Software that lets you configure this, rather than forcing one fixed standard, keeps both your compliance and your completion rates where you want them.
Judge a provider on seven things: certification and the level of confidence each method meets, the methods it offers and who they cover, completion and drop-off, how it handles data under UK GDPR, the audit trail it produces, how long it takes to integrate, and whether a verified identity can be reused. The table below turns each into a question to ask and the reason it matters.
|
Criterion |
What to ask |
Why it matters |
|
Certification and level of confidence |
Is the provider certified and on the register, and what GPG45 level of confidence does each method meet? |
Only a certified, registered digital verification service reliably supports the Regulation 28 identity step under the Money Laundering Regulations; uncertified services cannot (gov.uk, 26 Feb 2026). |
|
Methods and coverage |
Which methods does it run, and which customers do they cover? |
A single method fails some users. Bank-verified identity draws on near-universal current-account holding (FCA Financial Lives 2024). |
|
Completion and drop-off |
What share of users finish, and what happens to those who fail? |
Abandoned verification is lost revenue, not just a failed check. |
|
Data handling under UK GDPR |
What is collected, retained and shared, and is it minimised? |
Data minimisation is required under UK GDPR Article 5(1)(c); biometric data used to identify a person is special category data under Article 9 (ICO). |
|
Audit trail |
Does each check produce a verifiable evidence trail? |
Firms must be able to evidence their checks, and ongoing monitoring remains the firm’s own duty. |
|
Time to integrate |
How good are the API, SDKs and docs, and which integration patterns are supported? |
This sets your speed to production and your engineering cost. |
|
Reusable identity and orchestration |
Can a verified identity be reused, and can methods be routed from one build? |
Reuse cuts repeat-check friction, and orchestration raises coverage and completion. |
Score every provider on the same seven and the shortlist usually sorts itself.
A KYC API automates the identity checks that sit inside customer due diligence. Under the Money Laundering Regulations, a firm can meet its Regulation 28 identity-verification duty using a certified, registered digital verification service. The API returns verified attributes and evidence, while the firm keeps responsibility for its risk assessment, the purpose and nature of the relationship, and ongoing monitoring.
The distinction matters when an audit comes around. The government’s February 2026 guidance on using digital identities with the Money Laundering Regulations makes clear that the framework draws on GPG45 and that uncertified services cannot reliably be deemed suitable for this purpose. A certified service gives you defensible evidence for the identity step. The rest of the due diligence stays your job, which is why the audit trail the API produces is worth scoring carefully.
The cost of getting verification wrong is not abstract. In July 2025 the Financial Conduct Authority fined Barclays a combined £42m over failings in financial crime risk management, including weaknesses in the information gathered at the start of customer relationships and in ongoing monitoring. The identity step is one input into that wider duty, and a weak one is expensive to carry.
Reusable identity lets a returning customer verify once and reuse the result, instead of repeating a full check every time. Orchestration runs several methods from one integration and picks the route per user, so a customer one method cannot verify is offered another. Together they lift completion and cut the cost of journeys that would otherwise be abandoned.
This is where it helps to name a provider. OneID is a certified digital verification services provider in the UK, and the first Orchestration Service Provider under the trust framework. A single API runs bank-verified identity, document scanning, and digital wallet or international eID credentials, then routes each customer to a method that works for them. Verified identities can be reused, so a returning customer is recognised rather than re-checked.
For the person at the other end, that is the difference between a passport upload that fails on the third attempt and a tap that confirms them in seconds. The completion uplift that follows is a commercial number as much as an experience one, and it is the part of the verification decision that most directly touches revenue.
If you are sizing the trade-off, the cost of verification and the cost of drop-off are worth modelling side by side before you choose. Both come down to how many customers finish, and that is set by the software and integration you pick here.
Identity verification software confirms a person is who they claim to be during onboarding or KYC. It gathers identity evidence, checks the evidence is genuine and valid, confirms it belongs to the person, and returns a verified result with an evidence trail. It runs these checks through an API, usually across several methods.
They overlap. An identity verification API confirms who a person is and returns verified attributes. A KYC API does the same job inside a regulated due-diligence context, supporting the Regulation 28 identity-verification step under the Money Laundering Regulations. The firm keeps responsibility for risk assessment, purpose and ongoing monitoring around it.
You have three patterns. A hosted flow sends the user to a provider-run page and returns a result, which ships fastest. An embedded integration keeps the flow in your product using an API and SDKs, for more control. Orchestration routes users across methods from one build. Most providers support all three.
GPG45 sets four levels of confidence: low, medium, high and very high. You choose from your own risk assessment, setting a higher level where the risk of identity fraud is higher. Most regulated onboarding and right-to-work checks sit at medium. Software that lets you set the level per use case is worth preferring.
Yes, with a caveat. Under the Money Laundering Regulations, a firm can meet its Regulation 28 identity-verification duty using a certified, registered digital verification service (gov.uk, 26 February 2026). Uncertified services cannot reliably be relied on. The service covers the identity step; your firm keeps responsibility for the rest of customer due diligence.
Score providers on seven criteria: certification and the GPG45 level of confidence each method meets, methods and coverage, completion and drop-off, data handling under UK GDPR, the audit trail, time to integrate, and whether identity can be reused. Use the same questions across every provider so the comparison is fair.
Reusable identity verification lets a customer who has already proved their identity reuse that result, instead of repeating a full check. Because it removes a repeated step, it reduces the friction that causes returning customers to abandon onboarding. Paired with orchestration across methods, it widens coverage and lifts completion.
For the person on the sign-up screen, the politics of the under-16 plans are invisible. What they meet i...
For a parent, the proposal is easy to picture. The account a fourteen-year-old might open on a Saturday ...
An electronic signature proves a document was signed. On its own, it does not prove who signed it. A fre...