To choose KYC software, start with the obligations you have to meet, then test three things against your own data: list coverage, matching quality, and the audit trail the system produces. Everything else is negotiable. Demos are designed to look good. Your own customer file is the only honest benchmark.

Most buyers do this backwards. They collect feature lists, sit through six demos, then score vendors on things that look impressive but rarely fail in production. The problem surfaces later: the screening engine misses a name spelled a different way, or the audit export is a PDF nobody can query.

What follows is a selection method you can run in about six weeks. It names no products. It gives you the questions, the tests and a weighting you can defend to procurement and to an examiner.

What you are actually buying

KYC software is usually four separate products sold as one. Pull them apart before you evaluate anything, because a vendor can be excellent at one and weak at another.

  1. Identity verification. Reading an ID document, checking it is genuine, matching a live face to the photo.
  2. Screening. Comparing name, date of birth, address and country against sanctions, PEP, adverse media and export control data.
  3. Risk rating and workflow. Scoring the customer, routing the case, holding the decision record.
  4. Ongoing monitoring. Rescreening the existing book when lists change, and prompting periodic reviews.

You may not need all four from one supplier. Plenty of firms buy identity verification from one provider and screening from another. That is a legitimate design, and it keeps negotiating room at renewal.

If you trade physical goods as well as money, there is a fifth requirement that financial crime tools often skip. Export control lists such as the BIS Entity List, the Denied Persons List and the Unverified List are not sanctions lists, and many KYC products do not carry them. If your counterparties ship or receive goods, you need denied party screening alongside AML screening, not instead of it.

Write your obligations down first

Before any demo, write a one page statement covering six points. Vendors will ask for it, and writing it forces decisions you would otherwise defer.

  • Which regulators supervise you, and under which rulebook.
  • Whether you onboard individuals, legal entities or both. Entity onboarding is far harder and identity-first tools often handle it poorly.
  • Which countries your customers come from, and which documents they present.
  • Your risk tiers, and what each one requires.
  • Expected monthly volume, and your worst realistic spike.
  • Your record retention period, and who may see what.

The entity question matters most. Verifying a person is largely a solved problem. Unwinding a holding structure to find the beneficial owner is not. Ask each vendor to walk through a company with two corporate shareholders, one sitting in a jurisdiction with no public register. Watch what the software does when the data is simply absent.

Data coverage decides more than features

Screening software is a search engine sitting on a dataset. If the dataset is thin, interface polish will not save you. Coverage has four dimensions and buyers usually check only the first.

Breadth: which lists are in there

Ask for a written list inventory. Not a marketing phrase like “global watchlists”. You want the source name, the issuing authority and the update frequency for each. Then check your own exposures appear. A firm with US touchpoints needs the OFAC SDN list and the broader consolidated set. The difference between the SDN list and the consolidated screening list is a common gap, and a vendor who cannot explain it quickly is telling you something.

Depth: what each record contains

A name alone produces noise. A useful record carries aliases, transliterations, dates and places of birth, passport and national ID numbers, addresses, vessel details and programme codes. Depth is what lets the engine discard a false hit by itself. Ask to see a raw record for an entity with many aliases, then count the fields.

Ownership and control data

Several sanctions regimes reach entities owned or controlled by a listed party, even when the subsidiary is not named. Name screening will never catch that. Ask whether the product handles the 50 percent rule in sanctions screening, and whether it aggregates stakes held by two or more listed persons. Many do not. Some flag the parent and leave the arithmetic to you.

Update latency

Lists change without notice. Ask how long a new designation takes to reach the vendor’s database, then your live results, and how that is measured. Ask whether a designation triggers an automatic rescreen of existing customers. A tool that screens only at onboarding leaves your back book exposed the moment a list moves.

Test matching quality yourself

Almost nobody does this step, and it is the one that predicts how much your team will suffer. Vendors quote accuracy figures drawn from their own test sets. Build your own.

Build a blind test file

Take a few hundred records from your real book, anonymised if needed. Mix in four groups:

  • Known true matches. Take names currently on a public list and put them in, unaltered.
  • Near misses. Vary those same names the way real data varies. Change transliteration, drop a middle name, swap given and family name order, add a typo.
  • Known clean records. Ordinary customers who should produce nothing.
  • Noise magnets. Very common names, names that share a spelling with a listed party, and entity names containing generic words like trading, holdings or international.

Give the identical file to every shortlisted vendor. Do not tell them which records are which.

What to measure

Three numbers. How many known true matches were caught. How many near misses were caught. And how many hits were produced in total, because that total is your future workload. A tool that catches everything by flagging half your book is an expensive way to hire more analysts. Our guide to resolving a false positive sets out the discipline that keeps that queue under control.

Ask about the controls

Can you change the fuzzy matching threshold, per list or only globally? Can you set a tighter threshold for high risk customers? Can you whitelist a cleared record so the same false hit stops returning, and does that whitelist expire when the underlying entry changes? One locked threshold will either drown you or miss things.

Identity verification and document checks

For consumer onboarding, the identity layer carries most of the fraud risk. Ask for the document catalogue by country and document type, never a country count. Supporting a country means little if it covers only the current passport while your customers present the older national ID card.

Test the failure path. Submit a document photographed at an angle, in poor light, with glare across the machine readable zone. See whether the software asks for a retake with a useful message or just rejects the customer. Abandonment here is silent revenue loss and it shows up in no compliance report.

On biometrics, ask what the liveness check defends against. Printed photos and screen replays are the baseline. Injection attacks, where a manipulated video stream is fed straight to the application, are a different problem needing a different control. Ask whether an independent laboratory has tested the product against a recognised presentation attack detection standard, and ask for the report rather than the badge.

Integration, workflow and the audit trail

Ask for sandbox access on day one and have a developer spend two hours in it. That exercise tells you more about integration cost than any statement of work. Look for clear API documentation, webhooks for asynchronous results, and error messages that name the field at fault.

Then examine what the system writes down. An examiner will ask you to produce, for a named customer on a named date, what was screened, against which list version, what came back, who decided and on what basis. If the product cannot export that in a structured format, it has failed the test that counts. Hold the vendor to the standards in our note on record keeping for denied party screening.

Two specifics are worth insisting on. The system should store the list version at the time of the check, so you can prove what the data said then rather than now. And it should record a clean screen as permanently as a hit. Firms get caught out because they can prove the alerts they investigated but cannot prove they screened the customers who produced nothing.

Evaluation areaWhat good looks likeHow to verify it in the trialSuggested weight
List coverageNamed source inventory with issuer and refresh frequency for each listRequest the written inventory and check your specific exposures appear20%
Matching qualityCatches altered spellings while keeping total hit volume workableBlind test file run identically across all shortlisted vendors25%
Entity and ownership handlingResolves layered ownership and applies aggregation logic to listed stakesGive the vendor a real multi layer structure and watch the walkthrough15%
Audit trail and reportingStructured export showing list version, result, decider and rationaleAsk for a sample export file and try to answer an examiner question with it15%
Integration and workflowDocumented API, sandbox, webhooks, configurable queues and rolesTwo hours of developer time in the sandbox before any commercial talk10%
Security and data handlingIndependent audit reports, stated hosting regions, role based accessRead the actual report, not the certificate logo, and check its scope10%
Total costClear unit pricing with no charge for reruns caused by vendor errorModel three years at your forecast volume, including alert handling time5%

Pricing models and the cost nobody quotes

You will meet four models. Per check, where every attempt is billable. Per approved customer, where failed attempts are free. Tiered bundles with a monthly minimum. And a platform fee plus usage. Per approved customer looks generous and often is, but read how approval is defined, because some vendors count a completed check with a negative outcome as billable.

Get these answers into the contract, not the sales deck:

  • Are retries after a blurred photo charged again?
  • Is ongoing monitoring priced separately from onboarding checks?
  • Does the price change if you add a list, a country or a document type?
  • What is the overage rate above the bundle, and is it capped?

The largest cost is usually not on the invoice. It is analyst hours spent clearing hits the tool should have discarded. Two products with identical licence fees can differ hugely once you count that, which is why the blind test matters. Total hit count is a direct proxy for future headcount. The trade offs in automated versus manual screening are worth reading before you size the team.

Security, data residency and getting your data back

Ask where data is stored and processed, by region, and whether you can pin it. Ask for the independent audit report rather than the certification badge, then read its scope section, because a report can legitimately cover a narrow slice of the vendor’s estate. Send the data processing agreement to legal on day one. It is often the slowest step in the purchase.

Then plan the exit while you still have leverage. Argue for three clauses. A defined export format for every record and document you put in, delivered within a stated number of days of termination. A price for that export agreed now. And a deletion process that respects your own retention obligations, because you may be legally required to keep records the vendor would otherwise wipe.

A scoring method, and the mistakes it prevents

Agree the weights in the table above before the first demo and write them into the evaluation document. Score each vendor out of ten per area, multiply by the weight, then total. Doing this early stops the score drifting toward whoever presented best. Adjust the weights to your own exposure. A firm onboarding only domestic individuals should push identity verification up and entity handling down.

Four mistakes recur. Buying on a demo that ran on the vendor’s own sample data. Treating a certification logo as a substitute for reading the report. Ignoring alert volume because the licence price looked good. And buying a product that screens at onboarding only, with no way to rescreen when a list changes.

Before you spend anything, run a sample of your existing counterparties through a free checker. Globalior’s free screening tool gives you a baseline and a rough sense of hit volume without a procurement process.

Key takeaways

  • KYC software is four products in one: identity verification, screening, risk and workflow, and ongoing monitoring. Evaluate each separately.
  • Ask every vendor for a written list inventory naming each source and its refresh frequency, then check your own exposures appear on it.
  • Build a blind test file from your own records, including deliberately altered spellings of listed names, and run it identically across every shortlisted vendor.
  • Total hit volume from that test predicts analyst workload more accurately than any licence quote.
  • Sanctions rules can reach entities owned or controlled by listed parties, so confirm the product carries ownership data and applies the aggregation logic.
  • The system must record clean screens as permanently as hits, and store the list version used at each check.
  • Negotiate export format, export price and deletion terms before you sign.

Frequently asked questions

How long should a KYC software evaluation take?

Around six weeks is realistic for a mid sized firm. Allow one week to write your obligations statement, one to shortlist, two for sandbox access and the blind test file, and two for legal and security review. The data processing agreement is usually the slowest item, so send it to legal at the start of the trial.

Do I need one vendor for everything?

No. Splitting identity verification and screening across two suppliers is common and often works better, since few vendors lead in both. The cost is integration work and a second contract. The benefit is that you can replace one component without rebuilding the whole onboarding flow.

Is AML screening the same as denied party screening?

They overlap but are not identical. AML screening covers sanctions, politically exposed persons and adverse media, aimed at financial crime risk. Denied party screening also covers export control lists restricting who may receive goods and technology. If you ship anything physical, you need both, and many financial crime tools carry no export control lists at all.

Can a small business get by without dedicated software?

At low volumes, a disciplined manual process with a free screening tool and a proper written record can meet the obligation. Software starts paying for itself when rescreening the existing book by hand becomes unmanageable, or when you can no longer prove what you checked and when. Volume alone is rarely the trigger. Evidence quality usually is.

What should I ask about how often lists are updated?

Ask three things. How quickly a new designation reaches the vendor’s database. How quickly it reaches your live screening results. And whether that update automatically triggers a rescreen of existing customers or only affects new checks. The third question catches the weakest products, because onboarding only screening leaves your existing book exposed every time a list moves.

For a second opinion on a shortlist, or help designing the blind test file, get in touch with the Globalior team. You can also run a denied party screening check on a counterparty now, free, to see what a clean result and a hit look like.