We integrate identity verification APIs into an existing NBFC or fintech onboarding flow. The engagement covers vendor selection against your real volume and risk profile, the integration itself, fallback behaviour for when a provider degrades, and an audit trail your compliance team can defend. At handover you own working, instrumented code and the reasoning behind every choice in it.
The problem this solves
Almost every onboarding funnel we are asked to look at has the same shape. The marketing spend is working, applicants arrive, and then a disproportionate number of them stop at the verification step. When the drop-off is investigated, the cause is rarely a single broken thing. It is an accumulation of decisions that each seemed reasonable in isolation.
A vendor was chosen during a procurement cycle on the strength of a per-call price and a sandbox demo. Nobody modelled what happens when the same integration runs at month-end volume, or when the upstream registry the vendor depends on is slow rather than down. The integration was written by whoever had capacity that sprint, treated as a single synchronous call, and shipped. There is no distinction in the code between "this identifier does not exist" and "we could not reach the service in time", so both outcomes render the same rejection screen to a real applicant who then goes to a competitor.
Then the audit arrives. The compliance team is asked to demonstrate, for a specific customer, which checks ran, in what order, against which source, and what each returned. The application database has a boolean. The vendor dashboard has thirty days of retention and a different customer identifier. Reconstructing the trail becomes a manual exercise, and the finding writes itself.
Underneath all of it is a resourcing problem. Verification integration is specialised work that a lending engineering team does once, under deadline pressure, and then maintains forever. The knowledge of why a particular retry window was chosen leaves with the engineer who chose it.
What we deliver
The engagement produces a defined set of artefacts, and you should be able to check each one off at handover.
- The integration itself, covering the checks agreed in scope, written into your codebase in your language and framework rather than delivered as an opaque service you now depend on us to run.
- A vendor selection record that states which providers were considered for each check, what each was assessed against, and why the chosen one won. When someone asks that question in eighteen months, the answer is written down.
- Fallback and degradation design — what the flow does when a provider times out, returns a malformed response, rate-limits you, or is confidently wrong. This is the part that separates a demo from a production system.
- An audit logging schema that records every verification attempt against a customer identifier your systems already use, with the request, the outcome, the source and the timestamp, retained on your infrastructure rather than the vendor's.
- A failure-mode test suite that exercises the paths nobody exercises by hand: the timeout, the partial response, the duplicate submission, the retry that succeeds after the applicant has already given up.
- A runbook and a handover session with the engineers who will own it, so the first production incident is not the first time your team reads the code.
How we work
We start with discovery, and it is deliberately unglamorous. We read the existing onboarding flow, the current verification code if there is any, the last audit findings if you are willing to share them, and the volume pattern by hour and by month. What we are looking for is the difference between the flow as documented and the flow as it actually runs, because the gap between those two is where the drop-off usually lives.
Vendor selection comes next, against your numbers rather than a generic recommendation. The relevant questions are which checks you actually need for your customer segment and product, which providers cover those checks against the authoritative source rather than a cached copy, how each behaves under your peak, what their error semantics look like when something goes wrong, and what the commercial terms do at your volume. We do not run a benchmark and we do not publish figures about vendors; we read their documentation carefully, test against their sandboxes, and tell you what we found.
Integration follows, incrementally and behind a flag wherever your release process allows it. We build the failure paths at the same time as the success path rather than after it, because retrofitting graceful degradation into code that assumes success is substantially more expensive than writing it once.
Then we test the failure modes explicitly, go live in a controlled way, and hand over. Duration is driven far more by your release cadence and your vendor's onboarding paperwork than by the engineering, and we will say so during scoping rather than after.
Which verification checks this covers
The specific set depends on your product and customer segment, but an individual identity flow for an Indian lender generally combines an identifier check, a document-based check, and a liveness or presence check appropriate to the risk.
We scope that set with you rather than assuming it. Which identifier checks apply depends on the segment you lend to, which document checks are worth their friction depends on your risk appetite, and whether a presence check is required at all depends on how the account is opened. Each is a separate decision with a separate provider question behind it, and settling them before the integration starts is what keeps the build from being reworked halfway through.
For business and entity verification — GST, CIN, DIN, Udyam and the registries behind them — see KYB verification integration, which is a genuinely different problem with different data sources. Where the process itself is prescribed by the regulator rather than left to your design, see Video KYC and V-CIP integration.
Compliance context
Customer due diligence for a regulated Indian lender is governed by the Reserve Bank of India's Master Direction on Know Your Customer, available in full at rbi.org.in. We link the primary source deliberately. Verification requirements change by amendment, and a summary written on a blog two years ago is a liability rather than a shortcut.
Two practical consequences shape how we build. First, establishing identity requires an Officially Valid Document; a PAN check is a separate obligation under Rule 114B of the Income-tax Rules and does not substitute for one, which means your flow needs both and needs to record both distinctly. Second, an audit trail has to be reconstructible after the fact, per customer, from systems you control. A verification that happened but cannot be evidenced is, for practical purposes, a verification that did not happen.
We build to those two constraints from the first commit rather than treating them as a compliance review to survive later.
Why bring in an integrator
A verification vendor can only ever recommend itself. That is not a criticism of any particular provider — it is the structure of the business. When you ask a vendor whether their coverage is the right fit for your segment, you are asking a question they are commercially unable to answer against interest.
Our incentives sit elsewhere. We are paid for the integration working, not for which provider it calls. The recommendation you get is the one we would implement if the risk were ours, which sometimes means telling you that the provider you have already contracted is fine and the problem is in how it was integrated. It occasionally means telling you that a cheaper option would not survive your audit, and that the saving is not real.
That is also why we publish no figures about vendors anywhere on this site — no latency measurements, no pricing tables, no scores. A number we produced about somebody else's service would be out of date the week after we published it, and you would be the one acting on it. What we can offer instead is judgement, written down, with the reasoning attached.
Two adjacent engagements come up often enough to name here. Where the constraint is not the integration but the team operating it day to day — queue triage, vendor escalation, watching for the degradation that precedes an outage — that is managed onboarding rather than a build. And where the verification flow is one screen inside a lending product that does not exist yet, the integration is a component of NBFC app development, scoped and sequenced with the rest of the build rather than bolted on at the end.