Indian PII Firewall

Nothing personal reaches your database

Customer documents arrive carrying more than you asked for. Put a firewall between the upload and everything downstream: every recognised Indian identifier is found and covered before the file reaches your storage, your analysts or your model.

Talk to us about your document volume See the endpoint

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

11 types10 on by default
Any documentno parser required
Rasterisedno recoverable text layer
In memorynothing written to disk
Counted by typenever by value

Where the firewall sits

One call between the document arriving and the document being useful to anything else.

📤

Customer document arrivesKYC upload, email attachment, agent scan

↓

🔐

PII firewallPOST /api/v1/redact-pii — one call, no document type required

↓

🔍

DetectAadhaar, VID, PAN, passport, voter ID, licence, GSTIN, IFSC, phone, email

↓

Redactthe region is covered and the page rasterised — no text layer underneath

↓

✅

Safe documentinto your database, your data warehouse, your model

The response carries the file, a count of regions covered and a count by type. Never a value.

The problem was never only Aadhaar

Aadhaar is the identifier with a law attached, which is why it is the one everybody names first. It is not the one that turns up most often. A single KYC folder routinely carries a PAN, a bank account and IFSC, a mobile number, an email address, and a GSTIN on the invoice stapled behind them — and the folder is a rent agreement, a salary slip and a utility bill as often as it is an identity card.

An endpoint that only understands Aadhaar cards leaves all of that in place. The firewall is the same idea one level up: stop matching documents and start matching identifiers, so a document nobody has classified is still handled.

A masking endpoint

Knows it is looking at an Aadhaar card. Produces the UIDAI-recognised masked form. Perfect for the card, useless for the bill behind it.

The firewall

Knows nothing about the document. Finds identifiers wherever they are printed, on a form it has never seen, with no per-document work on your side.

They are both worth having, and they are not substitutes. Mask the card you keep as KYC evidence; run the firewall over everything else that came with it. Aadhaar masking and PAN masking sit behind the same key.

What it catches

Ten types are on by default. Each one is either checksum-validated or structurally distinctive enough to be safe on a document nobody has classified — which is the bar for a default, because a wrong redaction cannot be undone.

Type	Shape	Default
`aadhaar`	Twelve digits, Verhoeff-validated	On
`vid`	Sixteen-digit Virtual ID	On
`pan`	Five letters, four digits, one letter	On
`passport`	One letter, seven digits	On
`voter_epic`	Three letters, seven digits	On
`driving_licence`	State code, RTO code, eleven digits	On
`gstin`	Fifteen characters, embeds a PAN	On
`ifsc`	Four letters, a zero, six characters	On
`phone_in`	Indian mobile, optional country code	On
`email`	Anything shaped like an address	On
`bank_account`	Nine to eighteen digits	Off

Why bank_account is off. Nine to eighteen digits with no checksum describes an account number, an invoice number and a customer ID equally well. On by default it would quietly destroy the documents it was meant to make shareable. Enable it where you know the document type — on a bank statement, yes.

GET /api/v1/pii-types returns this table as JSON and needs no authentication, so you can read the current list before a key is issued rather than trusting this page to stay in step.

Documents you are about to give to a model

The firewall matters most at the boundary you cannot audit afterwards. A file that goes into your own database can be deleted. A file that has been sent to a third-party model, indexed into a vector store, or pasted into a support tool has left, and no retention policy of yours reaches it.

Running the firewall first changes what that boundary carries. The model still sees the layout, the dates, the amounts and the language — everything a document-understanding task actually needs — without the twelve digits that make the document about a specific person.

Redact, then send. One call before the model call. The redacted file is what leaves your infrastructure.
Nothing is retained here. The document is processed in memory and returned in the same response. There is no copy on our side to reason about in your DPDP assessment.
No values in headers. X-Redacted-Types reports counts by type. A header carrying the identifier it just redacted would put that identifier into every access log and proxy between us and you.
Zero is a branch, not a pass. A count of zero returns the document unchanged and fully readable. Usually that is correct. Sometimes it means the capture was too poor to read, and that document is the one you least want forwarded.

Redaction, not masking

Masking

Covers the first eight digits of an Aadhaar number and leaves the last four readable — the UIDAI-recognised form. The document remains usable as a KYC record.

Redaction

Covers the identifier entirely. Use it when the document needs to be shareable rather than usable as identity evidence.

PDFs are rasterised rather than annotated. Drawing a black rectangle over a PDF leaves the text underneath recoverable by copy-paste or pdftotext, and a redaction that survives pdftotext is not a redaction. That is the specific failure this endpoint exists to prevent.

Where the firewall stops today

Worth reading before you design around it. These are absences, not roadmap promises — if one of them is load-bearing for you, tell us, because that is how it gets built.

Documents in, documents out. The input is a JPEG, a PNG or a PDF, and so is the output. There is no plain-text or JSON call, so a firewall in front of a chat message or a database field is not something you can build on this today.
Redaction is one-way. There is no tokenization, no vault and no detokenize call. You cannot recover the original value later, and neither can we — there is no mapping stored anywhere. That is a real limitation and, for the no-retention claim, also the point.
Handwriting and signatures are not detected. The types above are printed, structured identifiers. A signature, a handwritten account number or a photograph of a face is left alone.
It does not tell you the document is genuine. The firewall makes a document safe to keep; it says nothing about whether it was altered. That is a different question with a different answer — see document verification, which checks the printed text against the payload UIDAI signed.

Choosing which types to enable

The defaults assume a document you know nothing about. Where you do know something, narrow or widen.

Unknown documents

Use the defaults. That is exactly the case they were chosen for.

Bank statements

Add bank_account. You know the long digit run is an account number here, which is the knowledge the default cannot assume.

Legal and property documents

Consider narrowing. A sale deed carries survey and registration numbers no identifier type should be matching, and a false positive on a legal document is unrecoverable.

Contact-only redaction

Pass just phone_in,email when the goal is to stop a document being used to contact someone rather than to identify them.

Questions we get asked

How is this different from the Aadhaar masking API?

The masking endpoints know what they are looking at and produce the UIDAI-recognised masked form of one card. The firewall does not need to know what the document is: it matches identifiers wherever they appear, so a rent agreement, a salary slip or a hospital bill is handled with no per-document work.

Does it work on documents you have never seen?

That is the design. It matches identifiers rather than recognising layouts. Anything shaped like an Aadhaar number, a PAN, a GSTIN or an email address is found regardless of which document it is printed on.

Can I use it before sending documents to an LLM?

Yes, for documents. Send the file to the firewall, get the redacted file back, and send that to your model. Today the input and the output are both documents — JPEG, PNG or PDF — so a plain-text or JSON firewall call is not yet available.

Does it tokenize, so the values can be recovered later?

No. Today it redacts only, and a redaction is one-way. There is no token vault and no detokenize call, which also means there is nothing on our side holding a mapping back to the original identifiers.

Do you keep the documents?

No. The document is processed in memory and the redacted file is returned in the same response. Nothing is written to disk and no values are returned in headers — only counts by type.

What happens if it finds nothing?

The document comes back unchanged and fully readable, with a count of zero, and the call is not charged. Treat zero as a branch in your code rather than an assumption — plenty of documents genuinely carry no identifier, but so does a document the firewall failed to read.