What we are building, and what we are not claiming yet.
PennyPay is a pre-revenue company working on real-time payment fraud risk. There is a working scoring path, a graph resolver and an operations console. There is no production deployment, no certification, and no detection rate we would ask anyone to believe. This page is the long version of that.
The rails got faster before the controls did.
Payment infrastructure across the markets we care about has spent a decade collapsing settlement time. Kenya’s national payments programme made mobile money interoperable and instant; comparable schemes exist or are being built almost everywhere else. The controls wrapped around those payments did not move at the same speed. A great deal of fraud tooling still assumes a window between authorisation and settlement that no longer exists, which turns detection into a reconciliation job that runs after the money is gone.
The liability moved as well. Since October 2024, UK payment firms have had to reimburse most victims of authorised push payment scams, with the cost split between the sending and the receiving institution. Once the institution absorbs the loss rather than the customer, “we flagged it the following morning” stops being an answer. Other regulators are moving in the same direction at different speeds, and the institutions we talk to are already planning for it.
What we concluded from that is narrower than a mission statement. Scoring an individual transaction is a well-served problem. Seeing the structure around it is not: fraud rings reuse devices, addresses and cash-out recipients, and that shape is legible well before any single payment looks unusual — published work on graph features in alert triage reports cutting false positives by around 80% at comparable detection rates. So PennyPay is a score, plus the network that explains it, returned inside the authorisation window rather than after it.
Our claim.
Fraud detection is a field where nobody can check your numbers until they have already bought them. This is the line we hold instead, and it is a reasonable thing to hold us to.
We will say
- What is implemented today, and what is only designed. The security section splits those out on purpose.
- Which third-party research we are relying on, with a link to it, so the claim can be checked without asking us.
- That an evaluation runs on your data, in your environment, and that the result belongs to you whichever way it goes.
- When an explanation is not good enough yet. That has happened, and it will happen again.
We will not say
- A detection rate, a false-positive rate or a latency figure, until one is established under benchmark conditions on production workloads.
- That we are certified under SOC 2, ISO 27001 or PCI DSS. We are not, and we display no certification marks.
- That any institution is a partner or a customer before there is an agreement that says so.
- That a model is explainable because it prints a number beside each signal. Attribution is the start of an explanation, not the whole of one.
- Anything about a named institution’s fraud exposure, including what we are shown during an evaluation.
Ovie Elanga
Payments risk, eleven years. Most of the week goes on institutions and the data-sharing agreements that make an evaluation possible at all.
Alan Chikwanda
Nine years on imbalanced, adversarial data. Owns the models, the pipeline they run on, and the uncomfortable question of what a score of 0.94 is actually asserting.
Larissa Kinyanjui
Twelve years reading cases rather than dashboards. Sets the typologies the models are trained against, and adjudicates the review queue.
The constraint is data, not ideas.
The fastest way to make this real is a labelled transaction set and an institution willing to let us run against it. If that is not you, the partnership programme sets out the other three arrangements we are looking for.