Bank statement & payslip analysis for lending

Loan files still arrive as a stack of PDFs, scans and phone photos: three months of statements, payslips, a tax assessment. Document AI turns them into structured, checked data — transactions, balances, salary credits, fixed obligations — so the credit decision is prepared in minutes instead of being typed in by hand. The extraction itself is low-risk; the moment its output feeds a creditworthiness decision about a natural person, EU rules for high-risk AI, consumer-credit law and GDPR Art. 22 apply.

Problem & value

• Today: brokers, banks, leasing firms and fintechs collect income and account documents, then analysts re-key transactions into spreadsheets, categorise salary, rent and loan repayments and compare payslip to salary credit. This is slow, error-prone and a typical bottleneck in consumer, mortgage and SME lending.
• AI value: template-free parsing of any bank's layout, automatic reconciliation (opening balance + transactions = closing balance), detection of recurring income and obligations, and first consistency checks. Staff handle exceptions and decisions.
• Alternative data path: in the EU, PSD2 account-information services (AIS) deliver transactions directly from the bank with customer consent, e.g. via finAPI (Germany; BaFin-registered AISP, offers categorisation and cash-flow/risk reports) [5]. PDFs remain necessary where the customer has no online access, for foreign or small institutions, for payslips, and as a fallback.
• No generic, independently verified accuracy or time-saving figures are cited here; vendor claims should be tested on your own documents (see Getting started).

Variants

• Consumer credit / BNPL / auto finance: 3 months of statements plus payslips; high volume, fast decision.
• Mortgage and property finance: longer histories, self-employment (tax assessment, BWA) → overlaps with DOC-012; broker platforms bundle the file.
• SME and leasing: business account statements, cash-flow analysis and seasonality; feeds credit memo preparation (AGENT-028).
• Tenant and landlord screening: income proof for rental applications (data-minimisation is critical).
• Insurers / credit insurers, marketplaces, payroll-advance providers: same extraction, different decision logic.
• Public sector: benefit and subsidy applications that require income proof → DOC-003.

How it works

1. intake (portal upload / email / broker platform / PSD2 AIS)
2. document type classification (statement | payslip | tax notice | other) [DOC-008 pattern]
3. authenticity pre-checks (PDF metadata, fonts, producer, edit traces) [-> ANOM-017]
4. OCR + layout parsing, table reconstruction across pages
5. field extraction against schema (VLM / document model)
6. validation (balance chain, date continuity, IBAN checksum, gross-net-deductions arithmetic)
7. transaction categorisation (salary, rent, loan, insurance, gambling, transfers between own accounts)
8. income verification (payslip net vs. salary credit; YTD vs. months)
9. summary + flags
10. credit officer review (source highlighted)
11. decision logic (policy rules / scorecard, separate system)
12. decision with human oversight

• Extraction: a document-parsing model or VLM returns JSON against a fixed schema; deterministic code verifies arithmetic. Multi-page tables, running balances and split lines are the hard part.
• Categorisation: text classifier or LLM with rules on counterparty and purpose text (see LANG-033 for the shared transaction-categorisation component).
• Human-in-the-loop: low-confidence fields, balance-chain breaks and tamper flags go to review; the decision on a credit application stays with a trained person or a documented, contestable decision process.

Data preparation

The inputs are bank statements and payslips that arrive as PDFs, scans or phone photos by e-mail, customer portal or broker platform, and end up in the DMS, the loan-origination system or on file shares. Where PSD2 account data is available, it avoids OCR altogether. Typical gaps are skewed phone photos, multi-bank layouts, password-protected PDFs, missing pages, duplicates of the same statement and application data that is not linked to the documents. Little historic data is needed, because modern document models work without training.

Preparation steps: - Fix a clean intake: one upload channel, mandatory document type and applicant ID, rejection of unreadable files at the door. - Collect 50-100 real, representative documents (with consent or pseudonymised, see PREP-022) as test set with the correct values, see PREP-018. - Export loan policy parameters (income multiples, obligations) from the loan system, see PREP-005. - Define retention and access rights for stored statements, see PREP-025.

Rough share of effort: about 15-20 percent, mostly intake and test set. Tools: the vendor's own pre-processing, or Docling/Tesseract for self-built pipelines. See also DOC-018 and GUIDE-003.

Implementation paths

Which path for whom

• SMB (brokers, small lenders): Path A, because mature EU-hostable statement and payslip OCR products exist at SMB prices and the process is standard.
• Enterprise (banks, insurers): Path B, because extraction must plug into the own loan-origination system and credit policy and volumes make a tailored pipeline worthwhile.
• Developer: Path B, because document-AI APIs plus an LLM validation step are the fastest way to build and embed the service.

Path A — Buy

• Document AI / OCR vendors: Mindee (Paris; bank-statement and payslip OCR APIs, EU or US hosting selectable) [4], Doxis AI Solutions (formerly Klippa; Netherlands; proof-of-income, bank-statement reconciliation and mortgage-processing use cases) [3], plus ABBYY Vantage, Rossum, Hypatos (Munich) and DMS/ECM suites such as DocuWare or d.velop. Check: German/European statement layouts, line-item (transaction) accuracy, EU hosting, retention settings, fraud/tamper checks.
• Open banking and data intelligence (EU): finAPI (Germany) [5]; other PSD2 aggregators such as Tink or GoCardless Bank Account Data are also used — verify licence status and current offering before contracting.
• Lending platforms: loan-origination systems and broker platforms increasingly embed statement analysis; ask which model and which subprocessors are used.
• Choose A when: volumes are moderate, you do not want to run a model pipeline, and the vendor is contractually bound as processor (Art. 28 GDPR).

Path B — Build on cloud APIs

• Specialised document models: Azure AI Document Intelligence offers prebuilt bank-statement and pay-stub models (prebuilt-bankStatement.us, prebuilt-payStub.us), but the documentation lists only the en-us locale, so they do not cover German or other EU layouts out of the box [1][2]. For EU documents use the Layout/Read models plus a custom extraction model or an LLM step. AWS Textract has an Analyze Lending feature for loan packages (classification and extraction of income and bank documents) aimed at US document types; check region availability and EU suitability before relying on it.
• General VLM extraction: send page images and a JSON schema to a multimodal model (Claude, Gemini, GPT, Mistral) with structured outputs and EU data residency; recompute all totals in code.
• Orchestration: n8n / Power Automate / custom service; queue and review UI; audit log of extracted vs. corrected values.
• Choose B when: you need custom schemas (e.g. specific policy ratios) and no hard on-prem constraint.

Path C — Self-host (open source)

• Parsing: Docling (MIT) with Granite-Docling (258M parameters, Apache 2.0) for layout, tables and OCR [6][7]; alternatives PaddleOCR-VL, MinerU, olmOCR.
• Extraction: Qwen3-VL (Apache 2.0; 2B–32B dense and 30B-A3B / 235B-A22B MoE variants, OCR in 32 languages) served via vLLM, constrained JSON output [8].
• Workflow: n8n or Camunda; PII-aware logging; encrypted storage with deletion jobs.
• Hardware: HW2 (one 24–32 GB GPU) for an 8B–32B-class quantised VLM; HW3 for higher throughput. Typical when a bank or lender must not send statements to third parties.

Path D — Custom training

Worth it only for high volume with recurring odd layouts (small regional banks, foreign statements, poor scans). Fine-tune a small VLM or layout model on a few hundred to a few thousand labelled pages per layout family; reviewer corrections are the training data. Never train on live applicant data without a clear legal basis and retention rule.

State of the art (2026)

• Template-free VLM parsing is the default; header fields and clean tables are largely solved, while long multi-page transaction tables, merged/wrapped lines, photographed statements, dark mode screenshots and mixed languages still produce silent errors. Deterministic checks (balance chain, sums) are the most effective safety net.
• Open banking beats OCR where available, because data are structured and signed by the bank; PDF analysis is the complement. The EU Financial Data Access (FiDA) proposal would extend data sharing beyond payment accounts; its final shape and timeline should be checked.
• Document forgery is the main adversarial problem: edited PDFs and AI-generated statements are a known issue for lenders; authenticity checks (metadata, font consistency, cross-checking against PSD2 data or payslip) belong in the pipeline (ANOM-017).
• Limits: the extraction model is not a credit model; categorisation of ambiguous transfers (own-account transfers, private loans from family) is error-prone; models can invent plausible values for unreadable cells — require "unreadable" as a valid output.

Shared resources & combinations

• Same stack (ocr-docparse + vlm + llm-general): DOC-001 invoices, DOC-003 forms, DOC-004 ID documents, DOC-012 financial statements — one self-hosted VLM server (HW2/HW3) serves them all.
• Upstream/downstream: DOC-004 and AGENT-015 (onboarding & KYC), ANOM-017 (document tampering), ANOM-037 (payroll plausibility), PRED-009 (scorecard / default prediction), AGENT-028 (credit memo agent), LANG-033 (transaction categorisation).
• Privacy tooling: DOC-018 for redaction of data not needed for the decision (e.g. third-party names, health-related transfers) before storage or sharing.
• Shared building blocks: document classification, schema-constrained extraction, review UI with source highlighting, audit log, PII-safe storage.

Effort, cost & KPIs

• Path A: days to weeks; per-document or per-application pricing.
• Path B: 1–3 months incl. review UI, integration with the loan system and testing on real documents.
• Path C: 2–5 months; GPU server, security hardening and ongoing evaluation.
• KPIs: field-level and transaction-level accuracy, share of files without manual correction, balance-chain pass rate, time from complete file to decision-ready summary, forgery detections, override rate by credit officers, complaints/contestations, bias monitoring of downstream decisions.

People & change

Involve management (budget, risk appetite) and the department lead for credit processing first, then IT (integration, accounts), the DPO and legal/compliance before any pilot, because bank statements and payslips are personal financial data: a DPIA is likely, and an AVV (Art. 28 GDPR) is needed with every vendor. Credit officers and brokers are the end users and should shape the review screen from the start.

Works council: depends. The system is aimed at applicant documents, not employees, but if it logs which officer corrects or approves what, it is objectively suited to monitor performance and §87(1) no. 6 BetrVG applies (BAG); §90(1) no. 3 additionally requires timely information about AI in work processes. A short works agreement settles this early.

Support AI literacy (Art. 4 AI Act) with a short training on reading confidence scores and typical OCR errors. Communicate that the tool prepares figures but the credit officer decides; run a pilot with one team and 2-3 weeks of parallel work. Typical concerns are job loss and blame for AI errors: address both by keeping the human approval step and measuring the time saved for more consulting. Data protection: tell applicants about the processing. Guides: GUIDE-005, GUIDE-004, GUIDE-008.

Risks, regulation & compliance

• EU AI Act: extraction alone (reading a PDF) is not itself listed. Annex III point 5(b) classifies AI systems used to evaluate the creditworthiness of natural persons or establish their credit score as high-risk, with an exception for detecting financial fraud [9][10]. A pipeline whose income/affordability output is an input to the credit assessment of a consumer is therefore likely in scope; a purely clerical OCR tool for corporate borrowers or an internal fraud check may not be. Classify per deployment (hence depends). High-risk duties: risk management, data governance, logging, human oversight, accuracy and documentation; Annex III obligations apply from 2 Dec 2027 (Digital Omnibus on AI, Reg. (EU) 2026/1744).
• Consumer Credit Directive (EU) 2023/2225: creditworthiness assessments must rely on relevant and accurate information; consumers have rights regarding automated processing (human intervention, explanation, contesting). Member-state rules apply from November 2026 — confirm against national transposition [11].
• GDPR: statements reveal highly sensitive details (health, religion, union dues, politics via transfers). Data minimisation, purpose limitation, DPIA, processor agreements, EU hosting. Art. 22 limits solely automated decisions; the CJEU SCHUFA ruling (C-634/21) treats a score that decisively shapes a lender's decision as itself an automated decision. Do not use special-category inferences.
• Banking supervision: EBA Guidelines on loan origination and monitoring require sound, documented creditworthiness assessment and data verification [12]; DORA for ICT third-party risk at financial entities; BaFin MaRisk in Germany.
• PSD2: access via licensed AISPs with explicit consent; do not use screen scraping with customer credentials.
• Mitigations: deterministic checks, human review of declines, documented decision rules, bias testing, deletion after the retention period, audit log of AI output vs. final decision.

Getting started

1. Collect 100–200 real (consented or anonymised) statements and payslips from your top 10 banks and employers, including bad scans, and define the target schema and ground truth.
2. Decide whether PSD2 account data can replace part of the PDFs; if so, integrate it first.
3. Benchmark 2–3 Path A vendors and one VLM approach on that set; measure transaction-level accuracy and balance-chain pass rate.
4. Classify the system under AI Act Annex III 5(b) and GDPR (DPIA); define human oversight and contestation procedures.
5. Pilot with a review screen, log corrections, then widen scope and add authenticity checks.

Sources

1. Microsoft Learn — Document Intelligence bank statement model (en-us only) — https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/bank-statement
2. Microsoft Learn — Document Intelligence payStub model — https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/pay-stub
3. Doxis AI Solutions (formerly Klippa) — https://www.klippa.com/en/
4. Mindee — bank statement and payslip OCR — https://www.mindee.com/
5. finAPI — open finance APIs (Germany) — https://www.finapi.io/en/
6. Docling project — https://github.com/docling-project/docling
7. IBM — Granite-Docling announcement — https://www.ibm.com/new/announcements/granite-docling-end-to-end-document-conversion
8. QwenLM — Qwen3-VL — https://github.com/QwenLM/Qwen3-VL
9. AI Act Annex III (point 5(b), creditworthiness) — https://artificialintelligenceact.eu/annex/3/
10. AI Act Recital 58 — https://artificialintelligenceact.eu/recital/58/
11. Directive (EU) 2023/2225 on credit agreements for consumers — https://eur-lex.europa.eu/eli/dir/2023/2225/oj
12. EBA — Guidelines on loan origination and monitoring — https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/credit-risk/guidelines-loan-origination-and-monitoring