All posts

KYC API for banks and NBFCs in India: how to choose a verification stack

Choosing a KYC API stack for a bank or NBFC in India. The six verification families a lending journey needs, nine criteria that separate vendors, and what uptime and fallback really cost.

A woman completes a video KYC at home, her face matched on the phone screen as she holds up her identity card

A KYC API verifies a customer’s identity or details against an authoritative source and returns a result in seconds. Choosing between providers comes down to coverage, latency, uptime and fallback behaviour, not API count. Most lending journeys need six families of checks.

Verification is bought the way it fails: one API at a time. A bank adds PAN verification from one vendor, bank account verification from another, video KYC from a third, and discovers that the onboarding journey now depends on three uptime SLAs, three support queues and three sets of error semantics that nobody has mapped to a single fallback policy.

A KYC API stack is not a list of endpoints. It is a set of decisions about what happens when a check fails, and most procurement processes never test that.

The six families a lending journey needs

Work backwards from the journey rather than forwards from a vendor’s catalogue.

  1. Identity verification: PAN, driving licence, DigiLocker and other officially valid documents, plus the name and date-of-birth matching logic that sits on top.
  2. Business verification: GST, MCA and CIN, Udyam. Anything that onboards a proprietor, partnership or company rather than an individual, often described as KYB.
  3. Video KYC: RBI’s V-CIP flow, with liveness detection and face match, where remote onboarding has to meet the full standard.
  4. Document intelligence: OCR, masking and secure storage for the documents a customer uploads.
  5. Financial intelligence: EPFO, ITR, bureau and bank statement analysis that derives obligations and FOIR, which is where underwriting input actually comes from.
  6. Payments verification: penny drop, eNACH mandate registration and UMRN, which decide whether money reaches the right account and whether the EMI can be collected.

A stack missing any one of these will have a manual process bolted onto the journey at that point, and that manual process will become the drop-off.

The nine criteria that separate vendors

#CriterionWhy it decides the outcome
1Coverage across all six familiesEvery gap becomes a second vendor, a second contract and a second failure mode
2Median latency, not best caseA check that usually returns in 400ms and sometimes in 9 seconds is an abandoned application
3Uptime SLA with a number attached“High availability” is not a commitment; a stated percentage is
4Fallback behaviour on failureDoes a timeout return a typed error your journey can route on, or does it hang?
5One SDK or manyIntegration cost is paid once per vendor, then again at every upgrade
6Sandbox before contractIf you cannot test before signing, you are buying a demo
7Data handling and residencyDPDP Act readiness, India residency, tokenised storage of identifiers
8Audit trailCan you show, per application, which check ran, when, against what, and what came back?
9Volume evidenceChecks run to date, on what kind of traffic, for what kind of institution

Row 4 is the one most often skipped and most expensive to discover later. A verification API without defined timeout semantics does not fail loudly; it fails as a conversion number nobody can explain.

What to ask in the evaluation

  • “What is your median response time, and your 95th percentile?” The median sells; the tail decides your drop-off rate.
  • “Show me the error codes.” A vendor who can hand over a typed error taxonomy has thought about your journey. One who returns a generic 500 has not.
  • “What happens if the source registry is down?” Not the vendor’s API: the underlying registry. The honest answer involves a fallback, not a promise.
  • “Give me a sandbox key today.” Same test as for lending software, same diagnostic value.
  • “How many checks have you run?” Volume at an Indian bank’s traffic pattern is not the same as volume in general.

A note on buying by API count

“100+ APIs” appears in nearly every verification vendor’s material, including ours. It is a weak differentiator on its own, because the number counts endpoints rather than journeys. The useful version of that question is narrower: do you cover all six families for the products I run, with one integration, and what is the uptime and the fallback on each?

Two vendors with identical API counts can differ enormously on the only three numbers that affect your funnel: latency, uptime and the behaviour on failure.

Who is usually on the shortlist

Indian lenders evaluating verification typically see four groups. Trustt competes with all of them, so read this as a map of the category rather than a ranking. Descriptions cover capability only, taken from each vendor’s own public positioning as at November 2026, with no claims about relative performance, accuracy or price. Confirm current scope and SLAs with any vendor directly.

Broad KYC and onboarding API platforms. Signzy, IDfy, HyperVerge, AuthBridge and Trustt. Identity verification, video KYC, document checks and business verification through one integration, usually with a workflow builder on top. The group where whole-journey coverage is most likely.

Financial intelligence led. Perfios and Digitap. Strongest where the requirement is income assessment, bank statement analysis and underwriting input rather than identity alone, with identity APIs alongside.

eSign and document execution specialists. Digio, Leegality and SignDesk. Built around Aadhaar eSign, eStamp, mandate registration and legally binding document execution. Often bought alongside a KYC platform rather than instead of one.

Global providers. Veriff and similar. Strong on cross-border identity, with narrower coverage of India-specific registries such as GST, Udyam, CKYC and the V-CIP standard.

Most lenders end up with two of these, not one. That is a defensible outcome, but it is a decision to make deliberately, with the fallback behaviour mapped across both, rather than one that accumulates.

Where Trustt’s identity suite sits

Trustt’s Digital Identity suite covers all six families on one integration: Identity Verification (PAN, driving licence, DigiLocker and other OVDs), Business Verification (GST, MCA and CIN, Udyam), Video KYC built to RBI’s V-CIP standard with liveness and face match, Document Intelligence (OCR, masking, vault), Financial Intelligence (EPFO, ITR, bureau and bank statement analysis deriving FOIR and obligations) and Payments (penny drop, eNACH, UMRN).

Against the criteria above: 100+ KYC and verification APIs, 500M+ checks run to date, a 99.95% uptime SLA and sub-second median response. Integration is sandbox first, then one SDK, then production keys. On data handling, Trustt is ISO 27001 certified, DPDP Act ready with India data residency, in PCI DSS Level 1 scope and CERT-In aligned, with quarterly VAPT and an annual red team.

Where it matters most is the join to lending. Inside the lending platform, every verified field carries its source, timestamp and confidence, so the underwriting decision is traceable to the check that produced the input. Upstream failures return a typed 424 error with a configurable fallback, so a bureau or Account Aggregator timeout is a routing decision in your journey rather than a dead application. AU Small Finance Bank uses Trustt for eKYC and eSign at scale across customer onboarding and UPI QR merchant onboarding, Utkarsh Small Finance Bank for eKYC and vault, and Avanti Finance for eSign in field onboarding.

If your onboarding funnel has a drop-off nobody can explain, it is usually a verification timeout. Talk to a Trustt specialist.

Talk to a specialist

Frequently asked questions

Which KYC API is best for banks in India?

The right stack is the one covering every check your journey needs on one integration, with a stated uptime SLA, a median latency you have tested rather than been told, and defined fallback behaviour when a source registry fails. Score coverage, latency, uptime, fallback, SDK count, sandbox access, data residency and audit trail.

What is a KYC API?

A KYC API is an interface a lender calls to verify a customer’s identity or details against an authoritative source, returning a structured result in seconds. Common examples are PAN verification, bank account verification, GST and Udyam verification for businesses, and video KYC for remote onboarding.

How much does a KYC API cost in India?

Verification APIs are normally priced per successful check, with rates varying by check type: PAN and bank account verification sit at the low end, video KYC and bureau pulls at the high end. Ask whether failed checks are billed, and whether volume tiers apply, before comparing per-check rates across vendors.

What is the difference between KYC and KYB?

KYC verifies an individual. KYB, know your business, verifies an entity: its registration, GST status, directors and beneficial ownership, usually through GST, MCA and CIN, and Udyam checks. An MSME lending journey needs both, because it onboards the business and its proprietor or directors.

What is video KYC and when is it required?

Video KYC, or V-CIP, is RBI’s video-based customer identification process, allowing remote onboarding with liveness detection and face match to the same standard as in-person verification. Lenders use it where a customer cannot visit a branch and a full-KYC relationship is being opened.

How many verification APIs does a lender actually need?

Fewer than vendors imply. Most lending journeys need six families: identity, business, video KYC, document intelligence, financial intelligence and payments verification. The number of endpoints matters far less than whether all six are covered through one integration with consistent error handling.

What uptime should a verification provider commit to?

Ask for a stated percentage rather than an adjective. Trustt commits to a 99.95% uptime SLA with sub-second median response across its verification APIs. Equally important is what the provider does when the underlying government or bureau registry is unavailable, which no SLA can cover.

What should happen when a verification check fails?

The API should return a typed error your journey can route on, with the failure reason distinguishable: bad input, record not found, registry unavailable, timeout. Each should map to a different path: correction, decline, retry or manual review. Treating all failures as rejections loses genuine customers.

Is customer data from KYC checks stored in India?

It depends on the provider. Under the DPDP Act, lenders need to know where personal data is processed and stored, and how identifiers are secured. Trustt is DPDP Act ready with India data residency, ISO 27001 certified, in PCI DSS Level 1 scope, with tokenised storage for sensitive identifiers.

Technology you can bank on!

Researched and drafted with AI assistance under editorial review by Gautam Bandyopadhyay.

Gautam BandyopadhyayCEO & Co-Founder
All posts

Keep reading

All posts