The United Nations Office on Drugs and Crime estimates that criminals launder 2% to 5% of global GDP each year, approximately US$800 billion to US$2 trillion, while stressing that deliberate concealment makes the figure necessarily uncertain (UNODC's overview of money laundering). That scale is why a KYC compliance API should be judged not by whether it returns “verified,” but by what evidence it supplies, how clearly it reports uncertainty, and whether its records remain useful when someone reviews the decision later.
Before comparing vendors, define the scope. Does your product need to establish who the customer is, whether a legal entity exists and is registered, or whether a party is cleared for a particular transaction? Those questions can require different checks, and one API category rarely answers all of them.
Table of Contents
- What a KYC Compliance API Must Prove Before You Choose
- Side-by-Side View of Five Provider Types
- Accuracy Thresholds to Demand from Any Vendor
- Geographic Coverage and GDPR Data Handling Compared
- Integration Effort, Pricing Models and Uptime Terms
- What Happens When the Registry Goes Down
- Which Provider Type Fits Each Use Case
- Confirm the Post-Verification Steps Before You Go Live
What a KYC Compliance API Must Prove Before You Choose
A KYC compliance API is a service that returns structured evidence about a person or business. Depending on the provider, that evidence may include document details, company-registration data, sanctions results, or risk signals. A useful response should identify what was checked, give the result and its source, and include a timestamp and reason codes where available. Without those fields, a pass/fail status can be difficult to explain or audit.
The distinction matters because customer identification, beneficial-owner checks, sanctions and politically exposed person (PEP) screening, risk scoring, and ongoing monitoring address different risks. The API may perform one check, combine several checks, or pass data to another service. A successful identity match doesn't by itself prove beneficial ownership, sanctions clearance, or low risk.
Scope test: Before opening vendor pages, list which of the three buyer questions your product must answer. Mark each as a regulatory requirement or a commercial need, then compare providers against that list.
A business validating a VAT number for an invoice has a different requirement from a financial firm verifying a customer's identity and screening for sanctions. The former may need an authoritative registration response; the latter may need document verification, screening, risk review, and a record of how the decision was reached. Treat those as separate requirements, even if a vendor sells them together.
Side-by-Side View of Five Provider Types
No single provider category answers all three buyer questions. The table shows where each type can contribute, and where you'll need another layer or vendor.
| Provider type | ID and document checks | AML and sanctions | Geographic coverage | Integration effort |
|---|---|---|---|---|
| Full-stack KYC platforms | Document OCR, liveness, and face match | PEP and sanctions screening may be bundled | Varies by document library | Medium, often SDK plus webhooks |
| AML and sanctions data APIs | None or limited | Sanctions, PEP, and adverse-media lookups | Global watchlists, varying by source | Low to medium, often REST |
| Document OCR and liveness SDKs | OCR, MRZ reading, and liveness detection | Not included | Varies by document library | Medium, often a mobile SDK |
| Company registry and VAT validation APIs | Company-registration and VAT-number checks | Not included | TaxID covers 31 countries, including EU member states via VIES | Low, often a REST endpoint |
| Bank and account verification APIs | Account-ownership checks | Not included | Country-specific, often limited | Vendor-specific; confirm API and workflow requirements |
Full-stack services can consolidate identity steps, but buyers should confirm exactly which checks are included, what data sources each check uses, and whether screening is ongoing or limited to onboarding. Screening APIs can be a better fit when a business already handles identity verification but needs sanctions or PEP lookup. Standalone document tools focus on whether a document appears valid and whether capture or liveness checks pass; they don't establish that a person is clear to transact.
Company and VAT validators solve a narrower problem. TaxID validates VAT and company identification numbers across 31 countries, returning validation status, registered name, and address in JSON. It doesn't perform document OCR, liveness, or AML screening, so it belongs as one layer in a verification pipeline, not as a complete KYC system. For teams that also need to match a business address against company data, a business address lookup API is a related capability to evaluate separately.
Ask vendors to demonstrate coverage by check type, not just country. Full-stack platforms such as Sumsub, Veriff, and Persona, screening services such as ComplyAdvantage and Dow Jones Risk & Compliance, document tools such as Regula and Microblink, registry services, and account-verification providers should all be scored against the same requirements. Names make a shortlist, not a verdict.
Accuracy Thresholds to Demand from Any Vendor
Treat the numbers below as a worked example for a high-risk onboarding flow, then tune them to your fraud model and legal duties. NIST's digital identity guidance is split across the SP 800-63-4 suite: NIST SP 800-63A covers identity proofing and enrollment, while biometric performance is addressed elsewhere in the suite, including SP 800-63B. Because clause numbers vary by revision and assurance level, ask each vendor to cite the exact standard, section, and test method behind every claim.
| Check | Example buyer floor | Evidence to request |
|---|---|---|
| 1:1 biometric false-match rate | 1 in 10,000 comparisons (0.01%) or better | Benchmark report, dataset description, test methodology |
| 1:1 biometric false non-match rate | 1 in 100 comparisons (1%) or better | Results by demographic group, device class, and capture condition |
| Presentation-attack detection: impostor accept rate | Below 0.07%, with unit stated as percent or proportion | Independent test evidence, attack types tested, model version |
| Remote document capture | Machine-readable result for document detected, image quality, authenticity or security-feature status, tamper signal, retry count, and timestamp | Capture-flow description plus sample API responses for pass, fail, and retry |
| Independent test cadence | Dated third-party report before contract signature and after material model changes | Report date, lab name or test basis, scope, model and data versions |
A binary result hides how the system reached its decision. Ask whether the API returns confidence or match scores, liveness and presentation-attack outcomes, retry outcomes, and machine-readable reasons for rejection or manual review. A vendor that provides these details lets your team investigate a disputed result. A vendor that returns only “verified” leaves the evidence locked inside the service.
Demand the test methodology with the score. Ask which devices, lighting conditions, document types, and participant groups were represented. Request cuts by demographic group and operating condition instead of an aggregate pass rate. If a vendor cites NIST, require the specific publication and clause used for each metric, and record the model version that produced the result.
A strong lab result is a starting point for evaluation; it does not prove the same workflow holds up on the phones, cameras, lighting, and documents your customers bring.
Run your own capture set before launch, including poor lighting, camera blur, expired documents, mismatched faces, and interrupted retries. Log what the API returns for a mismatch, an unreadable document, a failed liveness check, and an abandoned attempt. Confirm your application separates rejected, needs review, and unable to verify, since audit evidence is lost when those outcomes collapse into one status.
Geographic Coverage and GDPR Data Handling Compared
Headline country counts can hide gaps. Ask for a country list for each check type, because identity-document libraries, company registries, and watchlist sources don't necessarily cover the same markets. A vendor may support passports in a country but not national identity cards, or offer company data without biometric verification. A global coverage guide to tax ID validation can help frame the distinct coverage question for registry-based checks.
The data-handling review should also reflect what the API processes. A business-registry lookup and a biometric face match don't create the same privacy questions. For biometric data used to uniquely identify a person, GDPR treats the information as special-category data; buyers need to assess their lawful basis and applicable condition, as well as the vendor's processing arrangements. For identity and screening providers, ask for the data processing agreement, sub-processor list, processing locations, retention and deletion terms, and whether customer data is used to train models.
Questions to put to every vendor
- Coverage: Which countries and document types are supported for each check?
- Data location: Where is data processed and stored, including by sub-processors?
- Retention: How long are raw images, extracted fields, and decision records retained?
- Model use: Is customer data used for model training, and can that use be disabled?
- Auditability: Can you export the evidence, sources, timestamps, and reason codes?
- Biometrics: What privacy assessment and supporting documentation can you provide?
VAT and company validation may involve business names and addresses, which can present a different personal-data profile from face images or biometric templates. But company records can still relate to natural persons, such as sole traders or company officers. Don't assume that a “business-only” API removes the need to consider data protection.
Integration Effort, Pricing Models and Uptime Terms
Compare pricing models by the cost drivers they expose. Pay per check charges for each lookup, but confirm whether retries, failed attempts, or manual review are billed separately. That structure can fit low or uneven demand. Subscriptions with included checks suit steadier usage, but quotas, overage rates, and minimum commitments can change the effective price.
An annual enterprise contract may bundle committed volume and an SLA tier. Review the termination terms and data processing addendum alongside the quoted price, especially if your team depends on the provider for regulated onboarding. A free tier can help a team prototype before committing; check its limits, rate controls, and behavior under heavier use rather than assuming it predicts production performance.
Compare total operating cost
Model several monthly volumes using your own expected activity. Add retry calls and cases routed to manual review before multiplying by the effective per-check rate. Then include the time your team spends reviewing exceptions. A lower unit price can still produce a higher total if it sends more cases to manual review.
Operational terms deserve the same attention as pricing. Compare the uptime commitment and how the vendor measures it, p95 and p99 latency, timeout and retry rates, webhook delivery reliability, regional availability, and the percentage of cases routed to manual review. These measures affect whether a check can run inside onboarding or checkout without your application quietly skipping controls when the service is slow. FATF's digital identity guidance is a useful reference when assessing assurance and evidence requirements in digital verification workflows (FATF guidance on digital identity).
During integration, count the endpoints and webhook events you must implement. Check for an SDK in your stack, a usable sandbox, and machine-readable errors that your application can handle without parsing prose. The essential question is not whether the vendor offers an SDK, but whether your system can tell a transient outage from invalid input and apply the right decision rule.
What Happens When the Registry Goes Down
A registry outage forces a compliance decision. If your application treats a cached positive result as current evidence, or accepts every transaction while a source is down, it may produce a decision the record cannot justify later. The exposure is documented: a 2025 European Parliament question cited weaknesses in VIES update processes and enforcement delays in connection with VAT fraud (European Parliament question on VIES).
An unavailable response carries no evidentiary weight. Design the failure states before you need them.
| Failure or data state | Safe default | Evidence to keep |
|---|---|---|
| Format check fails before remote call | Reject with a format error; don't make a lookup | Input value and rule version |
| Live response returns invalid | Block the VAT exemption and show an error | Full response and timestamp |
| Service unavailable, no cache, high-risk payout | Hold the decision, or fail closed | Attempt log and retry schedule |
| Cached result exceeds its age limit | Re-verify before granting an exemption | Original cached record |
Set fail-open and fail-closed rules by transaction risk. A low-risk invoice can be queued for later review when a registry is unavailable, but queuing is not verification. Hold the VAT exemption or reverse charge, or document the tax treatment as unconfirmed, until a live check completes. A high-risk exemption or payout should wait for that live response in every case. Log the outage itself as unavailable so the record shows a pending decision rather than an implied pass.
Caching improves responsiveness, and it also creates a second failure mode. Cached evidence needs an explicit age limit, a named source, and a verification timestamp. An old positive must remain identifiable as an old response. Around that, include format validation before any remote request, retries with backoff, idempotency keys, and a circuit breaker so a failing dependency does not absorb repeated calls during the outage.
When service returns, reconcile every decision made while the registry was down. Re-check queued records, retain both the original state and the later response, and record why the business proceeded, paused, or rejected each transaction. That reconciliation record is what lets you explain the decision during an audit, when the only honest answer is that the external source was unavailable at the time.
Which Provider Type Fits Each Use Case
Start with the transaction, not the vendor's product list. A team billing EU businesses may need VAT validation before applying reverse charge; a consumer app opening accounts needs a different identity workflow. The table pairs common situations with a suitable first layer and the gap that layer leaves open.
| Use case | Must-have capability | Acceptable gap | Typical pattern |
|---|---|---|---|
| SaaS billing in the EU | VAT validation for reverse charge | No ID-document checks | Stripe plus Node.js or Python |
| B2B marketplace or custom checkout | VAT validation at cart | Limited manual-review tooling | Plugin or direct API call in checkout |
| Indie micro-SaaS | No-card free tier and a single endpoint | Enterprise SLA and dedicated support | REST call from app backend |
| Supplier checks in finance operations | Batch validation before payment | Real-time checkout response | Zapier, Make, or a scheduled job |
| Fintech or accounting platform | Embedded VAT, company, and identity checks | Screening gaps handled by a separate provider | Annual contract with SLA and DPA |
For EU SaaS billing, a registry API is often the right first layer for the tax decision. It doesn't establish a customer's personal identity or clear the business for every kind of transaction. Marketplace teams should test the lookup in the checkout path and decide what the cart does when a live response is unavailable; a cached response is helpful only when its age remains visible.
Indie builders can prioritize a straightforward REST integration and a clear upgrade path. Finance teams, by contrast, may value a batch workflow that helps check suppliers before payment more than a synchronous checkout response. Fintech and accounting platforms usually need to combine registry evidence with identity and AML screening, then review contract, availability, and data-processing terms across those providers.
TaxID's use cases for KYC and tax ID verification describe the registry-validation layer, not document or sanctions checks. For any shortlist, write down the gap you're accepting and how the rest of your system handles it. That's more useful than naming one overall winner.
Confirm the Post-Verification Steps Before You Go Live
A “verified” result doesn't close the file. A tax-ID match isn't proof of ownership, authority to act for a business, sanctions clearance, or low risk. For legal entities, collect and assess beneficial-owner information where required, and route ambiguous or incomplete results to a manual-review queue.
Store the provider, timestamp, source, full response, match scores, and reason codes for each decision. Make refresh triggers explicit, and use risk-based review rather than assuming an onboarding check remains current indefinitely. FATF guidance emphasizes reliable, independent evidence and appropriate assessment of digital identity systems; the API response is evidence to evaluate, not a substitute for your own process.
A narrow verification pipeline with clear verified, rejected, unknown, and unavailable states can be easier to defend than several overlapping vendors that produce one opaque score. Use this launch plan:
- Define the checks: List which buyer questions your product must answer and whether each is regulatory or commercial.
- Shortlist by category: Compare providers only where your requirements call for them, using the same evidence and outage criteria.
- Test difficult inputs: In the sandbox, try malformed, stale, failing, and ambiguous cases. Include biometric capture edge cases where relevant.
- Review data terms: Check the processing agreement, sub-processors, retention, deletion, and model-use provisions before sending customer data.
- Launch with records enabled: Keep audit logs, apply the outage rules to each transaction type, and confirm that every response can be traced to its source and time.
TaxID validates VAT and company identification numbers and returns validation status, registered company name, and address through a REST API. If your product needs registry evidence as one layer in a wider KYC workflow, visit TaxID to review its API and decide whether its scope fits your verification requirements.