Loan teams spend substantial effort gathering statements, payslips, tax documents, contracts and explanations before an authorised person can assess a case. AI can reduce that preparation work when every extracted fact remains tied to its source and uncertainty becomes a visible exception.
This guide describes a proposed pattern for consumer, mortgage, vehicle, business and specialist lending. It is not legal advice or a claim about Binarify client results. Affordability, creditworthiness, fair-lending, privacy and record requirements vary by product and jurisdiction. The lender’s authorised owners must define and approve them. See our AI consultancy for financial services for the wider service.
Choose a preparation outcome
“AI underwriting” can imply that a model decides who receives credit. A safer and more measurable first scope is document and case preparation:
Produce a review-ready application with each material fact linked to its document and page, deterministic calculations reconciled, missing or conflicting evidence listed, and no approval, price or affordability decision made by the preparation system.
The boundary matters. The FCA explains that responsibility for assessing creditworthiness, including affordability, falls on the lender. In the United States, the CFPB says creditors using complex algorithms must still provide specific principal reasons for adverse action. An opaque preparation layer can weaken the lender’s ability to understand the evidence and explain its decision.
A controlled loan-document workflow
1. Create one application evidence set
Connect portal uploads, broker submissions, email attachments and branch scans to a stable application ID. Preserve the original file, filename, source, time and person or channel that supplied it.
Keep applicant declarations separate from extracted evidence. “Applicant entered monthly rent of $1,500” and “bank statement appears to show a $1,525 payment” are separate observations until the lender’s approved process resolves the difference.
Check file safety, readability, duplication and page completeness before extraction. A truncated statement or document attached to the wrong application should create an exception.
2. Classify supported documents
Define the document types and versions in scope. These may include payslips, bank statements, tax returns, employment letters, company accounts, tenancy agreements, purchase contracts and identification documents.
Store the proposed class, confidence, model version and reviewer correction. Allow “unknown” and “multiple document types.” A forced label can apply the wrong schema and produce plausible but false fields.
3. Extract facts with field-level provenance
Define an approved schema for each document. A payslip may contain employer, pay period, gross pay, deductions and net pay. A bank statement may contain account holder, period, opening and closing balances, and transaction rows.
For each value, keep:
- document and page;
- visible source region where practical;
- raw text and normalised value;
- extraction and validation method;
- confidence or exception state; and
- reviewer correction and time.
Use deterministic code for arithmetic, dates, totals and policy rules. A language model may help interpret layouts or descriptions, but it should not calculate affordability or silently repair numbers that fail to reconcile.
4. Reconcile facts and calculations
Compare declared information, submitted evidence and approved third-party data. Examples include:
- employer and income across the application, payslips and bank credits;
- statement period, running balance and transaction totals;
- recurring commitments and declared expenditure;
- business revenue across accounts and financial statements;
- purchase price, deposit and requested loan amount; and
- identity or address fields already reviewed during onboarding.
Show matches, material differences and missing evidence. Do not collapse them into a single “document risk score.” The underwriter needs to see which fact is uncertain and why.
5. Detect exceptions without alleging misconduct
Rules and models can flag possible alteration, duplicate pages, inconsistent fonts, unexplained credits, missing periods or a mismatch between declared and observed facts. Present these as evidence checks.
Do not label an applicant fraudulent from one anomaly. Define the next step for each exception: request another document, ask for an explanation, verify through an approved source or refer to a specialist team. Limit internal fraud logic to people with a legitimate need to know.
6. Prepare the underwriter workspace
The case view should contain:
- requested product, amount and application stage;
- applicant declarations;
- received documents and completeness state;
- extracted facts with links to source pages;
- reconciled calculations and their formulas;
- missing, conflicting or unsupported evidence;
- approved third-party results and timestamps;
- previous questions and applicant responses; and
- the next deadline and responsible reviewer.
The summary should organise evidence. It should not recommend approval unless the lender has separately governed, validated and authorised that decision process. Even then, the decision owner must be able to understand the inputs, apply exceptions and meet explanation obligations.
7. Keep the decision and communication controlled
Authorised staff apply the lender’s policy to affordability, creditworthiness, eligibility, pricing, conditions and approval. Store their decision, reasons, evidence and any override separately from the generated case summary.
If evidence is missing, the workflow can draft a precise request using approved wording. If the lender takes adverse action, the communication must reflect the actual principal reasons under applicable law. A generic reason chosen because the model cannot explain itself is not a reliable control.
8. Write approved results to the system of record
Use supported APIs and field-level permissions. The document component may attach a sourced fact, open an exception or mark a preparation task complete. It should not change an application to approved, declined or funded.
Use idempotency controls for retries, reconcile failed writes and log every automated and human change. Apply the lender’s retention and deletion policy to original documents, extracted data, prompts and temporary files.
Binarify loan evidence ledger
This proposed ledger gives an underwriter one row per fact that could affect the case. It is a design artifact to adapt with lending, compliance and risk owners.
| Evidence item | Applicant assertion | Source and location | Normalised fact | Validation | Exception and owner |
|---|---|---|---|---|---|
| Employment income | Amount and frequency entered | Payslip 2, page 1; bank statement, rows linked | Approved period and currency | Arithmetic and cross-source comparison | Material variance to underwriter |
| Recurring commitment | Declared monthly amount | Application field; statement transactions | Amount and recurrence window | Deterministic grouping, reviewer confirms | Unmatched item to case owner |
| Deposit | Amount and source declared | Account statement and transfer evidence | Verified amount and date | Reconciliation to purchase | Source question to specialist review |
| Business revenue | Turnover entered | Accounts and account credits | Period-aligned figures | Formula and duplicate check | Period gap to business underwriter |
| Document validity | Document claimed | Original file and metadata | Type, issuer, date, completeness | Approved document rules | Unknown or suspected alteration to trained team |
Each row should retain its history. Replacing a value without preserving the earlier observation makes later quality review and decision explanation harder.
Integrate with the lending stack
| System | Read | Controlled write |
|---|---|---|
| Application portal or broker channel | Form data, uploads, declarations | Specific evidence request and status |
| Document store | Originals, metadata, retention state | Classification and reviewed extraction |
| Loan origination system | Case, product, stage and policy version | Evidence facts, exceptions and review task |
| Open-banking or data provider | Consented records, coverage and timestamp | Provider result reference |
| Credit or fraud provider | Approved response and reason fields | New check only under approved trigger |
| Decision and notice service | Actual decision factors and templates | Authorised decision and communication only |
Review data residency, applicant consent or lawful basis, vendor retention, sub-processors, access control and incident terms. Confirm how a supplier change or model update will be tested before it affects production extraction.
Measure case preparation and decision support
Take a baseline from comparable products and channels. Measure the complete path to a supportable decision rather than pages processed.
Flow and capacity
- median and 90th-percentile time from submission to review-ready;
- handling minutes for document preparation and later correction;
- applications waiting by age and missing-evidence reason;
- first-review completeness; and
- avoidable applicant follow-ups.
Evidence quality
- field accuracy by document and field type;
- material facts or conflicts missed in quality review;
- false exceptions and unnecessary document requests;
- calculation reconciliation failures;
- reviewer correction and override rate; and
- errors found after the credit decision.
Decision and customer controls
- adverse-action or decline reasons supported by the actual decision record;
- complaints and appeals linked to evidence or explanation errors;
- outcomes and error rates across tested customer groups and channels;
- access, retention and failed-write incidents; and
- cases completed through an alternative route when digital evidence fails.
Accuracy should be assessed on a representative test set that includes poor scans, combined files, variable income, joint applications, self-employed applicants, foreign documents, unexplained transactions, legitimate name differences and contradictory evidence.
Pilot in shadow mode
Choose one product, one application channel and a small set of high-volume documents. Let the system prepare cases while the current process remains authoritative. Compare both outputs at field and case level.
Before assisted use, agree the schemas, source requirements, materiality thresholds, human roles, adverse-action data path, quality sampling, outage procedure and rollback owner. Validate every integration write and confirm that underwriters can inspect the evidence faster than they could before.
For identity and business evidence earlier in the journey, read AI customer onboarding and KYC document processing. Use the financial-services AI ROI guide to build the investment case after its baseline is available. Explore our financial-services AI consultancy or book a 30-minute conversation about one loan queue.