For financial services
Financial services
Fraud alerts, AML cases, disputes, collections, credit exceptions: each is a queue longer than the team that works it, and each gets worked from the top of a sort. That sort is a decision rule. It runs thousands of times a month, and in our experience almost nobody has measured what it costs against the best rule available. We model the decision, measure the gap on your own history, and leave you with a rule you can explain to a regulator a year later.
The decisions that bind here
The five decisions a control team makes
There is nothing exotic in this list, and a data-science team would not recognise most of it as modelling. They are allocation and threshold problems, made continuously, under a review capacity that nobody gets to raise this quarter.
-
Which cases does a limited team work first?
Alerts, disputes, chargebacks and collections all arrive faster than they can be cleared. Sorting by exposure looks obvious and is usually not optimal. The best set under the capacity you have is a different set, and the difference is measurable.
-
What is an investigation worth running?
A review costs analyst hours whether or not it finds anything. Some cases carry enough expected loss to be worth the look and some do not, and treating them identically spends the scarce hours on the cheap question.
-
Where should the threshold sit?
A rule tuned to catch more also stops more good customers. That trade can be priced. But it is usually set once, defended by anecdote, and left alone for years.
-
How much review capacity do you need?
Queues arrive unevenly. Staffing to the average leaves a backlog that never clears, and staffing to the peak buys idle time. The answer is a scheduling question with a known shape.
-
Can you explain the rule a year later?
In a regulated setting a decision has to survive being asked about. A rule you can state, with a recorded reason per case, is a different asset from a score nobody can open.
Before you talk to us
Try the argument on your own numbers first
The claim that a capacity-aware selection beats a worst-first queue is not something you should take on trust. One of the tools on this site solves exactly that problem. Enter your cases, their exposure and the effort each takes, set the capacity you have, and it computes the best set and shows what worst-first costs you against it.
It solves it exactly, with no ranking heuristic, and it runs in your browser: nothing you type leaves your machine. The same family of solvers is in orhof, our open-source operations-research library, 251 functions across 30 namespaces, zero dependencies, so you can read the grown-up version before trusting any of it.
Where it applies
- Payments and PSP operations with fraud and dispute queues.
- Banks and lenders running AML alert review or credit exceptions.
- Collections and recoveries teams prioritising limited contact effort.
- Any control where the queue is longer than the people who work it.
How we engage
How an engagement runs here
We do not arrive with a platform. We start by finding whether a decision is worth improving at all, and prove the value on your own data before anyone commits to building a system to sustain it.
1. Audit
Find the decision that pays
A Decision Opportunity Audit runs on one queue or control you operate today, establishes the baseline and the economic stakes, and ends with a recommendation. One of the possible recommendations is that no system is needed.
2. Proof
Test it against your baseline
If the value is there, a proof of value tests the method on your own history before it is trusted, measured against the rule you run today, with calibration reported. Our standard for what counts as evidence is set out in how we validate.
3. Build
Build what proved out
Only what proved out gets built into something durable and owned. Find, Prove, Build keeps each stage honest, so evidence sets the scope.
What we need to see
The queue itself, cases with whatever outcome and effort data exists, and the capacity the team working it has in practice. Where a baseline was never recorded, establishing one is the first deliverable. A model cannot repair data that does not exist.
When testing is not enough
The rules that should be proved
Some rules must never breach a hard constraint: an exposure cap, a contractual limit, an exclusivity. Tests sample the input space but cannot close it. So the residual risk is exactly the case the tests did not draw, and for those rules a proof is the cheaper instrument.
Rainbow is our Clojure-native dependent-type theorem prover, with a ~1,200-line trusted kernel. It machine-checks decision logic instead of only testing it, and carries proofs for 222 of 222 catalogued operations-research algorithms. We publish the covered set and the gap together, because a proof covers what it covers.
What we are not
- Not a compliance or regulatory advisory. We hold no audit or certification credential and do not interpret regulation.
- Not a licensed payments platform or a card processor.
- We are not a fraud-score vendor. We build the decision system around your controls, and there is no black box to put inside them.
Where we have worked
Where we have worked
Ten years in, about 50 people across around 20 countries. We have built financial and transactional systems for the companies below. What we will not do is attach a percentage, a revenue figure or a delivery timeline to any of them, because none of them published one, and a number you cannot check is worth nothing to you anyway.
-
Zimpler
Fintech and mobile engineering.
-
Guaranteed Rate
Software engineering engagement.
-
Cicada Wallet
Blockchain wallet engineering and product design.
-
Starcity
A payment microservice extracted from a monolithic application.
The research behind it
The method, published
When we are a fit
- A queue or control that recurs daily and is worked under a fixed capacity.
- Enough history to build a baseline of how the decision is made today.
- An owner able to change the rule once the evidence says it should change.
When we are not
- You need a regulatory opinion or a certification signed off.
- The decision happens once a year, or the stakes do not justify a system.
- No route to case, outcome or capacity data, and no appetite to build one.
FAQ
Questions from financial-services teams
Which decisions do you work on?
The repeated ones that ration a scarce resource or set a threshold: which alerts and disputes a limited review team should work first, what an investigation is worth running at all, how to schedule operations capacity against a queue that arrives unevenly, and where a rule should sit when both false positives and false negatives cost money. Each is made continuously, usually by a queue sorted on one field, and the cost of a slightly wrong rule compounds every day it runs.
Are you a compliance or regulatory consultancy?
No, and it would be misleading to imply it. We hold no audit or certification credential and we do not advise on regulatory interpretation. What we do is build the decision system underneath a control and make its logic legible, so that when your compliance function or an examiner asks why a case was actioned and another was not, the answer is a stated rule with a recorded reason, never a model nobody can open.
Why does formal verification come up in a finance context?
Because some decision rules must never violate a hard constraint, a capacity, a contractual limit, an exclusivity, and tests sample the input space without ever closing it. Rainbow, our Clojure-native theorem prover, machine-checks decision logic instead of only testing it. It carries proofs for all 222 catalogued operations-research algorithms, and we publish the covered set and the gap together. A proof covers what it covers; it complements testing and never replaces it.
What do you need from us to start?
The decision, and the history of how it has been made. For a triage problem that means the queue itself, cases with whatever outcome and effort data exists, plus the capacity the team working it has in practice. Where a baseline was never recorded, establishing one is the first deliverable. A model cannot repair data that does not exist.
Do you have a fintech case study with numbers?
Not one we can show. Zimpler, Guaranteed Rate, Cicada Wallet and Starcity were engagements and we name them as engagements. We do not attach an outcome figure, a percentage or a timeline to a client that has not published one. What we can show instead is the method: the research is public, the operations-research library is open source, and two of the tools on this site run the same algorithm on your own numbers in your browser.
Start with the decision
Bring us one queue
One control you run today: a fraud queue, a dispute backlog, an AML review list. A short audit run by a partner will say what the current rule costs against the best available one, and whether a system to close the gap is worth what it would cost. The fee is fixed before we start.