Systems where being wrong is a regulatory event.
Financial services is the sector where every shortcut we would take elsewhere becomes unacceptable. Decisions have to be explainable, records have to survive an audit years later, and nothing irreversible can happen without a trail.
The technology is ordinary. The consequences are not.
Most of what a bank runs is, technically, unremarkable: ledgers, workflow, document handling, reporting. What makes financial services hard is not complexity in the algorithms, it is that a defect has a regulator attached to it, and that the system has to explain itself years after the transaction cleared.
That changes design decisions instead of just testing discipline. Deterministic logic is preferred wherever the rule is knowable, because a rule can be shown to an auditor and a model cannot be shown in the same way.
It also changes migration strategy. A retail platform can tolerate a bad week; a payments system cannot tolerate a bad hour. So the work moves in slices with both paths live, reconciled against each other on real traffic, and reversible until the evidence is unambiguous.
We have been doing this since 2003, including on the platforms nobody wants to open. The unglamorous parts (reconciliation, regulatory submission, exception handling) are where most of our work in this sector sits.
One payment, four controls, one expensive step.
Sanctions screening is deterministic and cheap. Settlement is deterministic and cheap. The expensive layer is the one in the middle, where a score says ‘maybe’ and an analyst has to look.
That is the layer where AI earns its cost, not by replacing the analyst, but by assembling the case, surfacing the comparable history, and cutting the false positives that make up most of the queue.
Six pieces of work we do repeatedly in financial services.
Core system modernization
Moving decades-old lending, ledger and servicing platforms onto something maintainable, in slices with both paths reconciled.
COBOL · ColdFusion · .NET · JavaRegulatory reporting
Assembling recurring submissions from live systems, with the lineage of every figure recorded and a review step before filing.
Warehouse · BI · filing portalsFraud & AML exception handling
Case assembly and prioritisation for the review queue, cutting false positives without removing the human decision.
Scoring · case management · audit logDocument-heavy onboarding
KYC packs, statements and contracts read into structured data with confidence scores and a review queue for anything uncertain.
Document store · CRM · core bankingPayment & ledger integration
Connecting systems that each believe they hold the truth, with reconciliation that surfaces genuine breaks, not noise.
Payment rails · ledger · middlewareInternal knowledge copilots
Answering staff questions from your own policy and procedure material, with the source cited and access scoped per user.
Policy library · intranet · proceduresSix questions we expect before anything reaches production.
We would rather answer these in the first workshop than in a remediation exercise eighteen months later.
Can the decision be explained?
Every automated outcome records its inputs, the rule or model version applied, and the reasoning available at the time, reconstructable years later.
Where does the data physically sit?
Chosen against your regulator's requirements. Where a model must run inside your own tenancy or jurisdiction, it does.
What can run unattended?
Reversible operations. Anything that moves money, closes an account or communicates externally waits at an approval gate regardless of confidence.
How is model drift caught?
An evaluation suite of real historical cases runs against every change, so a degradation is a failing test rather than a quarterly surprise.
Who can access what?
Least-privilege service accounts scoped per system, and retrieval that inherits your existing entitlements instead of a parallel permission model.
What happens in an incident?
A rehearsed rollback per slice, retained until the change is proven, plus the logs an investigation would actually need.
Before you start in this sector.
Three questions we are asked by almost every financial services client.
Our core platform cannot go down. How do you migrate it?
In slices, with both paths live and reconciled; never a cutover date. We take a bounded piece of the system, rebuild it, then run the old and new paths in parallel on real traffic and diff the outputs field by field. Only when the differences are all explained does traffic move, and the old path stays available until that slice has been stable for an agreed period. That comparison report is usually what satisfies your risk function, and it is far more convincing than a test plan.
Can we use AI at all given our regulator?
Almost always yes, but not everywhere, and the distinction matters. Regulators are generally comfortable with AI that assembles, summarises, prioritises and recommends while a person decides, the analyst still owns the outcome. They are much less comfortable with a model making an unexplainable determination that affects a customer. We design to that line instead of against it, which usually means AI in the preparation and deterministic rules in the decision.
We are mid-way through a programme with another supplier. Can you take part of it?
Yes, and it is a common way we start in this sector. Usually it is the integration or governance layer that has stalled instead of the application itself. We will review what exists and give you an honest read on whether it should be finished, repaired or replaced— including when the answer is that the incumbent should finish it.