Fraud moves faster than rules
Every new pattern means a developer writing another rule, and by the time it ships the pattern has moved. Rules engines are always fighting the last attack.
Financial services & fintech
Money systems are judged on the day they are wrong.
A payments platform that reconciles perfectly for eleven months and is out by four hundred pounds in December has not had a good year. Financial software development is judged the same way: not on average behaviour, but on the worst hour the system has ever had, by a regulator, in retrospect, with the ledger in front of them.
The question to answer first
“Can you catch the fraud without blocking real customers, and prove both to an auditor?”
$2M
A year saved by the AI fraud detection we built for a start-up
The pressure
Four forces acting on every money system.
Real-time expectations
Settlement used to be a batch job. Customers now expect the money to move while they are looking at the screen, which removes the window you used to reconcile in.
Regulatory surface
PCI DSS, KYC, AML, PSD2, SOC 2. Each one is survivable. The cost is carrying all of them at once in a codebase that also has to ship features.
Legacy cores
The system of record is often decades old, well understood by three people, and cannot be replaced in one move without betting the business on it.
The work
What we build for financial institutions
Four systems, each of which has to be correct on its worst day rather than its average one.
Fraud and risk scoring
Models that run inline against the live transaction stream, with a review queue ranked by expected loss rather than by arrival time.
Payment and settlement rails
Idempotent, reconcilable, and correct under retry. The hard part is never the happy path, it is the duplicate write at 2am.
Regulatory reporting
Reports generated from the ledger rather than assembled by hand in a spreadsheet the week they are due.
Core modernisation
Replacing a legacy core in slices, each one covered by tests and reversible, rather than a rewrite with a launch date and no way back.
Brilliant Systems helped us design and implement a sophisticated AI-driven risk analysis tool tailored for the financial sector. From initial consultation to final deployment, their team showcased deep expertise in machine learning models, particularly in anomaly detection and natural language processing for parsing financial documents.
Read the full review
The reconciliation test
Five failures we deliberately cause before you go live.
Any payment system works when the network behaves. These are the conditions we introduce on purpose in staging, during the week before handover when an engineer who did not build the system tries to break it. Production will introduce them without asking.
01
Duplicate delivery
The same webhook, twice
A provider retries a callback the system already processed. The correct outcome is one ledger entry and an acknowledged duplicate, not two charges and a support ticket.
02
Partition
The database is unreachable mid-transaction
The write succeeded, the confirmation never arrived. On recovery the system must be able to determine which, without a human reading logs.
03
Clock skew
Two services disagree about now
Ordering by wall clock across machines is a bug waiting for a leap second. We test that sequence survives disagreement.
04
Partial settlement
The batch half-lands
Four hundred of a thousand movements clear. The reconciliation has to identify the six hundred precisely, not report a mismatched total.
05
Replay under load
A day is reprocessed at volume
Reprocessing a historic day must produce the identical ledger. If it does not, the ledger was never the source of truth.
Non-negotiable
What the ledger has to be able to prove
- Reconciliation to the cent
- Every movement traceable to its source event. If the ledger and the bank disagree, the system must be able to say exactly where and when.
- Idempotency everywhere
- Retries, webhooks and network partitions are normal. A payment system that can double-charge under load is not finished.
- Explainable decisions
- When you decline a transaction you may have to justify it. A score with no reasoning attached is a liability, not a feature.
- Immutable audit
- Append-only records of who changed what. Not a table anyone can update, which is what most systems actually have.
Where AI actually lands
Four places it earns its cost, and one line we do not cross.
Worth doing
- Fraud scoring, where the pattern shifts faster than anyone can write rules and the cost of a miss is measurable to the penny.
- Anti-money-laundering triage, cutting the false positives that can take up most of an analyst team’s day.
- Document handling in onboarding, where the work is high volume, well specified and dull.
- Reconciliation exceptions, matching the awkward five percent that break the automated rules.
Where we stop
Anything that moves money without a human in the loop, and anything whose decision you cannot reconstruct. Both fail the same test: an auditor asks why, and "the model said so" is not an answer that ends the conversation.
Evidence
Our published fintech case study is AI-driven fraud detection that saved a start-up $2M a year.
Read the case study
How we deliver it
The services this work draws on.
AI Development
Production ML pipelines, retrieval systems, and evaluation harnesses built to survive audit.
Enterprise Software
Platforms that hold up under real load, real compliance, and real headcount.
Cybersecurity
Threat modelling, hardening, and the evidence trail an auditor will ask for.
Other sectors we work in
Next step
Tell us where your ledger and your bank disagree.
A senior engineer reads every enquiry and replies within one business day with an honest view of what it will take, including what an auditor will ask of the design.
