Fraud Prevention
Stopping authorised push payment fraud with phone intelligence
In authorised push payment fraud, the victim sends a payment themselves, which means conventional fraud controls that flag unauthorised transactions arrive too late. The PSR introduced mandatory reimbursement for APP fraud in the UK in October 2024, shifting liability to payment firms. Telecom signals add a real-time check on the phone numbers involved in a payment before the transfer is authorised.
How APP fraud works
APP fraud typically follows one of two patterns. In the first, the attacker impersonates a trusted party and persuades the victim to send a payment to an account the attacker controls. In the second, the attacker takes over the victim's account directly, often via a SIM swap, and initiates the payment themselves.
What makes APP fraud difficult to block with standard controls is that the payment looks legitimate at the point of processing. The sender has authenticated successfully. The amount may be within normal range. The only signal that something is wrong may sit in the phone number layer: the victim's SIM was swapped hours before, or the recipient's number resolves to a non-fixed VoIP number rather than a registered mobile.
What PSR mandatory reimbursement means for fraud teams
Under PSR rules effective October 2024, payment service providers in the UK must reimburse customers who are victims of APP fraud on Faster Payments, subject to defined limits and eligibility criteria. The reimbursement obligation applies to both the sending and receiving firm.
This changes the incentive structure. Previously, the cost of APP fraud fell on the customer. Now it falls on the firm. A telecom signal layer that catches a high-risk payment before it is processed is no longer just a fraud metric; it is a direct reduction in reimbursement exposure. For the broader UK regulatory context, see SIM swap signals for FCA affordability and lending checks.
Where in the payment flow to apply each signal
Check the phone number supplied by both sender and recipient at account creation. A non-fixed VoIP number at registration is a strong indicator of a synthetic or mule account. Catching this before the account is active removes the problem at source. See number type detection for fraud for the VoIP screening pattern.
For high-value or first-time payments, check the active status and SIM swap recency of the sender's registered phone number. A SIM swap in the hours before a large payment is a high-confidence ATO indicator. If simSwap is SWAPPED and the swap is recent, step up to a second authentication factor before releasing the payment.
If you process incoming transfers, check the recipient's phone number before crediting the account. A recently registered number, a non-fixed VoIP type, or a SIM swap event in the preceding 24 hours on the account that is about to receive funds are all worth flagging for review. This is the signal that addresses the mule account scenario directly.
What a Telebase lookup returns
curl -s 'https://telebase.fatcatremote.com/api/lookup?phone=%2B447700900000' \ -H 'Authorization: Bearer tb_live_xxxxxxxxxxxxxxxxxxxxxxxx'
{
"phoneNumber": "+447700900000",
"active": true,
"carrier": "EE",
"country": "GB",
"numberType": "mobile",
"simSwap": "UNKNOWN", // launching for GB, DE, NL and FR
"simSwapAt": null,
"_meta": { "activeSource": "LINE_STATUS" }
}
All signals return in a single call. A numberType of nonFixedVoip or a simSwap of SWAPPED on either side of a payment is the actionable output. For the full ATO signal stack, see account takeover prevention with telecom signals.