Intelligent document processing for commercial lending

20 hours a file shouldn't
be data entry.

We build IDP and workflow automation platforms that turn unstructured financial documents — tax returns, statements, loan files — into underwriting-ready data. Engineered end to end: computer vision, custom-trained extraction models, and the workflow engine that acts on them.

Talk to an engineer Read the full story

Documentcommercial_loan_application_2024.pdf — page 4 of 38100s of files/mo

Manual review

~25 hrs/file

Gross Revenue — hand-keyed from PDFanalyst entry
EBITDA — recalculated manuallyanalyst entry
Working Capital — cross-checked by eye~7% error rate

IDP extraction

99.5% accurate

Gross Revenue — auto-extractedverified
EBITDA — auto-extractedverified
Risk score — generated, fast-trackedlow risk

The story

Ten days to say yes, while fintechs said
it in one

The client is a mid-sized commercial finance firm in the North American middle market, underwriting hundreds of business-credit and asset-backed loan applications a month. Due diligence — verifying financial statements, tax returns, debt schedules — was still entirely manual.

Analysts spent 20–30 hours per client file just aggregating and keying in data from unstructured documents. Pre-approval decisions averaged 7 to 10 business days, while agile fintech competitors were quoting in one. Manual entry also carried a 7% error rate in the numbers feeding risk scoring — a compliance exposure, not just a speed problem.

We started with a full audit of the firm's document archive and legacy systems — because the historical records had inconsistent date formats, currencies, and naming conventions, and no extraction model would hold up on top of that. We normalized the archive first, then trained computer-vision and TensorFlow extraction models on the client's own documents, wired into a microservices platform on AWS with a workflow engine that auto-scores risk and fast-tracks low-risk files.

The trade-off we made explicit up front: a generic OCR tool would have shipped in weeks but never cleared 99% accuracy on their document mix. We built and continuously retrain a custom model instead, through an MLOps pipeline that validates accuracy on every iteration.

Client: North American commercial NBFC, middle-market lending
Core Stack: Computer vision, TensorFlow, AWS microservices, MLOps pipeline
Before: 20–30 hrs/file, 7–10 day Time-to-Yes, ~7% error rate
Ongoing: Model retrains continuously; accuracy validated every iteration

How it was built

Four phases, in the order they
actually happened

Auditing the document archive
Before any model, a full audit of years of records — inconsistent date formats, currencies, and naming conventions had to be normalized or extraction accuracy would never hold in production.
Training custom extraction models
Computer-vision and TensorFlow models trained on the client's own historical documents, not a generic pretrained OCR tool — the only way to clear 99%+ accuracy on their specific document mix.
Building the workflow platform
A microservices platform on AWS wraps the extraction models, with a workflow engine that auto-scores risk and fast-tracks low-risk files straight to approval.
Continuous MLOps retraining
An MLOps pipeline validates accuracy on every iteration, so the model keeps pace as document layouts and lending regulations change instead of degrading after launch.

higher underwriter throughput: 35%
reduction in manual data-entry effort: 90%
data extraction accuracy, maintained: 99.5%

How we scope work

What we say no to

We Won't
start building an extraction model before a document and data-infrastructure audit. If your archive is too inconsistent to train against, we'll tell you that first — even though an off-the-shelf OCR tool is faster to sell.
We Won't
pitch a full digital transformation program when the actual problem is one broken layer of your stack. Most engagements here start and end at one system — not a six-workstream retainer.
We Will
show you the accuracy benchmark and where the model still gets it wrong. A system that's never shown to fail in an edge case hasn't been tested honestly.