OTP Theft and Impersonation Scams: Watch the Session

The call comes in around evening. The caller knows the customer's name and the last four digits of their card. He says he is from the bank's fraud team, there has been suspicious activity, and he needs to verify the account. A code arrives by SMS. The customer reads it out.

Six minutes later a new device logs into the account, changes the registered phone number, adds a beneficiary, and transfers most of the balance. By the time the customer calls the real bank, the money has passed through two mule accounts.

This pattern, or a variant with a fake delivery fee or a fake government fine, is behind a large share of retail fraud in the Kingdom. The transaction itself often looks normal: a transfer the customer's account is allowed to make, to an account at a local bank, for an amount that does not trip any threshold. If your fraud checks start at the payment, they start too late.

The session tells the story

Look at the same six minutes from the platform's side, event by event:

1. An OTP is requested for the account. 2. A login succeeds from a device never seen on this account, on a different network. 3. The phone number or email is changed. 4. A new beneficiary is added. 5. A transfer goes to that beneficiary for most of the available balance.

No single step is damning. Customers change phones. They add beneficiaries. Together, in that order, inside one session, they are close to a signature.

Rules that catch the sequence

Score every step, not just the last one. That means sending logins, contact detail changes, and beneficiary changes to your fraud engine as events, with the device fingerprint attached.

• New device plus a contact detail change within the same session: REVIEW, or require re-verification through a channel the fraudster does not control.
• New beneficiary added from a device first seen today: hold transfers to that beneficiary for a cooling-off period.
• Transfer of more than most of the balance to a beneficiary added less than an hour ago: REVIEW.
• Beneficiary account already linked to other customers' recent first transfers: BLOCK or REVIEW, depending on how many.

The last rule matters more than it looks. Mule accounts receive money from many victims. When three unrelated customers send their first-ever transfer to the same account in one day, that account is the problem.

Friction in the right place

Nobody wants to add friction to every transfer. You don't have to. A long-standing customer on their usual phone, sending money to a beneficiary they have paid before, should feel nothing. Friction belongs on the narrow set of sessions that look like the sequence above, and it should be friction the fraudster cannot pass: a call-back to the original phone number, an in-app confirmation on the old device, or a delay on newly added beneficiaries.

Measure it honestly

Run new rules in observation mode first and compare them with the fraud reports you already received. How many reported cases would the rule have caught, and how many genuine customers would it have stopped? That comparison, not a vendor's claim, is what tells you where to set the dial.

Naiza scores logins, profile changes, and payments as separate events with device context, so rules can see the whole session. The fraud detection API page covers the event model, and the financial fraud guide walks through the common schemes.