What to redact on a bank statement (and what you must not)

Bank statements are the most frequently shared financial document in Indian lending and the least frequently redacted. They go to lenders for income assessment, to landlords as proof of means, to accountants, to insurers, and increasingly to aggregators and analytics vendors. Most of the time they are shared exactly as downloaded.

They also contain more distinct identifier types than an Aadhaar card does.

What is actually on the page

Identifier	Why it matters	Redact?
Account number	With the IFSC it is sufficient to initiate credits, and it appears in every payment-fraud playbook.	Usually yes
IFSC code	Identifies the branch. Harmless alone; meaningful next to an account number.	Usually yes
Customer ID / CIF	The bank's internal identifier for the person. Useful for social engineering the bank's own support channel.	Yes
Address	Printed on the statement header. Often the most sensitive item on the page and almost never considered.	Depends on purpose
Phone and email	Increasingly printed in the header on retail statements.	Yes, if sharing outward
PAN	Appears on statements issued for tax purposes and on some fixed-deposit advices.	Yes
Counterparty names in transactions	Salary employer, rent recipient, medical payees, loan servicers. Reveals employment, tenancy, health and indebtedness.	Usually no — see below

The thing you must not redact automatically

Here is the trap, and it is the reason our own API leaves bank account detection off by default.

An Indian bank account number is nine to eighteen digits with no checksum and no distinguishing structure. That is also an exact description of an invoice number, a policy number, a customer reference, a cheque number, a UTR, and a loan account number — several of which appear in the transaction narration column of the very statement you are redacting.

This is why "redact everything that looks sensitive" is the wrong default. On a document you have classified — you know it is a bank statement, you know which column is which — account-number redaction is correct and safe. On an unclassified document in a mixed KYC folder, it is destructive.

Transaction narrations: the part everyone forgets

The identifiers get the attention. The narration column is where the actual privacy exposure lives, and it is not pattern-detectable at all.

A twelve-month statement tells a careful reader the customer's employer and salary, their landlord and rent, which hospital they paid and roughly when, which loans they service and with whom, whether they gamble, and which insurers they hold policies with. None of that is an identifier. All of it is inference, and no redaction API will remove it, including ours.

The honest control here is not redaction — it is not sending the document. If the recipient needs income verification, a salary certificate or an account aggregator summary answers the question with a fraction of the disclosure. If they need proof of balance, a bank-issued balance certificate does. The full statement is shared because it is easy to produce, not because it is the minimum that answers the question.

A practical policy

1. Decide what the recipient actually needs. If a summary answers it, send the summary. This removes more risk than any redaction step.
2. If the statement must go, classify it first. You know it is a bank statement, so enable account-number redaction deliberately for this document type.
3. Always redact the header block: address, phone, email, customer ID.
4. Leave the transaction table intact unless the recipient has no need of it, in which case send fewer months rather than a redacted table.
5. Check the result reconciles. If the closing balance no longer follows from the transactions, your redaction has eaten something it should not have.
6. Never rasterise and re-share without checking. A redacted statement that has lost its text layer is fine for a human reader and useless to an automated underwriting system, which may then reject the file.

Where this fits in a KYC pipeline

In a loan file, the bank statement usually arrives alongside an Aadhaar and a PAN. Those two have a defined structure and can be handled automatically with confidence — Aadhaar carries a Verhoeff check digit, PAN has a fixed five-four-one shape. The statement does not, which is why it should be treated as a separate step with its own explicit configuration rather than being fed through the same default pass as everything else.

The general principle is worth stating plainly, because it applies well beyond bank statements: the more confident a redactor is on an unknown document, the more damage it does. Every identifier type worth turning on by default is one that can be validated — by a checksum, or by a structure specific enough that nothing else matches it. Everything else needs you to say what the document is first.