Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Lenders cannot judge a vendor's tampering detection from a demo, because demo files are chosen to trigger flags and a tool's false-alert rate on genuine statements is never shown.
Build an internal set of altered statements and clean controls from each bank, run both through the tool blind, and score catches, evidence quality and false alerts against tolerances set in credit policy.
Ten to twenty masked or controlled altered copies, an equal number of clean controls, a manipulation-to-check map, and a scoring sheet with page, row and reason for every flag.
A per-signal-family view of what the tool catches, what it misses and how often it alerts on genuine files, with the next review step defined for each flag type.
The fairest test of a vendor’s tampering and fraud detection is a small set of bank statements you know were altered, mixed with clean controls from the same banks. Run both through the tool without telling the vendor which is which, then judge three things: what it flags, how it explains each flag and how often it alerts on genuine files. A flag prompts review; it does not prove fraud.
For how the individual checks work, see PDF tampering detection, balance-chain verification and metadata inspection.
How do you build the known-bad set?
Use three sources and keep the set inside the credit or risk team:
- Masked files from past fraud cases. Statements your team rejected or that led to a fraud report. Mask the borrower’s name and account number.
- Controlled copies made from clean statements. Your own staff take a genuine statement and make general-purpose edits of the kind you have seen: a changed amount, a shifted date, a deleted row. This is for testing only and never leaves the team.
- Clean controls. Untouched statements from each bank you lend against, downloaded through the bank’s channel, in equal number to the altered files.
Ten to twenty altered files and the same number of controls is enough. Under the RBI Master Directions on Fraud Risk Management for NBFCs issued on 15 July 2024, lenders need an early-warning framework for fraud; the results of this test feed the part of that framework that covers document checks.
Which signal families should the tool cover?
Ask the vendor to list its checks by family and show the evidence each produces:
- Document metadata: signs that a file passed through an editor or converter after it left the bank, such as a modification date later than the creation date.
- Balance-chain breaks: rows where the printed balance does not follow from the previous balance plus that row’s credit and debit.
- Impossible dates: postings through clearing channels on dates those channels did not run, such as Sundays and RBI-notified bank holidays.
- Digit patterns: amount distributions that do not look like natural financial data.
- Sequence and structure: gaps in running sequences, rhythmic amounts and round-number clusters.
- Transaction behaviour: circular credits between related accounts and money that comes in and goes straight back out.
| Test | What to give the vendor | What a pass looks like |
|---|---|---|
| Edited amount | Altered file, clean control from same bank | Balance-chain break flagged on the right page and row |
| Shifted date | Altered file with a posting moved to a bank holiday | Impossible-date flag naming the row and the channel |
| Deleted row | Altered file with one debit removed | Balance-chain break at the gap |
| Re-saved file | Genuine statement re-saved through an editor | Metadata flag, clearly labelled as needing review only |
| Circular credits | Past case with round-tripping | Linked credits and debits shown together |
| Clean controls | Untouched statements | Few or no flags; each one explained |
Set the tolerance in your credit policy before the run: for example, no misses on edited balances and no more than 1 in 10 clean controls raising a high-severity flag.
Worked example: a ₹30,000 closing balance edit
Illustrative. A six-page statement shows a genuine page 3 closing balance of ₹48,500. A controlled copy changes the page 3 closing balance to ₹78,500, an increase of ₹30,000, and carries the higher figure forward.
What a good tool should show:
- A balance-chain break on page 3, last row: the previous balance plus that row’s credit minus its debit gives ₹48,500, but ₹78,500 is printed.
- A metadata flag if the copy was saved through an editor, showing a modification date later than creation.
- An opening-balance or inflow mismatch if later pages now show more money than the recorded inflows can explain.
What the clean control should show: the same bank’s format, a balance chain that agrees on every row and no metadata flag. If the control also raises a high-severity flag, ask why before you trust any flag on that bank’s files.
The next step for the credit officer is not rejection but verification: ask for the statement again through net banking download in the officer’s presence, or through Account Aggregator, and compare.
What should you ask the vendor after the run?
- Which altered files were missed, and which check should have caught them?
- What does the false-alert rate look like by bank category?
- Can the evidence be exported into the credit file?
- How are new manipulation types added, and how are lenders told?
How Terra Insight fits
TransactIQ surfaces document-level and transaction-level indicators, including PDF metadata anomalies, balance-chain breaks, impossible-date transactions, digit-pattern and sequence irregularities, as signals for credit and forensic review rather than verdicts. It runs as a managed service on Terra Insight’s AWS Mumbai infrastructure. Evaluating lenders can request a representative-sample fit benchmark, and the bank statement analyzer, statement authenticity checker and fraud and tampering detection pages describe the signal set.