Stop fraud before money moves.
PennyPay detects suspicious payments using behavioural intelligence, transaction analytics, graph relationships and GPU-accelerated machine learning — giving financial institutions a risk decision before the transaction completes.
Built for banks · fintechs · neobanks · digital wallets
mobile · cross-border
Payments move in milliseconds.
Fraud does too.
Interoperable instant rails removed the delay that fraud controls were designed around, and liability is moving with them: 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. Detection that arrives after settlement is reconciliation, not prevention.
Fragmented signals
Traditional systems analyse transactions without enough behavioural, device, identity and network context. Each signal is evaluated alone, so coordinated activity stays invisible.
Static rules
A rule engine encodes the fraud an institution has already seen, so each new typology arrives as an incident first and a rule some weeks later.
False positives
Tightening thresholds catches more fraud and also blocks more paying customers, and most institutions measure only the first of those two numbers.
Signals arrive from the payment flow you already run.
Nothing new has to be collected. The transaction, device, identity and account data an institution already holds is evaluated by three engines at once, and a decision returns before the payment completes.
Adopt it one module at a time.
Most institutions start with scoring and add the rest once it is earning its place. Each module is useful on its own.
Evaluate every transaction against behavioural, transactional, device, identity and historical signals, and return a calibrated risk score to the payment flow.
See a score explained →Connect accounts, devices, IP addresses, merchants, recipients and transactions to uncover coordinated activity that transaction-level analysis cannot see.
See the network view →Combine machine-learning scores, graph signals and institution-defined rules into configurable approval, review or decline workflows your risk team controls.
See the decision path →Give analysts the context behind every alert — transaction history, connected entities, triggered signals and model explanations — in one workspace.
Open it in the console →Fraud rings are visible in what they share.
Fraud rings share infrastructure. When accounts reuse devices, IP addresses and cash-out recipients, the relationships are visible long before the individual transactions look unusual — published results on graph features in alert triage report cutting false positives by around 80% at comparable detection rates, and Europol's money-mule operations describe the same shared-infrastructure pattern at scale. Select an entity to inspect its connections.
Built for decisions at transaction speed.
PennyPay is being architected around GPU-accelerated feature engineering, machine-learning inference and graph analytics, to analyse large transaction streams with minimal decision latency.
These technologies are named because they are part of the system design, not as endorsements. PennyPay does not publish throughput, latency or detection-rate figures, and will not until they are established under benchmark conditions on production workloads.
Every score needs a reason.
A score an analyst cannot interrogate is a score a regulator will not accept. PennyPay is designed to provide interpretable signals behind each risk decision, supporting investigation, policy review and auditability.
Each contribution is attributable to a named signal, so a declined customer can be given a reason and a policy team can see which signals are driving their review queue.
One API call between a transaction and a decision.
Post the transaction you are about to process. Receive a score, a decision and the signals behind it. No batch export, no overnight file, no separate console to check.
{
"transaction_id": "txn_8fc921",
"account_id": "acc_1024",
"amount": 184500,
"currency": "KES",
"channel": "mobile",
"device_id": "dev_884"
}
{
"risk_score": 0.947,
"risk_level": "high",
"decision": "review",
"signals": [
"new_device",
"velocity_anomaly",
"network_risk"
]
}
Fraud looks different depending on who is being defrauded.
Banks
Established fraud operations with legacy rule engines, large analyst teams and regulatory reporting obligations.
Neobanks
Fast onboarding and instant payments, with small risk teams that need automation rather than headcount.
Digital wallets
High-volume peer-to-peer transfers where funds leave the network quickly and recovery is rare.
Payment platforms
Multi-merchant flows where risk sits with the platform and exposure concentrates in a small number of bad actors.
A fraud model is only as good as the labelled data behind it and the rails it plugs into. Below are the organisations we work with, and the four arrangements we are still looking for, each stated as an exchange.
Pilot institutions
Banks, wallets and payment platforms willing to run an evaluation on their own historical transactions under a research protocol.
We bring
Scoring, graph resolution and an explanation for every decision, run against your data at no cost during the evaluation, with the output benchmarked on the four measures below.
We need
Labelled historical transactions, including the confirmed-fraud outcomes. This is the single biggest constraint on progress right now.
Core banking and switch vendors
The platforms already sitting in the payment path, where a risk decision has somewhere to be returned to.
We bring
A single synchronous API that returns a score, a decision and the signals behind it, designed to sit inside an existing authorisation flow rather than beside it.
We need
A supported integration point, and a realistic latency budget agreed up front rather than discovered in production.
Academic and research groups
Groups working on graph learning, anomaly detection or financial crime typologies.
We bring
Applied problems on real payment topologies, and engineering time to turn a method into something that runs inside a latency budget.
We need
Method review, and an outside reading of whether our evaluation is measuring what we claim it measures.
Regulators and industry bodies
The people who will decide whether an automated decision is defensible, long before a customer disputes one.
We bring
Decisions that are attributable to named signals and reproducible after the fact, and a willingness to be told the explanation is not good enough yet.
We need
Early guidance on what evidence an automated decline has to carry in each market we would operate in.
Marks above indicate a working relationship and nothing more — no organisation shown has endorsed a performance claim we have made. The four arrangements below describe partnerships we are still looking for, not ones already in place.
Designed for financial-grade security.
PennyPay handles transaction data belonging to regulated institutions. Below is what is implemented today, what is in progress, and what is planned — stated separately, because the distinction matters.
- Encryption in transit
- Encryption at rest
- Secure API authentication
- Role-based access control
- Audit logging
- Per-tenant data isolation
- Key rotation
- IP allowlisting
- Data retention controls
- Continuous monitoring
- Formal incident response programme
- SOC 2 Type II
- ISO 27001
- PCI DSS where applicable
PennyPay is not currently certified under SOC 2, ISO 27001 or PCI DSS, and displays no certification marks. Certification status will be published on the security page as each is achieved.
Put PennyPay against your fraud data.
Run it over historical or simulated transaction data and measure it on the four things that decide whether a fraud system earns its place.