How to Detect Tampered PAN Cards, Aadhaar Documents and Salary Slips: A Forgery Detection Guide for Lenders
NBFC and fintech lending runs on documents. A PAN card confirms tax identity, Aadhaar confirms residency and identity, a salary slip and a few months of bank statements stand in for the income proof that underwriting decisions get built on. And every one of those document types gets forged or tampered with, in ways that are boring and recurring rather than exotic - a salary figure bumped up in a scanned payslip to clear an income threshold, a PAN card with a date of birth quietly altered to fix an eligibility mismatch, someone else's photo morphed onto a genuine-looking ID, a bank statement with a couple of transaction lines edited to smooth over a month where the balance dipped too low.
None of this requires a sophisticated forger. A reasonably competent person with image editing software and twenty minutes can produce a document that looks completely normal to a human reviewer glancing at a PDF on a screen, and that reads out perfectly clean text to a plain OCR engine. That's the specific problem this post is about - not fraud in the abstract, but the concrete question of how a lender actually catches a document that's been edited, when the edit itself was done well.
Why OCR Alone Doesn't Catch Tampering
Optical character recognition does exactly one job: it looks at an image and converts the text in it into machine-readable characters. Feed it a salary slip and it will hand back a name, an employee ID, a gross salary figure, deductions, a net pay number - accurately, and usually in a fraction of a second. That's genuinely useful, and it's the backbone of any document verification flow, because it's what turns a static image into structured data a system can actually act on.
What OCR does not do, and was never built to do, is judge whether the text it just read is true. If someone has opened a salary slip in an image editor and changed "42,000" to "84,000" - matching the font, matching the spacing, blending the edit into the surrounding pixels reasonably well - OCR will read "84,000" with complete confidence. It has no concept of what the number used to say, no way of knowing the pixels around that figure were touched after the document was originally generated. It's reading the document as it currently exists, not as it was issued.
This is the gap that catches lenders who treat OCR as their entire document verification layer. It's fast, it's cheap to run, and it makes a document verification flow feel automated - but on its own it verifies legibility, not authenticity. A forged document that's been edited competently sails through OCR looking identical to a genuine one. Catching the forgery needs a second layer that examines the document itself for signs it's been altered, independent of what the text says.
What Document Forensic Analysis Actually Looks For
Document forensic or tamper-detection analysis works at the image level rather than the text level. Instead of asking "what does this say," it asks "does this image look like it was produced in one continuous step, or does part of it look like it was added, altered, or pasted in afterward." A few of the signals this kind of analysis typically checks for:
Editing artifacts at the pixel level
When someone edits a region of an image - retyping a number, pasting in a different photo, smoothing out a line of text - that region tends to carry telltale signs even when the edit looks clean to the naked eye. Font rendering in the edited area can differ subtly from the rest of the document (a slightly different anti-aliasing pattern, a font that's a close match but not an exact one). Compression artifacts around an edited region often don't match the compression pattern of the rest of the image, because that region was re-saved or re-compressed separately from the original. Lighting and noise patterns can be inconsistent too - a pasted photo lit differently from the rest of the ID, or a patch of unnaturally uniform pixels where a genuine scan would show natural sensor noise.
File and metadata inconsistencies
For documents submitted as digital files rather than photos of printouts, the file itself often carries metadata - creation and modification timestamps, software signatures left behind by editing tools, layer information that wasn't fully flattened out. A PDF that claims to be a straight scan but carries metadata from an image editor is worth a second look, even before anything about the visible content raises a flag.
Layout and template mismatches
Government-issued documents follow specific templates. A PAN card has a defined layout, font, and placement issued by the Income Tax Department; an Aadhaar card has a defined layout, QR code structure, and security elements specified by UIDAI. Forensic checks compare a submitted document against what a genuine document of that type should look like - field positions, spacing, the presence and placement of security features like the state emblem, guilloche patterns, or the Aadhaar QR code - and flag documents that deviate from the expected template, even in ways too subtle for a person to notice at a glance.
None of these checks work in isolation, and none of them can promise a forgery-proof result - a good enough forgery, given enough effort, can defeat any single signal. What forensic analysis actually does is stack multiple independent signals so that a forgery has to get all of them right simultaneously, which is a meaningfully harder bar to clear than fooling a human reviewer's eye.
Cross-Verification: Checking the Data Against the Source
Here's the part that matters even if a forgery is technically flawless at the pixel level: for documents like PAN and Aadhaar, there's an issuing authority sitting behind them with its own database, and you can check the claimed data against that database independent of anything about the image itself.
A PAN verification check queries Income Tax Department records for whether that PAN number actually exists, whether it's active, and whether the name on file matches the name the applicant has given. A forger can produce an image that looks exactly like a real PAN card, right down to the font and the hologram - but if the PAN number printed on it doesn't correspond to a real, active record, or the name doesn't match, the forgery fails at the database check regardless of how well the image itself was made. Aadhaar verification works the same way in principle - the demographic data and Aadhaar number pattern get checked against what UIDAI's systems return, rather than trusting whatever's printed on the card.
This is why document forensics and database cross-verification aren't substitutes for each other - they're two different failure modes, and a lender needs both closed off. Forensic analysis catches a forgery even when there's no database to check against, or when someone has submitted a real, unaltered document that simply belongs to someone else (a genuine PAN card with a swapped photo, say). Database cross-verification catches a forgery even when the image itself is flawless, because the underlying data still has to match a real record somewhere. A verification stack that only does one of these has a predictable blind spot the other one exists specifically to cover.
Salary Slips and Bank Statements: Verification Without a Government Database
PAN and Aadhaar have the luxury of an authoritative government source to check against. Salary slips and bank statements don't - there's no central database of "genuine salary slips issued this month" you can query the way you'd query Income Tax Department or UIDAI records, and that's exactly why income document fraud is harder to catch than identity document fraud, and why it deserves its own layer of thinking rather than assuming the same approach carries over.
What you're left with, in practice, is internal consistency and cross-referencing rather than a single authoritative check:
Do the numbers actually add up: gross salary minus the listed deductions (PF, professional tax, TDS) should equal the stated net pay. A slip where the arithmetic doesn't reconcile is either sloppy or edited, and either way deserves a closer look.
Does the format match the claimed employer's known template: larger employers tend to have a consistent payslip layout, and a submission that deviates from the template a lender has seen before from the same company is worth flagging, though smaller employers with no established template make this signal weaker.
Does the employer itself check out: a company name and PAN that don't resolve to a real, verifiable business is a red flag well before you even get to the salary figure - an income claim from an employer that doesn't exist isn't worth much.
Does the claimed salary show up as a matching credit in the bank statement: this is usually the strongest signal available, because a bank account isn't as easy to fabricate as a PDF. If the salary slip says forty-two thousand and the account shows a recurring credit of that amount from a source consistent with the employer's name, that's real corroboration. If the account shows something considerably different, or no matching recurring credit at all, that mismatch matters more than anything about how clean the payslip itself looks.
None of these checks is individually conclusive - a genuine borrower can have a messy payslip format, an unusual deduction structure, or a bank account that isn't their primary salary account. But taken together, they give a reasonably reliable picture, and they push the fraud detection burden away from "does this one document look real" and toward "does this whole picture hang together," which is a harder thing for a fabricated application to fake consistently across multiple documents.
Document Types, Common Tampering Patterns, and How They're Caught
| Document Type | Common Tampering Pattern | How It's Detected |
|---|---|---|
| PAN Card | Altered name or date of birth to fix an eligibility mismatch; morphed photo | Layout/template check against the Income Tax Department's issued format, plus PAN database verification of the name and number |
| Aadhaar Card | Photo swap; edited demographic details; fabricated QR code | QR code and template validation, plus UIDAI-based demographic cross-verification |
| Salary Slip | Inflated gross salary or net pay figure; fabricated employer letterhead | Pixel-level edit artifacts around the altered figure, arithmetic reconciliation, cross-check against bank statement credits |
| Bank Statement | Edited transaction lines to hide a low balance or bounced payment | Formatting/font consistency checks, running-balance reconciliation across entries, cross-check against penny-drop bank account verification |
Putting the Layers Together in an Onboarding Flow
In practice, none of this needs to slow down onboarding the way a manual document review would. A document verification flow that combines these layers typically runs as follows: OCR extracts the structured data from whatever document was submitted, forensic analysis runs against the image itself for tamper signals, and - wherever an authoritative source exists, as it does for PAN and Aadhaar - the extracted data gets cross-checked against the issuing authority's records. Where no such database exists, as with salary slips and bank statements, the system leans more heavily on internal consistency checks and cross-referencing against other submitted documents.
Where this gets useful for a lender isn't any single check catching every case - it's that stacking these layers means a fraudulent application has to defeat all of them at once, across multiple documents, to get through clean. That's a meaningfully higher bar than editing one payslip and hoping nobody looks closely.
Frequently Asked Questions
Can OCR alone detect a forged or tampered document?
No. OCR is built to read text off a document accurately, not to judge whether that text is genuine. A salary slip with a photoshopped income figure will often OCR perfectly clean - the software has no way of knowing the number was edited, because it only sees pixels that render as characters. Catching tampering needs a forensic layer on top of OCR that looks at the image itself for signs of manipulation, not just at what the text says.
What's the difference between OCR and document forensic analysis?
OCR extracts and reads text and fields from a document image. Document forensic analysis examines the image itself - font consistency, compression artifacts, lighting patterns, metadata, layout against the known template for that document type - to flag signs of digital editing. OCR answers "what does this document say"; forensic analysis answers "has this document been altered since it was issued." A verification stack needs both.
How do lenders verify that a salary slip is genuine, since there's no government database for it?
Mostly through internal consistency and cross-referencing rather than a single authoritative source. That means checking that the numbers on the slip actually add up (gross minus deductions equals net), that the format and layout match the claimed employer's known template, that the employer itself is a real, verifiable entity, and - most importantly - that the claimed salary shows up as a matching credit in the applicant's bank statement. No one signal is conclusive on its own, but together they're a reasonably reliable proxy.
Does document forgery detection require the original physical document, or does it work from a scan or photo?
It works from a scan or a photo, which is what nearly all digital onboarding relies on anyway - lenders aren't handling physical PAN cards and salary slips in most journeys. Some forensic signals (print artifacts, physical security features like holograms) get harder to assess once a document is digitised, which is exactly why forensic analysis of the image is paired with database cross-verification wherever an authoritative source exists, rather than depending on the image alone.
How much faster is API-based document verification compared to manual review?
This varies a lot by document type and how many checks are chained together, but the general shape is consistent: automated OCR plus forensic and database checks typically return a result in seconds, where a manual reviewer eyeballing the same document might take several minutes per case and still miss subtle tampering a pixel-level check would catch. The bigger gain for most lenders isn't raw speed, it's consistency at volume - a human reviewer's attention varies across the two-hundredth file of the day in a way an API doesn't.
Conclusion
Document fraud in lending rarely looks dramatic - it's a number quietly changed on a payslip, a date of birth nudged on a PAN card, a bank statement line edited to hide a bad month. Catching it reliably takes more than reading the text off a document; it takes examining the document itself for signs of tampering, and wherever a government database exists to check against, confirming the data actually matches a real record. That combination - OCR extraction, forensic tamper detection, and database cross-verification working together - is exactly the layer document verification APIs like Verify Edge are built to support. If you're looking to add this kind of check into your onboarding or underwriting flow, get in touch with SecureEdge to talk through what that would look like for your document mix.
