Fraud Prevention API

A verified phone number establishes one narrow fact: at a given moment, whoever was using your product controlled that number. It says nothing about the person's name, age, intentions or history. Fraud systems that forget this end up over-trusting a signal that was never meant to carry that much.

What makes the narrow fact valuable is its price. Email addresses are free and infinite. Phone numbers are neither — each one costs a SIM or a messaging account, and a WhatsApp account is itself the product of a verification. Verification does not make abuse impossible; it makes abuse cost something per attempt, which is usually enough to change who bothers.

Scripted registration is the clearest case. A bot farm creating accounts against an email-only form scales at effectively zero marginal cost. Put a verified number in the path and each account needs a distinct, working number behind it — the attack still exists, but its unit economics collapse.

The same logic applies to anything measured per account: trial abuse, rate-limit evasion by re-registration, and scraping accounts created faster than they can be banned.

Referral schemes, welcome credits and first-order discounts all depend on being able to tell one person from fifty. Without a scarce identifier there is no such thing as a first-time user, only a first-time email address.

Attaching offers to verified numbers rather than to accounts closes the loop. It also gives you a clean rule to enforce, which matters as much as the check itself: a policy that a number may back one bonus claim is auditable, while a policy about 'the same person' is not.

It is worth being honest that the usual defence has its own fraud problem. SMS one-time passwords are billed per message, which makes them a revenue stream for artificially inflated traffic: an attacker triggers enormous volumes of sends to numbers on routes they profit from, and you pay for every one. The accounts are never created; the invoice is the attack.

A Reverse OTP flow is structurally immune to this, because nothing is sent outbound. The user sends the message. There is no per-attempt delivery cost to inflate, and a bot hammering your start-verification endpoint generates sessions that nobody completes rather than a bill.

SMS codes are also a weak link at the other end. In a SIM swap, an attacker persuades a carrier to move the victim's number onto a SIM they control, and every code sent to it lands in the wrong hands. The user does nothing wrong and notices nothing until their account is gone.

Reverse OTP does not send a code, so there is none to redirect; proof comes from a WhatsApp account, which is bound to the device and protected separately. That is a meaningfully different exposure, though not a total answer — layer it with your own signals for anything high-value.

Use verification as a gate on actions that cost you something — claiming a bonus, withdrawing, messaging other users, publishing — rather than as a blanket wall at the door. Keep rate limits regardless: verification prices abuse, it does not throttle it.

And keep the proof once you have it. A number verified at signup can back later step-up checks and account recovery without a second enrolment, so each additional use of the signal costs nothing further.