240 tabs.
One spreadsheet ran beneficial-ownership checks for 20+ banks. We replaced it in three months.
Global beneficial-ownership compliance · name withheld under NDA
Anonymised mockup of the compliance platform · UI design by Amelia Prasad
At a glance
- Client
- Global risk-intelligence and screening platform, deployed into banks and financial institutions (name withheld under NDA)
- Industry
- Client and counterparty risk: beneficial ownership (UBO), KYC and KYB, sanctions, PEP and adverse-media screening, network analytics
- The arc
- First build three years ago, iterated since. The platform: 3 months, inception to deployment, against a licence-expiry deadline. AI layer in production now.
- Team
- 30 engineers, plus around 20 business analysts and support staff
- Stack
- Kubernetes · Dapr · Go · Python · Node.js · PostgreSQL
- Outcome
- Spreadsheets and email replaced by one audit-ready platform. Tenant setup takes days, not weeks. ISO 27001 achieved with the platform in scope.
A Tuesday morning, before
When we first arrived, the master workbook had 240 tabs. Version control was an email chain. The week before, someone had saved over a formula, and three cells downstream were quietly wrong.
Analysts described their handovers to us: four attachments and a note, sent person to person over email. No record of who decided what, or when. A regulator visit six weeks out.
These were some of the best analysts in the business. Their tools were the problem.
Sound familiar?
You don't need to work in beneficial ownership to know this shape. The signs are the same everywhere:
- → Your real system of record is a workbook someone emails around.
- → Case status lives in whoever replied last.
- → Every new client means cloning a file and changing it by hand.
- → You couldn’t show a regulator, or an auditor, or your board, how a decision got made.
If that's your Tuesday too, the rest of this page is how one firm got out.
Why they finally moved
No one rebuilds the way they work for fun. Three things forced it.
Bad data
Spreadsheets fail in silence. A broken formula doesn’t announce itself. In this line of work, a quiet error is the worst kind.
Risky data
Client data moved between banks and analysts by email, person to person. Every attachment was a risk. Every human in the loop was one more place for things to go wrong.
Cost
The firm charged per check, and every check crossed a human desk. More volume meant more people, and people don’t scale. Growth needed the routine work out of human hands.
It started small
This began about three years ago, before LLMs were everywhere, so the first fix was standards, not AI.
The first build was small and sharply scoped: a secure app that let banks send private data straight to the firm, in one standard format. No more email attachments. No more hunting for the right version. One front door. One format. One audit trail.
Tom and his team came in and transformed the highly manual Excel work into a flexible, dynamic piece of software we could deploy into financial institutions to ensure they sent their compliance data safely, securely and optimally.
Small was the point. It proved the working relationship before anyone bet big. And it did something quieter too: once the input data was standard, everything built after it got easier.
Why did they trust us with it? Expertise in building data products and systems, proven somewhere unforgiving. Before fintech, Tom built data platforms for NASA's Mars rover missions. That work is on the public record, with published science and open-source software, along with other government programmes. Environments where "it mostly works" doesn't pass. That experience shaped how the first build was scoped, and later, how the whole platform was staffed and run.
Then the clock started. The licences on the firm's case management and entity resolution tooling were due to expire. Those tools handled narrow steps while the real workflow lived in the workbook around them. Renewing meant recommitting for years to software that didn't fit how they worked. That deadline gave us three months, inception to deployment.
The delivery organisation was 30 engineers and around 20 analysts and support staff, run by us on the client's behalf. It was mobilised ahead of the build window, drawn from established engineering partners rather than open-market hiring. You can't hire fifty people in a quarter, and we didn't try.
Three months is not how long a build like this should take, and we won't pretend otherwise. The date wasn't negotiable, so depth was. Every surface shipped as an MVP, with as few features per section as the analysts could work with, then deepened release by release once the switch was made.
Build or buy?
This was a real debate, and the licence expiry gave it a date. You can buy entity resolution. You can buy screening. There's a crowded market of case management tools, and the firm had been paying for one. We priced the options and weighed them.
Buying lost, for three reasons.
Roadmap
Buy a vendor’s tool and you inherit the vendor’s plans. The firm’s edge was its own way of working. It needed software shaped to that.
Cost at scale
Per-seat and per-lookup fees look fine in year one. Run them across dozens of banks and the numbers turn ugly.
IP
Built well, the platform wasn’t a cost. It was IP the client owns outright, a product they can sell as their own. (That’s true of our builds generally: the client owns what we build.)
We'd give different advice to a different client; sometimes buying wins. Here, the firm's business model made building the right call. (The general framework is written up in Build vs Buy.)
What we built
One platform. Four parts. One codebase.
Ingestion
Pipes that pull data in from each bank, check it, and route it into cases.
Case management
The analysts’ day-to-day system: workflows, documents, assignments, escalations. Every change is recorded.
Dashboards
Live views of case state, document flow, and screening hit rates.
Infrastructure
The plumbing: Kubernetes, a Dapr service mesh, PostgreSQL, monitoring, CI/CD.
Configuration, not code
The design call that mattered most: each client's compliance rules are configuration, not code. Workflows, escalation rules, document types, report templates, all of it is data in the system. Adding a new bank means setting up a tenant, not forking the code. Tenant setup now takes days, not weeks.
Configuration this powerful needs governance, and it has it: every config change is versioned, needs a second approver, is tested against replay data before it goes live, and lands in the same audit log as everything else. A rule change that could suppress an alert gets the same discipline as a code change, because it carries the same risk.
What actually got faster
The business problem was that every ownership case crossed a human's desk, with the human untangling the corporate structure by hand.
Now the algorithms make the first pass. Every entity is resolved and its ownership chain mapped automatically, and the beneficial owners it surfaces are screened and scored. Clean structures clear, with the result logged. The ones the scoring flags become cases, and every case still ends with an analyst's decision, as it should in beneficial-ownership work. The analyst now starts at the judgement, not the wrangling: the case arrives with entities resolved, the ownership graph drawn, screening already run, and documents attached.
Humans stopped being the pipe. They became the judgement layer at the end of it, which is the part of the job they were hired for.
The same Tuesday, after
Same team, months later. Cases live in one system. A handover is a reassignment, not four attachments. Bad data gets caught at the front door.
And when the regulator asks how a decision was made, the answer is a log, not a folder of spreadsheets. Every change, every person, every timestamp, kept by the platform as it works.
The proof kept coming after the switch. New institutions now onboard in days. And the client took the whole operation through ISO 27001 certification, with the platform inside the certified scope.
We don't publish the operational numbers behind this: case volumes, hit rates, costs, throughput. This is confidential risk work, and we'd rather say less than dress numbers up.
The technical detail
The architecture, delivery structure, and security posture: the material a platform or procurement team will want.
The architecture, in four layers
Client applications
Purpose-built interfaces that replaced the email-and-spreadsheet workflow. Reports are generated, not assembled.
Service mesh
Microservices on Kubernetes with Dapr sidecars. Each service owns one domain: case lifecycle, document processing, rule evaluation, audit logging. Services talk through Dapr pub/sub and service invocation, which keeps coupling low and observability high.
Domain services
Language follows workload. Go for high-throughput processing with tight latency budgets. Python for the regulatory rule engine. Node.js for user-facing APIs.
Data and audit
PostgreSQL as the system of record: full-text search, JSONB documents, row-level security. The audit log is enforced at two levels: the service framework writes every state change, and the database refuses to alter it afterwards. Belt at the framework, braces at the database.
How fifty people stayed coherent
The delivery organisation was 30 engineers plus around 20 business analysts and support staff. A team that size is only an asset if it's organised to compose, not collide.
- • Pods foundation, services, frontend, data, QA, each with a clear owner.
- • Service contracts as the integration currency. Contracts were agreed before code was written, so pods could mock and build in parallel from day one.
- • Daily integration on staging, which caught interface drift while it was still cheap to fix.
- • A dedicated platform pod holding the single source of architectural truth.
The three phases
Foundation
Kubernetes, the service mesh, database baselines, CI/CD, observability: the rails everything else ran on.
Service build
Parallel pods built the domain services. Audit logging was wired into the shared service framework rather than bolted onto each service by hand.
Hardening and handover
Load testing, security review, RBAC and segregation-of-duties checks, regulator-readiness rehearsals, runbooks, on-call docs, launch.
Compliance and security posture
Encryption & secrets
- • mTLS on every service hop via Dapr.
- • Encryption at rest.
- • Secrets in a dedicated store, never in environment variables.
Identity & access
- • RBAC with segregation-of-duties enforced at the mesh.
- • Privileged actions need explicit elevation, and elevation is logged.
Audit trail
- • Append-only, enforced at the database tier: UPDATE and DELETE revoked from every application role.
- • Every state change, authorisation decision, and analyst action carries an actor and a timestamp.
- • Write volume handled with partitioning; audit queries run against read replicas, so they never contend with the live system.
- • Export formats are regulator-friendly by design.
Tenancy, residency & scope
- • Tenant isolation at row-security and namespace level.
- • Residency configurable per engagement; retention configurable per data class, with verifiable destruction.
- • Beneficial-ownership rules track the major regimes: EU registers under the AML directives, US reporting under the Corporate Transparency Act, and the UK PSC register.
- • Entity resolution, ownership-chain mapping, and screening of owners against sanctions, PEP and adverse-media data run automatically on every inbound entity; flagged results open cases, and every result is logged.
Independent assurance
- • The client achieved ISO 27001 certification following launch, and the platform operates inside the certified ISMS scope.
- • No certification audits every control above individually. It does mean the management system around them is independently assessed rather than self-reported.
Technology choices, with reasoning
Stack choices follow workload, not fashion.
What we're adding now
The AI layer
In beneficial-ownership work, "we're adding AI" is a risk statement before it's a benefit, and we treat it that way. So, plainly:
Where it’s aimed
The routine first-pass tier of the work: document validation and data extraction, the checks that consumed the most junior analyst time and needed the least judgement. Senior judgement calls stay where they are. We started at the bottom of the judgement ladder on purpose, and we’re climbing it only as the evidence supports.
Where it stands
Document extraction and validation are in production. So are data search and augmentation. For entity resolution, LLMs suggest candidate matches, and an analyst confirms or rejects every one. Nothing on this list decides; it prepares, and humans decide.
Model governance
Models are hosted inside the platform’s own Azure tenant and data is processed under that tenant’s agreements. Nothing goes to public model APIs, and nothing is used to train anyone’s models. Model versions are pinned and changes go through the same release discipline as code. Every agent output is logged with the model version that produced it, so any suggestion can be traced.
Measurement
Small models handle high-volume validation and extraction; larger models handle the harder suggestions, benchmarked per task because cost and latency have to hold under the platform’s SLAs. Accuracy runs continuously against held-out cases. Models drift; the eval harness is how we catch it, and it produces the evidence trail an auditor would ask for.
One lesson from the build
Docs were the floor, not the ceiling
A distinction matters here. Tenant setup, configuring the platform for a new institution, takes days. User adoption, getting analysts at 20+ banks across time zones actually working in it, is where we stumbled. Our first adoption plan was written docs plus live sessions. The docs went unread. The sessions died of timezone maths. We rebuilt onboarding around recorded walkthroughs and async-first support, and adoption recovered.
For busy, spread-out teams in regulated work, the path to adoption is not paved with PDFs.
Talk to the people who built it
Under pressure from a regulator? Modernising compliance ops? We'll walk you through the decisions, the trade-offs, and what we'd do differently now.
Related work