Last updated: October 2026

The best identity verification software for a financial institution is the one that covers the documents and applicants the institution actually sees, shows how it fails, can be backed up by a second provider, and hands its result to the decision with the reasons attached. No single provider is best for every institution, because document mix, applicant base and fraud pressure differ from one to the next. The reliable way to choose is to test each candidate on your own past applications, including known fraud, before you sign.

This guide sets out eight criteria for choosing among identity verification providers, each with the question to ask, what a weak answer sounds like and how to test it, followed by a test plan and a scorecard. Oscilar wrote this guide. Oscilar is not an identity verification provider, and the criteria name no provider.

TL;DR

• No identity verification software is best in general. Judge each provider on its fit to your documents, your applicants and your fraud.

• Identity verification shows that an identity matches its evidence. It does not show that the applicant means well, so the result should feed the onboarding decision rather than be the decision.

• Ask how a provider fails, and not only how often it passes, and whether you can fall back to a second provider when it fails.

• The bank Customer Identification Program (CIP) rule, 31 CFR 1020.220, lets a bank verify identity with documents, non-documentary methods or both, and its non-documentary procedures must address applicants who cannot present a photo ID.

• Test every candidate on your own past applications, including confirmed fraud and genuine customers who failed verification.

• Oscilar orchestrates identity verification providers and does not verify documents itself. A later section applies the same criteria to Oscilar.

The short answer: how to choose identity verification software

Choose the identity verification software that fits your applicants and fails in ways you can see and handle. In practice, the best identity verification software for a bank or fintech meets five tests:

• Coverage: it reads the documents your applicants actually present, and you have a route for applicants who have no acceptable document.

• Failure handling: it tells a poor image from an unrecognized document from a forged one, and returns the reason.

• Fallback: you can send a failed check to a second provider without rebuilding your rules.

• Decision: its result reaches your onboarding decision with the reasons attached, next to device, behavioral and other signals.

• Proof: it holds up when you run your own past applications through it, including known fraud, before you sign.

Identity verification answers a narrower question than the one an institution has to decide. A KYC check confirms that a claimed identity exists and matches its documents at a moment in time. It does not establish intent, and it does not establish that the identity was not assembled specifically to pass the check. Deciding what to do with an applicant who passes is a separate job, and the criteria below treat the identity verification result as one input to that decision.

Identity verification software is usually one part of a larger purchase. For the layer that calls every identity check and makes the onboarding decision, read our guide to the best onboarding software for banks.

What identity verification software checks

Identity verification software checks that an applicant is a real person and the person they claim to be. Most identity verification solutions combine some of four checks:

• Document capture and authenticity: capturing an image of an identity document, such as a driver's license or passport, and checking that it is genuine, current and unaltered.

• Selfie match and liveness: comparing a selfie with the photo on the document, and checking that a live person is in front of the camera rather than a printed photo, a mask or a video.

• Database and electronic identity checks: checking the applicant's name, date of birth, address and identification number against authoritative or credible data sources, with no document involved.

• The hand-off to watchlist screening: passing the verified identity on to sanctions and watchlist screening, which institutions often run as a separate step.

NIST's identity proofing guideline gives a useful way to sort these checks. NIST SP 800-63A-4, published in final form in July 2025, splits identity proofing into identity resolution, evidence validation (whether the documents presented are genuine, accurate and current), attribute validation (whether the applicant's core details check out against authoritative or credible sources) and identity verification (whether the applicant is the person the evidence describes). The guideline is written for US federal agencies and does not bind banks, but it maps well onto what providers sell: a document check covers evidence validation and verification, and a database check covers attribute validation.

For a bank, the CIP rule sets the frame. Under 31 CFR 1020.220(a)(2)(ii), a bank's verification procedures must describe when the bank will use documents, non-documentary methods, or a combination of both. Non-documentary methods include independently verifying identity by comparing the customer's information with information from a consumer reporting agency, a public database or another source. Document checks and database checks catch different problems, so the difference between document and database verification is worth settling before you compare providers on either.

The eight criteria, and how to use them

The eight criteria follow an applicant through verification: what the provider can check, how it fails, what happens when it fails, where its result goes, what else the decision needs, how it handles forged evidence, what record it keeps, and what it costs to change your mind. Each criterion has the same three parts: the question to ask a provider, what a weak answer sounds like, and how to test the answer on your own applications.

The criteria are disclosed so you can weigh them for yourself, and this guide names and ranks no identity verification vendors. A ranking would tell you which product suited someone else's applicants. Put the same questions to every provider in writing, and test each answer on your own applications rather than on demonstration data.

1. It covers your documents and your applicants

Coverage only matters for the documents your applicants actually carry. List the identity documents presented in a recent sample of your applications, by document type and issuing country, and ask each provider to confirm support for every one of them, including the uncommon ones.

Coverage also means a route for applicants a document check cannot serve. Under 31 CFR 1020.220(a)(2)(ii)(B)(2), a bank's non-documentary procedures must address situations where an individual cannot present an unexpired government-issued photo ID, the bank is not familiar with the documents presented, the account is opened without obtaining documents, the customer opens the account without appearing in person, and other circumstances that increase the risk that the bank cannot verify identity through documents. ID verification software that only reads documents leaves those applicants to a manual process, so ask how the provider, or a second provider, covers them with database checks.

What to ask: Which of the documents our applicants present do you support, and how do you verify an applicant who has no acceptable document?

What a weak answer sounds like: A headline count of supported documents or countries, with no breakdown against the documents your applicants present.

How to test it: Run a sample that matches your real document mix, including the less common documents, and record each document the provider could not read.

2. It shows you how it fails, not only how often it passes

A pass rate tells you how often a check succeeded. It does not tell you why the rest failed. A failed document check can mean a blurred image, a genuine document the provider does not recognize, or a forged document, and each calls for a different response: ask the applicant to retake the photo, send the check to another provider, or refer or decline the application.

A provider that returns only pass or fail pushes all three cases into the same queue, and the queue is usually manual review. A chief compliance officer at a fintech put the goal plainly: "we would like to not be manually reviewing documents when we have a vendor that can do it." Ask what the provider returns on a failure, and whether a reviewer could act on it without opening the image.

Some failures can be prevented before the check runs. A software engineer at the same fintech wanted real-time feedback before an image is sent to the verification provider, such as flagging a passport photo that does not show all four corners. Capture guidance of that kind turns a failed check into a retake the applicant can fix on the spot.

What to ask: What do you return when a check fails, and how do you separate a poor image, an unrecognized document and a suspected forgery?

What a weak answer sounds like: A pass rate with no breakdown of failures, or a single failure code for every case.

How to test it: Include known poor-quality captures and known forgeries in your sample, and check whether the provider's failure reasons tell them apart.

3. You can fall back to another provider

No single provider reads every document or finds every applicant in its data, and any provider can have an outage. Fallback means sending a check that one provider could not complete to a second provider, in an order you set. A product lead for merchant verification at a payments company described the design many teams are after: "use the first best provider and then if it fails, fall back to the other one."

Fallback is only practical if your rules are not wired into one provider's integration. A director of fraud and deposit risk at a bank described the cost of that kind of lock-in: "when you have to put all the rules in place and build an integration platform that's just for [a provider], switching it over, isn't just swapping out a vendor, there's more to it than that." Keeping your decision rules outside any single provider's integration is what lets you add, reorder or replace a provider later.

What to ask: Can a second provider sit behind you in our flow, and what do you return that would let us route a failed check to it?

What a weak answer sounds like: A provider that expects to be the only one, or whose rules and thresholds can only be set inside its own platform.

How to test it: In the test flow, force a failure on the first provider and confirm the check reaches the second one, with both results recorded.

4. Its result reaches your decision, with the reasons

An identity verification result is one signal in an onboarding decision, and it is most useful when it arrives with its reasons. A useful response says what was checked, what the result was and why: which field did not match, which document feature failed, or which data source had no record of the applicant. A decision engine and a reviewer can both act on a response like that, and neither can do much with a bare pass or fail.

A document check used as the answer to every doubtful application becomes the one control fraudsters learn to beat. The same director of fraud and deposit risk described replacing manual review of uncertain applications with a document step-up: "we step you up to [a provider], we make you do either a driver's license or a passport to confirm who you are. We have been beat with that." A VP of operations who owns enterprise fraud at a tax-preparation and financial services company said the team steps applicants it is unsure about up to an ID scan, and that the scan had become a safety net used "in far too many places."

What to ask: What does your response contain, field by field, and can our decision logic read it without a person opening your console?

What a weak answer sounds like: Pass or fail only, or a single score with no reasons attached.

How to test it: For a handful of passed and failed applications in your sample, check whether the response alone tells a reviewer why the provider reached its result.

5. It works alongside signals beyond identity verification

An identity can be real-looking, pass every check and still be fake or misused. A synthetic identity combines real and invented details and can be assembled specifically to pass document and database checks. Evaluating that risk is its own exercise, covered in our guide to synthetic identity fraud detection software.

The signals that catch what identity verification misses sit around the check rather than inside it: the device the applicant uses, how they behave while filling in the application, and links between this application and others that share a device or details. Those are the device and behavioral signals at account opening that an onboarding decision should weigh next to the identity verification result. The provider's job is to return its result in a form that can be combined with them.

What to ask: What identifiers and metadata do you return, so that your result can be linked to our device, behavioral and application data?

What a weak answer sounds like: A provider that presents its check as the whole onboarding decision.

How to test it: Include applications later linked to fraud rings in your sample, and see how many of them passed identity verification on its own.

6. It stands up to forged and AI-generated evidence

Forged and generated documents and selfies are part of the threat every identity verification platform now faces. FinCEN's alert on fraud schemes using deepfake media, FIN-2024-Alert004 (November 2024), lists red flags that include identity documents that are inconsistent with each other, and a customer photo that is inconsistent with other identifying information, such as a date of birth that does not match the applicant's apparent age. Those are consistency checks, and a provider should be able to say which of them it runs.

Ask how the provider compares the document with the selfie, with the application data and with any other documents the applicant submits. Injected video, liveness and deepfake detection are a deeper evaluation, set out in our guide to evaluating deepfake detection tools.

What to ask: Which consistency checks do you run across the document, the selfie and the application data, and what do you return when they disagree?

What a weak answer sounds like: A general statement that the product uses AI to detect fakes, with no account of what it checks.

How to test it: Include applications with known inconsistencies between documents, photo and application data, and record which ones the provider flags.

7. It keeps the record you will be asked for

A bank's CIP procedures say when it uses documents, non-documentary methods or both, so the identity verification output has to show which method was used for each applicant. A useful record shows, per applicant, which checks ran, with which provider, what came back, when, and what was decided as a result. Aggregate pass rates on a dashboard do not answer a question about one customer.

Ask where that record lives and for how long. A record held only in the provider's logs, available on request, is harder to produce and may not survive the end of the contract.

What to ask: Can we pull the full record of one past applicant's verification ourselves, and keep it after our contract ends?

What a weak answer sounds like: A dashboard of rates, with per-applicant records only on request.

How to test it: Pull the records for a handful of applicants in your sample and follow each one from the check to the decision.

8. It fits your contracts and the cost of changing your mind

Adding an identity verification provider takes longer than the integration. A consumer fraud strategy lead at a telecom said that onboarding a new data vendor is a long process: contract, legal, privacy and security reviews, and then a proof of value. Plan those steps into the evaluation rather than discovering them after the shortlist.

Price the exit as well as the entry. The cost of leaving a provider sits in the rules, thresholds and integrations built around it, which is the lock-in criterion 3 describes. Ask about data ownership, how long images and results are retained, how retries and fallback checks are charged, and what notice either side must give.

What to ask: What happens to our data and our configuration if we add a second provider or leave?

What a weak answer sounds like: An entry price, with the exit left for later.

How to test it: During the proof of value, swap the provider out of the test flow and record everything else that had to change.

How to test an identity verification provider on your own applications

The test that separates identity verification providers is a replay of your own past applications, run the same way through every candidate. A senior KYC team lead at a property-management software company said any evaluation would have to run on their actual applicants, including records already confirmed fraudulent, because those are the cases they want to see a provider catch. Run the test within your privacy and consent terms for the data you use.

1. Build a sample that matches your real mix: approved customers, declined applications, confirmed fraud, and the less common documents your applicants present.

2. Include genuine customers who failed verification: they show whether a provider's failures cost you good customers.

3. Run the same sample through every candidate: same applications, same order, same capture conditions where possible.

4. Compare failure reasons, not only pass rates: sort each provider's failures into poor captures, unrecognized documents and suspected fraud.

5. Force a failure to test fallback: switch the first provider off in the test flow and confirm a second one completes the check.

6. Pull the records: for a handful of applicants, follow the record from check to decision.

Weigh the results on your two hardest groups: confirmed fraud the provider passed, and genuine customers it failed.

Where Oscilar fits, judged on the same criteria

Oscilar wrote this guide, so this section applies the eight criteria to Oscilar using only what Oscilar's published pages state. Oscilar is not an identity verification provider. It does not verify documents, match selfies or run liveness checks itself. It is the decision and orchestration layer around the identity verification providers an institution chooses, and it uses third-party providers for those checks.

On coverage and fallback (criteria 1 and 3), the page on orchestrating identity checks in consumer onboarding describes how Oscilar can "Orchestrate KYC checks and enhanced identity checks for a true 360° view of each applicant", connect an institution's own databases, and connect third-party data sources through a partner marketplace. Coverage therefore depends on the providers an institution connects. Ask Oscilar to build the fallback you need into your test flow, as you would ask any candidate.

On the decision and the signals around it (criteria 4 and 5), Oscilar offers "Step-Up Verifications: Trigger enhanced due diligence and additional verification steps when it's needed" and onboarding workflows "that adapt to each user's risk profile". It adds device intelligence, behavioral biometrics and data enrichments to identity checks, and combines rules, supervised machine learning and unsupervised anomaly detection. Its case management explains in natural language why each case was created, and the platform is specified for sub-100ms decisions.

On forged and AI-generated evidence (criterion 6), document authenticity, liveness and deepfake detection come from the identity verification providers Oscilar orchestrates. Oscilar's role is to combine their results with device and behavioral signals in the decision.

On the record (criterion 7), Oscilar keeps a full audit trail per decision with stored reasoning, and human-in-the-loop by design. A risk team can backtest a workflow on historical data, run A/B tests, and monitor false positives, approval rates and its own KPIs. Oscilar also has auto model monitoring covering data drift, feature drift and concept drift, plus outcome KPIs measured by segment.

On contracts and switching (criterion 8), Oscilar is one platform across onboarding, credit, fraud and AML. Test the switching cost directly: swap one provider in the test flow and see what else has to change.

Oscilar was named to Chartis's 2026 FCC50, its ranking of financial crime and compliance technology vendors, with category wins for Low-Code/No-Code Customization and Agentic AI Innovation. That is not a ranking of identity verification software, and it does not replace running the test above on Oscilar with the same sample as every other candidate.

The eight criteria at a glance

The table pairs each criterion with the question that tests it, the answer that should give you pause, and the test to run on your own applications. Fill it in once for each provider on your shortlist.

Use the second column as the script for every provider conversation, and the last column as the test plan.

Frequently asked questions

Does identity verification software need to check a document every time?

No. Under the bank CIP rule, 31 CFR 1020.220, a bank's procedures describe when it uses documents, non-documentary methods or both. A database check can verify an applicant without a document, and a document check can then be kept for applicants the data cannot verify or whose risk calls for a step-up.

Should a financial institution use one identity verification provider or several?

A financial institution should at least be able to add a second identity verification provider without rebuilding its rules, even if it starts with one. A second provider covers documents and applicants the first cannot verify, and keeps onboarding running if the first has an outage. The cost of a second provider is the contract, the reviews and the integration, so weigh it against the coverage gaps your own test reveals.

How do you test an identity verification provider before signing?

Replay a sample of your own past applications through every candidate, including confirmed fraud and genuine customers who failed verification. Compare why each provider failed applications, not only how many it passed, force a failure to test fallback, and pull a few per-applicant records. The test plan above sets out the steps.

Does passing identity verification mean an applicant is not a fraudster?

No. Passing identity verification confirms that a claimed identity exists and matches its documents at a moment in time, and it does not establish intent. A synthetic identity can be assembled to pass the check, so the result should be combined with device, behavioral and cross-application signals before an account opens.

Is Oscilar an identity verification provider?

No. Oscilar is the decision and orchestration layer around identity verification providers: it orchestrates KYC checks and enhanced identity checks from third-party providers, steps applicants up when their risk calls for it, and combines the results with device and behavioral signals to make and explain the onboarding decision. Document verification, selfie matching and liveness checks come from the providers it orchestrates.

The best identity verification software is the one that performs on your own applications: it reads your applicants' documents, explains its failures, lets you fall back to another provider and hands its result to your decision with the reasons attached. Ask every candidate the same eight questions, run the same test on your own past applications, and decide on the evidence that test produces.