Case Study · Banking · Cost & Sustainability

Document Aggregator — a UK bank's path from 6 paper letters/month to 2 (and a digital wallet).

A non-intrusive aggregation middleware between statement generation and the printing/postal pipeline cut physical deliveries by ~67%. A second phase added a secure digital document wallet, opening the path to going green.

Industry: Banking / Retail Financial Services Geography: United Kingdom Role: Solution Architect

~6 → 2

Physical statement deliveries
per user per month

£1+/user/mo

Conservative saving per user
= millions annually at retail-bank scale

Zero rewrite

Non-intrusive middleware —
no rewrite of legacy statement system

The situation (why they called)

A leading UK retail bank generated multiple physical statements per customer every month — current account, mortgage, credit card, two loan products, sometimes a savings statement on top. Each ran through a separate generation system; each landed in the printing and postal pipeline as its own job; each customer received 5–6 envelopes per month.

Three pressures were converging:

Postage and printing costs were a large operational line item that nobody in the business owned
The bank's sustainability team had publicly committed to reducing paper and carbon — but the statement pipeline was the elephant in the room
Customers were complaining about envelope clutter; some never opened the statements at all

The internal team had proposed rewriting the statement generation system to consolidate at source. That was a multi-year programme touching 6 underlying core-banking systems. Out of scope for this engagement.

The diagnosis

Two observations changed the conversation:

The statement systems and the print/post pipeline were already loosely coupled. Statements were generated as files and pushed into a shared print queue. A new component could insert itself between those two without rewriting either side.
Most customers' multiple statements were generated within a few days of each other (cycle dates clustered around mid-month and end-of-month). Holding a few days of statements per customer would let us batch most of them into 1–2 envelopes instead of 5–6.

The decision

Decision (two phases) Phase 1: insert a non-intrusive aggregation middleware between statement generation and the print/post pipeline. Hold documents up to a configurable cutoff window, batch them per customer, ship one envelope. Phase 2: add a secure digital document wallet in the bank's existing customer app, so customers who opt in receive statements digitally and never trigger physical delivery at all.

The architecture

Phase 1 — Aggregation middleware

Intercepts documents as they exit the generation systems, before they hit the print queue
Each document tagged by customer ID, document type, generated date, and "drop-by date" (the regulatory deadline by which it MUST reach the customer)
Buffer holds documents up to a configurable cutoff (initially 15 days) per customer
At cutoff (or earlier if drop-by is approaching), aggregator releases all queued docs for that customer as a SINGLE batch into the print pipeline
Single shared cover sheet, single set of T&C pages, single envelope — drastic reduction in paper and postage per customer
Configurable per document type — high-priority docs (overdue notices, regulatory) bypass the buffer and ship immediately

Phase 2 — Digital document wallet

Encrypted document store integrated with the bank's existing customer-facing application
Customer opts in to digital delivery — opt-in is reversible and document-type granular
For opted-in customers, the aggregation middleware routes their documents to the wallet instead of the print pipeline
Wallet supports: instant delivery, long-term storage, on-demand retrieval, audit trail per access
End-to-end encryption with per-customer keys; bank ops can't read content, only metadata

Key decisions (and what we said no to)

Yes: middleware between existing systems — minimal blast radius, no core-banking change
Yes: opt-in digital wallet — avoids regulatory issues with default-digital and customer trust issues
No: rewriting the statement generation system at the source (would have been a 2–3 year programme; this delivered value in months)
No: third-party document storage SaaS — bank required keys to stay in-house
No: aggressive default cutoffs — held the line at 15 days because regulatory drop-by deadlines are non-negotiable

The outcome

Numbers Physical deliveries per user/month: ~6 → 2 (~67% reduction).
Conservative saving: £1+ per user per month on print + postage alone.
At retail-bank scale (millions of customers), the annual saving is multi-million-pound.
Sustainability metric (paper, carbon footprint): meaningfully improved.
Customer experience: noticeably less envelope clutter; opt-in digital wallet drove a steady migration to paperless.

What I'd do differently

I'd build the analytics surface first. We launched the middleware with operational metrics (queue depth, batch sizes, drop-by misses) but with limited customer-impact metrics. As soon as the sustainability team started asking for "paper saved per quarter, carbon equivalent, by region", we had to backfill those calculations. If the business metrics can be shown back to leadership in a chart, the project's mandate to expand widens dramatically. Build the dashboard alongside the system, not after.

Have a high-volume operational system where small per-unit savings become huge at scale?

Book a System Review All engagement tiers