The problem
Underwriters spending their time transcribing, not judging.
Document volume is brutal
A single business-loan file can arrive with dozens of documents — months of bank statements, years of tax returns, financials, KYC, property papers — in formats that vary by issuer and by year.
Turnaround lags the market
Manual review takes days against competitors promising same-day decisions. A meaningful share of applicants drop off during the wait.
Inconsistent decisions
Two underwriters can reach different conclusions on the same file, and audit sampling finds calculation errors in a meaningful share of approved cases.
Fraud slips through
Doctored statements and inflated income figures are common. Catching them needs cross-document consistency checks that no one has time to do by hand.
The high-level solution
A five-stage document-to-decision pipeline.
Ingest and classify every document, extract fields with confidence scores and citations, verify with a set of specialist agents, decide with a deterministic policy engine, and route to a human based on how confident the whole chain actually is. The policy engine is code, not an LLM. Credit decisions have to be reproducible and defensible under fair-lending expectations. The model assembles evidence; the rules decide — and every arithmetic figure (balances, ratios, income) is computed in code, never generated.
1 & 2 — Ingest, extract
Documents are classified, then read: layout-aware OCR for structure, an LLM for semantic extraction — every field carries a confidence score and a source citation.
3 — Verify
Specialist agents each own one domain: financial analysis, income reconciliation, cross-document consistency, fraud/tampering, and policy compliance — running in parallel, stateless, evidence-backed.
4 & 5 — Decide, review
A deterministic policy engine — not the model — produces the recommendation. Confidence and findings route the file straight through, to a light-touch review, or to a full manual read.
Architecture
From upload to decision.
Document processing pipeline
Documents arrive → classify → extract (OCR + LLM) → verify (parallel agents) → policy decision. A single bad scan or corrupt page fails in isolation and retries independently — it never fails the whole file.
Human review loop
Confidence & findings → route → straight-through / light-touch / full review → underwriter decision. Every underwriter correction is written back as labelled training data — the review queue compounds into a better extraction model over time.
Pipeline
How it got built.
Foundation
Secure document storage with immutable retention, a relational database, and identity/access controls.
Golden evaluation set
Hundreds of applications, manually annotated field-by-field, covering every document type and scan-quality tier. Built early — everything downstream is measured against it.
Extraction
Classify, extract with OCR plus LLM, then compute every derived figure in code. Evaluated against the golden set before moving on.
Verification agents
Five specialist agents, each with its own prompt, tool schema, and evaluation set.
Policy engine
Deterministic credit rules in versioned configuration, with a simulation mode to replay a policy change against months of history before it goes live.
Orchestration
Fan-out processing over every document with independent retry, error isolation, and a full execution history that doubles as the audit trail.
Human review
Confidence-routed review templates and a feedback loop that turns underwriter corrections into training data.
Underwriter workspace
Queue, split-screen document view, click-to-source citations, findings panel, and a decision API back to the loan origination system.
Outcomes
What moved.
Figures are illustrative engineering targets for this solution pattern, based on comparable production systems — not a guaranteed result for any specific deployment.
Turnaround (application → decision)
Before: 3–5 days → Target: Hours (fast-track: minutes)
Straight-through processing rate
Before: 0% → Target: 50–60%
Underwriter time per file
Before: ~95 min → Target: ~22 min blended
Calculation errors in approved files
Before: ~4% → Target: <0.5%
Applicant drop-off during underwriting
Before: ~22% → Target: 8–11%
Components
This engagement ran AWS-native, matched to the client's existing cloud estate — the same pattern deploys equally well on Azure or GCP.
Where the platform fits
Every pattern here has an action boundary — a block, an approval, a reply. That is exactly where Nikash's gate sits: claims checked deterministically before the action, and real outcomes fed back afterwards.
See the platform →