Regional Bank Cuts Document Processing Time by 73%

Context

A regional bank with $4B in assets and 35 branch locations was struggling to keep pace with loan document processing volume. Their commercial lending team reviewed an average of 2,400 documents per month—loan applications, financial statements, title reports, appraisals, and compliance filings. Each document required manual review by a loan processor, data extraction into their loan origination system, and a compliance check against regulatory requirements.

The team of eight loan processors was at capacity. Turnaround times had stretched from 24 hours to 72 hours during peak periods, and the error rate on data extraction had crept up to 8.2% as the team handled increasing volume under pressure. Hiring additional processors was approved but difficult—experienced loan processors are hard to find in a competitive market, and training takes 4-6 months.

Constraints

This engagement operated under constraints that are typical for financial services but require careful architecture:

• Regulatory compliance. All document handling had to comply with federal lending regulations, including data retention and audit trail requirements. The system needed to be explainable—regulators could ask why a document was flagged or how data was extracted.
• Data residency. All data had to remain within the bank’s Azure tenant. No document content could leave their environment or be used for model training.
• Integration with legacy systems. The bank’s loan origination system was a 15-year-old platform with a limited API. Any solution needed to work with it, not replace it.
• Human oversight requirement. The bank’s compliance team required that no document processing happen without human review. The system could assist and pre-populate, but a human had to approve every extraction before it entered the loan origination system.

Approach

We structured the engagement in three phases over eight weeks.

Phase 1: Document analysis and pipeline design (weeks 1-2). We analyzed 500 representative documents across all types the team processes, mapped the current workflow step by step, and identified where AI could reduce time without removing necessary human judgment. The key insight was that most processing time was spent on extraction and formatting, not on the review decisions themselves.

Phase 2: Pipeline development and integration (weeks 3-6). We built the document processing pipeline using Azure OpenAI for extraction and classification, FastAPI for the processing service, and PostgreSQL for the extraction database and audit log. The system classifies incoming documents by type, extracts relevant fields using type-specific extraction prompts, validates extracted data against business rules, and presents results to loan processors in a review interface.

Phase 3: Testing, calibration, and rollout (weeks 7-8). We ran the system in parallel with manual processing for two weeks, comparing extraction accuracy and processing time. Processors reviewed every AI extraction and flagged errors, which we used to refine extraction prompts and validation rules.

Architecture

The system follows a straightforward pipeline architecture:

1. Document ingestion. Scanned documents and PDFs arrive via Azure Blob Storage. An event-triggered function classifies each document by type (application, financial statement, appraisal, etc.) and routes it to the appropriate extraction pipeline.
2. Extraction service. A FastAPI service manages document processing. Each document type has a tailored extraction prompt that specifies the fields to extract, validation rules, and confidence thresholds. Azure OpenAI processes the document and returns structured extraction results.
3. Validation layer. Extracted data passes through business rules—checking for required fields, value ranges, cross-field consistency, and format compliance. Failed validations are flagged for processor attention.
4. Review interface. Processors see the original document alongside extracted data, with confidence scores and validation results. They can approve, correct, or reject each extraction. Every action is logged for the audit trail.
5. LOS integration. Approved extractions are formatted and pushed to the loan origination system via its API. A reconciliation check confirms the data landed correctly.

Implementation Details

Several implementation decisions shaped the system’s reliability:

Confidence scoring. Every extracted field carries a confidence score. Fields below 85% confidence are highlighted for processor attention. Fields below 70% are marked as requiring manual entry. These thresholds were calibrated during the parallel processing phase based on actual error rates.

Document quality handling. Scanned documents vary in quality. We built a pre-processing step that assesses scan quality and applies OCR enhancement where needed. Documents below a quality threshold are routed for manual processing with a note about the quality issue, rather than attempting unreliable extraction.

Audit trail. Every document processing event is logged—ingestion, classification, extraction, validation results, processor actions, and LOS submission. The bank’s compliance team can trace any document from arrival through final submission, including the AI’s extraction and the processor’s review.

Results

After 90 days in production, the results were clear:

• Processing time dropped from 45 minutes to 12 minutes per document. The bulk of the savings came from automated extraction and pre-population of the review interface. Processors spent their time reviewing and approving rather than typing and formatting.
• Error rate decreased from 8.2% to 1.1%. Most manual errors were transcription mistakes—typos, transposed digits, missed fields. The AI extraction eliminated most of these, and the validation layer caught inconsistencies that humans missed under volume pressure.
• Monthly capacity increased from 2,400 to 9,000 documents without adding staff. The existing team could handle 3.75x the volume, which eliminated the immediate hiring need and gave the bank headroom for growth.
• Turnaround time returned to under 24 hours even during peak periods.

Lessons

Start with the boring parts. The highest-value automation wasn’t the most technically impressive—it was eliminating copy-paste from documents into forms. Processors were spending 60% of their time on extraction and 40% on review. Automating extraction freed the majority of their time.

Calibration needs real volume. The extraction prompts that worked well on our test set of 500 documents needed adjustment once they hit production volume and the full variety of document formats, scan qualities, and edge cases. Building in a calibration period was essential.

Processors are the best testers. The loan processors identified extraction failures and edge cases faster than any automated test suite. Their feedback during the parallel processing phase improved accuracy significantly more than our internal testing had.

Next Steps

The bank is planning two extensions: expanding the system to handle mortgage documents (a different document set with different extraction requirements) and building a compliance monitoring layer that flags potential regulatory issues during extraction rather than in a separate review step.

Security and Data Handling

All document processing occurs within the bank’s Azure tenant. Document content is processed by Azure OpenAI deployed within the tenant and is not used for model training or accessible outside the bank’s environment. The system uses Azure’s encryption at rest and in transit, and access is controlled through the bank’s existing Active Directory integration. Audit logs are retained per the bank’s regulatory retention schedule.

This case study represents a real engagement with details modified to protect client confidentiality. Specific metrics are representative of actual results.