Case study

Cutting Annuity Application Processing from Four Hours to Eight Minutes

Outcome

Processing time cut from 4 hours to 8 minutes per application

Client

Insurance and annuities provider (name withheld)

Industry

Fintech, insurance and annuities

Status

In production

My role

Architecture and implementation lead

Published

September 1, 2026

The client is not named under contractual confidentiality. Where this write-up says "we", it refers to the delivery team I led; the architecture decisions described are mine.

Context

The client issues annuity products, and a meaningful share of new applications still arrive on paper, filled out by hand by policyholders and agents in the field. Before this project, every one of those applications went through a manual review process: a trained operator read the handwriting, checked boxes against the form logic, and typed the result into the client’s policy administration system. That process took approximately four hours per application.

Four hours does not sound catastrophic until you multiply it by application volume and realize it sets a hard ceiling on how fast the business can onboard new policyholders. It also meant operational cost scaled linearly with volume: more applications meant proportionally more reviewer hours, with no way to get ahead of a surge. The business wanted the throughput of automation without giving up the accuracy a trained human reviewer brings to a form full of handwritten numbers, ambiguous checkboxes, and free text.

The Problem

Handwritten financial forms are a genuinely hard input for automation, for reasons that are easy to underestimate from the outside. Handwriting varies enormously between applicants. Checkboxes get filled in with anything from a clean tick to a scribble that partially overlaps two boxes. Numeric fields use domain-specific conventions and abbreviations that a general-purpose model has not seen enough of in training to get consistently right. And because this is an insurance application, a wrong extraction does not just cost time to fix later, it can produce an incorrect policy record.

Before this system, there was no automation at all in the read-and-transcribe step: it was fully manual. That meant no existing pipeline to improve incrementally, and no historical error data to mine for common failure patterns. We had to design the whole read path from a blank page, and we had to be honest that a single generic vision call was not going to hit the accuracy bar this use case demanded, especially on the specific financial abbreviations and checkbox conventions this client’s forms used.

Architecture

We built the pipeline as four coordinated stages rather than one large model call, specifically so that each stage’s accuracy problem could be solved with the tool suited to it.

First, a custom-trained convolutional neural network classifies each incoming page. This tells the rest of the pipeline what kind of document element it is looking at before any extraction is attempted, which matters because a multi-page application mixes different form types and free-text pages.

Second, Anthropic’s Claude Opus 4.5 model, using its vision capabilities, does the actual reading: handwritten numbers, checkbox states, and free-text fields, converted into structured markdown. This is the step where most of the “reading a human’s handwriting” burden sits, and a frontier vision model earns its cost here.

Third, AWS Nova 2 Pro takes that markdown and maps it into the exact structured schema the client’s downstream policy administration system expects. Keeping this as its own step meant schema changes on the client side did not require touching the OCR stage at all.

Fourth, and the part I am most proud of: a monitored optimization loop. Using Langfuse observability across a multi-model framework spanning Claude, Nova, and DeepSeek, the system continuously watches its own accuracy, identifies which prompt versions are producing errors, and proposes and tests improvements against a held-out validation set before promoting any change. Nothing gets promoted to production just because it looked better on paper; it has to clear that validation bar first. Alongside this, we fine-tuned a domain-specific model on AWS SageMaker using LoRA, specifically to improve handwritten field recognition where general-purpose models were inconsistent on this client’s financial abbreviations and checkbox conventions.

Results

Processing time dropped from four hours to eight minutes per application, a change that moved the workflow from a bottleneck the business had to staff around to a step that keeps pace with intake. Accuracy on checkbox detection, handwritten numbers, and form field extraction has remained high since launch, and continues to improve as the optimization loop accumulates more corrections and passes each change through held-out evaluation, with no manual prompt retuning required from an engineer. The client’s operators shifted from transcribing every application by hand to reviewing the flagged edge cases the pipeline is not confident about, which is a much better use of a trained reviewer’s time than full manual transcription.

What I Would Do Differently

If I were starting this again, I would build the human-review sampling dashboard on day one instead of adding it after launch. We got the optimization loop right early, but for the first few weeks we relied on ad hoc spot checks to build confidence in it before opening it up to the business, and a proper sampling and disagreement-tracking view from the start would have shortened that trust-building period considerably. It is a small operational gap, not an architectural one, but it is the kind of thing that is cheap to build early and annoying to retrofit once a system is already carrying production volume.