Credit teams cannot reliably detect edited bank statement PDFs by visual inspection alone. A document with modified transaction amounts or a boosted opening balance can look identical to a genuine statement unless the PDF's internal metadata is examined.
Inspect four metadata fields on every uploaded PDF: Creator (the application that originally created the document), Producer (the PDF rendering engine), CreationDate (when the file was first generated), and ModDate (when the file was last modified). Bank-generated PDFs from known core banking software show consistent Creator/Producer values and matching creation and modification dates. Consumer editing tools update these fields automatically, exposing the edit.
Match Creator and Producer values against a reference list of known banking software (Finacle, Flexcube, iText, Crystal Reports, Temenos T24) and known editing tools (iLovePDF, Smallpdf, Foxit PDF Editor, Adobe Acrobat DC, LibreOffice Draw, FPDF, ReportLab). Flag when CreationDate differs from ModDate by more than a de minimis threshold.
Per-PDF metadata verdict — Clean, Flagged for Review, or Unknown — with the specific field values that triggered the classification, surfaced in the fraud signals section of the bank statement analysis report.
Credit teams reviewing loan applications from NBFCs, small businesses, and individual borrowers face a document that looks identical whether it is genuine or altered — a PDF bank statement. Bank statement PDF metadata inspection examines the properties embedded inside every PDF file to determine whether the document left the bank’s core banking system intact or was processed through an editing tool after generation. This check takes seconds to run automatically and catches a category of manipulation that visual review cannot detect.
What PDF Metadata Is
Every PDF file carries a set of internal properties that describe how, when, and by what software it was created. These properties are not visible in the rendered document — they sit in the file’s underlying structure and are accessible through document properties tools or automated parsing.
The four fields that matter most for bank statement verification are:
- Creator — the application that originated the document (e.g., the report generation module in a core banking system)
- Producer — the PDF rendering engine that converted the content into PDF format
- CreationDate — the timestamp when the file was first generated
- ModDate — the timestamp when the file was last modified
A bank-generated statement produced directly from a core banking system will typically show software like Finacle, Flexcube, iText, Crystal Reports, or Temenos T24 in the Creator or Producer field. The CreationDate and ModDate will match, because the file was generated once and never subsequently edited.
What Flagged Metadata Looks Like
When a PDF is opened in a consumer editing tool — even just to view it, crop it, or merge it with another file — the editing software typically updates the Producer field and may update the ModDate. When the document is saved or exported, it now carries evidence of that intervention.
The most significant signal is a CreationDate that differs from ModDate. A statement generated on 1 March 2026 and modified on 15 March 2026 raises the question: why was it modified two weeks after generation? Banks do not re-export existing statements through editing tools. Applicants who have altered amounts, added transactions, or changed balances will almost always have done so through software that leaves this trace.
Creator and Producer values from tools like iLovePDF, Smallpdf, Foxit PDF Editor, Adobe Acrobat DC (editing mode), LibreOffice Draw, or similar consumer tools are categorised as flagged — not because use of those tools is inherently fraudulent, but because genuine bank-generated PDFs do not pass through them.
Metadata Reference Table
| Creator / Producer Value | Origin | Verdict |
|---|---|---|
| Finacle, Infosys Finacle | Core banking — Infosys (HDFC, Union Bank, others) | Clean |
| Flexcube, Oracle FLEXCUBE | Core banking — Oracle (ICICI, SBI, PNB, others) | Clean |
| iText, iTextSharp | PDF library used in banking software | Clean |
| Crystal Reports, SAP Crystal | Enterprise report generation | Clean |
| Temenos T24, Temenos Transact | Core banking — Temenos | Clean |
| ReportLab, FPDF | Python/PHP PDF libraries, sometimes used in bank portals | Clean |
| iLovePDF, Smallpdf, PDF2Go | Online consumer PDF editing services | Flagged |
| Adobe Acrobat DC (edit mode) | Desktop PDF editor | Flagged |
| Foxit PDF Editor, Foxit PhantomPDF | Desktop PDF editor | Flagged |
| LibreOffice Draw, LibreOffice Writer | Open-source desktop office suite | Flagged |
| Microsoft Word, Microsoft Print to PDF | Consumer document software | Flagged |
| (blank or stripped) | Metadata removed — may indicate deliberate scrubbing | Unknown — review |
India-Specific Context
India’s banking sector presents a wide range of metadata patterns. HDFC Bank statements typically carry Finacle or iText signatures. ICICI Bank statements commonly show Oracle FLEXCUBE or Jasper Reports. SBI statements vary by branch reporting system but consistently carry known banking software signatures.
Co-operative banks and Regional Rural Banks (RRBs) present more variability. Some generate statements through third-party reporting software that produces legitimate but less recognisable Creator values. In these cases, the metadata verdict is classified as Unknown rather than Flagged, and balance chain verification becomes the primary check.
The RBI Master Direction on KYC requires regulated entities to verify the authenticity of documents submitted by customers. Metadata inspection is one structured way to satisfy that verification obligation for digitally submitted bank statements.
Automated bank statement fraud detection that inspects PDF metadata on every uploaded file gives credit teams a consistent, documented check — one that applies the same standard to every file rather than relying on an analyst’s memory to check document properties.
The bank statement analysis platform runs metadata inspection as part of a layered fraud signal review that also covers balance chain verification, transaction date anomalies, and digit-pattern forensics — so no single signal is relied on as a sole indicator.