For fintech

KYC document processing built for product teams

You are shipping features, not building an OCR stack. This is the document layer — extract, verify, mask, redact — as four REST endpoints you can integrate in an afternoon and hand to a compliance reviewer without a rewrite.

Talk to our technical team → — for integration questions, a security review or a volume estimate.

The build-versus-buy maths, honestly

Aadhaar masking looks like a weekend project. A regex for twelve digits, a black rectangle, done. Here is what the weekend project misses, in the order teams discover it — usually in production.

Week 1
Twelve digits matches a phone number with a country code, an invoice number, a policy number. You need the Verhoeff checksum, which is not a regex.
Week 2
Aadhaar is printed as three groups of four. Your token-level matcher sees "1234", "5678", "9012" and matches none of them. You need multi-token joining on a line.
Week 3
Half your uploads are photographed at an angle or upside down. You need multiple rotations and multiple OCR passes.
Week 4
Someone notices the rectangle you drew on the PDF is an annotation. The text underneath comes back with copy-paste. You need rasterisation.
Week 6
A customer asks about the VID — the sixteen-digit Virtual ID that authenticates exactly like an Aadhaar number and which you have been storing in the clear.
None of this is hard. All of it is a month, and it is a month spent on something that is not your product — then owned forever.

Four endpoints, one key

Extract
Fields as JSON with the checksum validated, so a mis-read never silently becomes a customer record.
Verify
Checks the card against its own signed QR code. A tampered document fails here rather than at your first NPA.
Mask
First eight digits covered, last four readable. Store this version.
Redact
Everything else in the file: PAN, passport, licence, IFSC, phone, email — on documents you do not have a parser for.

Worked clients with retry and error handling for Python, Node.js and Java. Start on a trial key against the live service — there is no mock environment, deliberately, because a sandbox returning canned responses tells you nothing about how your documents actually OCR.

What compliance will ask your engineering team

Usually a week before a funding diligence, and usually about code somebody wrote eighteen months ago and left.

"Where is the unmasked original?"
The honest answer for most products is: in the upload bucket, in its versioning history, in last night's backup, and in whatever the analytics pipeline copied. Masking at ingestion is the only answer that is short.
"Can you prove masking ran?"
Every call returns a count of what it redacted. Log the count, not the document. That gives you an audit trail with no sensitive data in it.
"What does your vendor keep?"
No document, ever. One metadata row per call carrying key, endpoint, file type, size, duration, count and status code. You can hand that list to a reviewer directly.
"Is it processed in India?"
ap-south-1, Mumbai. Nothing crosses a border.
"What happens if the vendor is breached?"
There are no customer documents in our systems to lose. That is a structural property, not a policy.

Integration patterns that survive contact with production

Questions we get asked

How long does integration take?

A single multipart POST with an API key header. Most teams have masking in a staging pipeline the same day. There is no SDK to install and no dependency to add.

Can we test before committing to volume?

Yes. A trial key with a small quota calls the live service, so what you test is what you will run in production.

Will this keep unmasked Aadhaar out of our logs?

It keeps it out of ours: we return counts by type, never the values, precisely so an identifier does not end up in every access log between us. What your own application logs is yours to control — the usual mistake is logging the request body on error.

Do you handle the Virtual ID as well as the Aadhaar number?

Yes. The 16-digit VID authenticates in place of an Aadhaar number and is covered by default. It is the identifier most in-house implementations miss.

What happens if the masking call fails mid-onboarding?

Fail closed: do not store the original and continue. Hold the document out of the archive, retry, and surface it for review if it keeps failing. The failure mode worth designing against is an exception path that quietly falls back to storing the unmasked file.

Can we run masking asynchronously?

You can, but think about what it implies: the unmasked document has to live somewhere until the worker picks it up, which recreates the stored object you were trying to avoid. Synchronous masking in the request path is the pattern that actually removes the risk.

Related

Talk to us about your document volume

Tell us how many documents a month you process and what your peak looks like. We will size a plan, provision a key with a test quota, and answer a security questionnaire if you need one.