Perspective
Decide in Advance Which Instant Payments Deserve a Second Look
When the customer authorises the payment, every sign-in check passes. We help you choose which payments deserve a second look, and test those rules on your own cases.
4-minute read5 November 2026
In Brief
- A customer talked through a payment by a caller supplies both factors correctly, on their own device. The risk lies in the payment and in the account receiving it.
- We see four actions: build one table of recent complaints, add friction to a small share of payments, watch accounts that receive and pass money on quickly, and staff a queue that can act in minutes.
- Thinqmesh ranks your risks by business impact, tests candidate rules against your real cases and keeps a person checking where a wrong answer costs money. The assessment takes four weeks.
A fraud team built for card payments assumes it has time. A suspicious transaction can be declined, queried by telephone or reversed through a dispute process that runs for weeks. Instant account-to-account payments remove most of that margin, because the money has reached another account, and often a third, before anyone has looked at it. Our view is that the effort belongs on the payment and on the account that receives it, and that a small share of payments should be made deliberately slower.
A Correctly Authenticated Fraud Passes Every Check
A typical fraud now works by persuading the customer. The customer authorises the transfer, supplies both sign-in factors, uses their own device and sits in their usual location. Stronger authentication is sensible against stolen credentials, and it does little here. What remains visible is the amount, the newness of the payee and the behaviour of the receiving account.
A blanket control would fall almost entirely on customers doing nothing unusual, which is why payment leaders are right to be wary of it. The cost of doing nothing is that the money is gone within minutes and recovery is limited. Choosing which payments deserve friction, and testing that choice on your own cases, makes the control narrow enough to run.
Four Actions That Put Scrutiny Where the Risk Sits
Each one is built from your own data, so the discussion between fraud, product and operations rests on your figures.
Build One Table From the Last Ninety Days of Complaints
Confirmed or not, each authorised payment complaint becomes a row you can test rules against.
For each case we record the amount, whether the payee was new to the payer, the age of the receiving account where you hold it, and the minutes between credit and onward transfer. We build a test set from these real cases, where the answers are already known, and then run candidate rules against all your payments for the same period.
Get started
- Collect ninety days of authorised payment fraud complaints, confirmed or not.
- Add the four fields above for each case.
Add Friction to a Small Share of Payments
Speed can be unequal: instant for most payments, slower for the few that carry the risk.
A large first payment to a new payee, from an account that rarely makes one, deserves more than a score. Within what your scheme rules and regulation allow, that can mean a specific warning, a short pause or a call from someone trained to speak to a person under pressure.
Get started
- Define what a large first payment to a new payee means for your customers.
- Count how many genuine payments such a rule would touch.
Watch the Account That Receives the Money
A receiving bank can see a thin-history account taking unrelated credits and paying them out in minutes.
That pattern needs no cooperation from the victim. We help you rank the receiving-side signals that matter and route them to monitoring that concentrates on those signals. Alerts that no one can act on within minutes have little value on an instant rail.
Get started
- List the signals your receiving side can already see.
- Choose the three that would most often precede a fraud.
Keep a Person Checking Where a Wrong Call Costs Money
A staffed queue with authority to hold funds, where the rules permit, completes the control.
Models and rules do the first pass. A person reviews the cases where a wrong answer costs a customer money, with the scoring on your own cases kept in view after launch. Roles and decision rights are agreed before an incident, and the team rehearses a realistic scenario.
Get started
- Name who can hold a payment, and how quickly they can be reached.
- Write down the decision rights for a payment held at night.
How Thinqmesh Solves This
We begin with which data, systems and processes would cause most harm if lost, leaked or stopped, and that ranking governs the rest of the work.
- Week 1
The Risk Ranked by Business Impact
We rank the processes and accounts that matter most, and gather ninety days of cases into a test set with the answers already known.
- Week 2
Access and Existing Tools Tightened
We review who can approve, change limits and release holds, and how existing tools are used. A new product is recommended only when a specific risk justifies it.
- Week 3
Rules Scored on Your Own Cases
Candidate rules are run against your cases. You see which frauds each rule would have caught, and which genuine payments it would have touched.
- Week 4
A Rehearsal, and a Costed Plan
Your team walks through a realistic scenario, and the findings become a prioritised and costed plan to close the gaps.
You finish with your risks ranked by business impact, rules scored on your own cases and a costed plan. Your team has practised the decisions, and the documents are yours.
