From 44% to 86%: How a Stalled AI Document-Processing Programme Was Rescued for a Leading Icelandic Bank

From 44% to 86% automation

A document-processing AI programme at a leading Icelandic bank was missing its targets and losing executive confidence. A ground-up rebuild took priority-loan automation from 44% to 86%, with zero recurrence of the failure that triggered it.

Nine months into production, the numbers were going the wrong way and the room was turning. This is the story of how a financial-services AI programme that had stalled at 44% automation was reframed, rebuilt and brought to 86%, and why the turnaround came down to engineering discipline and an honest working relationship in equal measure.

At a glance

• Client: A leading Icelandic bank, a universal bank serving households and businesses across Iceland (named withheld)
• Domain: AI-driven document processing across financial operations, including loans
• Platform: Microsoft Syntex for intelligent document processing
• Tarento's role: Diagnose, redesign and scale the automation programme end to end
• Team: Six people on the Tarento side, working across continents
• Hero outcome: Priority-loan automation lifted from 44% to 86%, with zero recurrence of the regression that started the engagement

The problem: a programme missing its targets and losing the room

The bank had deployed Microsoft Syntex to automate document processing across its financial operations. The target was 70% automation. Nine months into production, the reality was 44%.

Then, in July 2025, a deployment broke existing forms with no clear root cause. Automation dropped 15% overnight, and the monitoring in place caught the fall fifteen days too late. For a programme already behind plan, that was the tipping point. Executive confidence in the platform, and in the team behind it, was shaken.

This is the moment most engagements go one of two ways. You patch the symptoms and hope the numbers recover, or you stop, reframe the problem, and rebuild from first principles. Tarento and the bank chose the second path, and that decision shaped everything that followed.

The diagnosis: six root causes, one underlying mistake

A joint, ground-up review put the whole pipeline on the table rather than chasing the latest broken form. It surfaced six root causes:

1. Models that were too coarse, unable to tell closely related document types apart.
2. No scan pre-processing, so the models were reading raw, messy images.
3. A blanket 99% confidence threshold, which pushed almost everything to manual review regardless of risk.
4. No learning loop, so human corrections never fed back as a training signal.
5. Weak release gates, which let a damaging change reach production unchecked.
6. Drift from AI into rule-writing, with a new rule hand-written for every form variation.

Underneath all six sat a single mistake. The programme had been asking a rules-heavy system to read messy paper, without cleaning the paper first.

The playbook: six levers, applied in order

The rebuild was a deliberate sequence rather than a scramble of fixes. Six levers, each addressing a root cause, applied in order:

1. Family-level models that recognise groups of related documents instead of forcing one rigid template.
2. Scan pre-processing to clean and standardise images before the model ever sees them.
3. Field-level thresholds calibrated by risk, so a low-risk field clears automatically while a high-risk one still gets a human eye.
4. A weekly retrain loop, turning every human correction into training signal so the system improves itself.
5. Release gates with golden-document regression on every change, so no update ships without proving it has not broken what already worked.
6. A weekly monitoring cadence, with both teams reading the same dashboard and no surprises in either direction.

This is AI document automation done as engineering, with the regression and release discipline that keeps a live financial system trustworthy as it changes.

Delivery: four phases over nine months

The programme ran in four clear phases: diagnose, redesign, pilot, scale. Across the most intensive stretch, from January to May 2026, a team of six delivered 465 work items, working across continents and time zones with the bank's own people.

The result: a turnaround you can measure

44% → 86%

By June 2026 the picture had changed completely. Priority-loan document processing reached 86% automation. Non-loan processing reached 79%. Two domains passed 90%. And the regression that had started the whole engagement saw zero recurrence, because the release gates now caught that class of failure before it could ship.

The headline is the jump from 44% to 86% on priority loans. The quieter win is the zero recurrence, which is what restored confidence that the platform would stay fixed.

Recognition: the client's own words

In May 2026 the bank presented Tarento with its Team Excellence Award for the Microsoft AI Tools Initiative. The bank's Executive Director of Financial Markets wrote publicly about the work:

"A great collaboration with Tarento Group. We have seen significant progress in document processing automation with the help of AI. Very good cooperation between teams across continents, delivering measurable and strong results."

Why it worked: five things, and one of them is not technical

Five practices carried the turnaround:

1. The team stopped patching symptoms and reframed the problem first.
2. The business owned the trade-offs, deciding where automation was worth the risk and where it was not.
3. Human edits became training signal, so the system learned continuously.
4. Every release was gated against a regression suite.
5. Both teams read the same dashboard every week.

That last one matters more than it looks. No surprises in either direction is not really a technical practice. It is a relationship practice, and it is what turned a difficult engagement into a reference story. The lesson generalises: durable AI operations depend as much on shared visibility and honest trade-offs as on the models themselves.

Turn a stalled AI programme into a working one

Document-processing automation rarely fails because the technology cannot do it. It stalls because the data is messy, the thresholds are blunt, the system never learns, and no one is gating the changes. If your automation programme is stuck short of its target, that is exactly the kind of problem we rebuild.