Rate this page:

Preventing Toll Fraud

If you are about to build and/or have deployed phone verification or two-factor authentication (2FA) in your app or on the internet, then it is extremely important that you are aware of the threat of International Revenue Sharing Fraud (IRSF) also known as “Toll Fraud”. Fraudsters commonly target phone verification or 2FA flows with the goal of generating a high volume of voice calls or SMS to expensive destinations. Our simple diagram below illustrates how fraudsters can abuse your app to commit toll fraud. For a deep dive, learn more from our whitepaper or in the blog post on best practices for managing retry logic with SMS 2FA.


Customer participation and shared responsibility are essential to successfully defend against toll fraud attacks. Our Verify and Authy products both include comprehensive built-in fraud detection and mitigation mechanisms. However, no provider-side solution can guarantee 100% effectiveness against sophisticated attackers using dynamic, constantly changing phone numbers and countries.

By implementing these simple safeguards to limit and restrict sending of one-time passcodes (OTPs) in your Verify deployment, you can greatly reduce the risk of toll fraud saving you much headache in the future.

Highly Recommended Actions

1. Disable unused channels

If you don't plan to allow any calls, you can disable the channel at the service level in the Verify service console settings.

Verify service with call channel disabled

2. Use the following Verification Retry Logic in your application code:

  • Use our Lookup API to identify if the phone number is a landline. Then if the phone number is not a landline phone number, require 3 time-delayed SMS attempts before allowing the voice OTP call option. You can find a more detailed example workflow on our Fraud Prevention blog post.
  • If you cannot use the SMS channel and must rely on voice to verify a user, ensure you implement the recommendations below to mitigate abuse from a bad actor requesting voice OTPs.
  • Make sure to include the logic in both your backend and frontend application code, not only in the frontend UI/mobile application code
Good Example - “Call me instead” option is not visible until 3 time-delayed SMS attempts. Bad Example - “Call me instead” option is visible at any time and can be repeatedly submitted.
Good Example

Bad Example

3. Set Rate Limits on requesting verifications

  • Use Verify Service Rate Limits or build your own to proactively suppress and rate limit your verifications.
  • Implement rate limits by user, IP, or device identifier. For example, 20 verification per hour per IP or 50 per day per IP. Web servers like Nginx and Apache support basic rate limiting through modules to prevent DDOS attacks. Standard security measures like this will raise the bar for an attacker.

Recommended Actions

4. Restrict Destination Countries by managing your own allow/deny lists

  • If you only have customers in certain countries, you can restrict verifications to specific countries (e.g. “allow list”) by using the free Twilio Formatting Lookup to determine the country of the phone number being verified.
  • Alternatively, you can disallow countries that you do not want to allow verifications based on the country of the phone number being verified (e.g. “deny list”).
  • If you have data on the number of verifications you’d expect per day in a given country, you can set rate limits on groups of countries, allowing relaxed rate limits in countries where you expect legitimate users, and more restricted rate limits in all other countries.

5. Create Alerts

  • Create internal monitors for conversion rate of verifications (Number of OTP Validated by end users / Number of OTP sent by end users) and verification volume. Having a spike in verifications to an unexpected country along with a sharp drop in conversion rate could mean you’re facing a toll fraud attack, but it can also mean you’re facing delivery issues.
  • Configure a Usage Trigger on your account to alert you when your usage goes above a certain threshold.

Optional Actions

6. Analyze IP

  • Analyze IP location, IP owner (ISP/proxy/TOR/cloud provider, etc), and IP against the bad reputation list. Block TOR/Cloud Providers/proxies/bad IPs.

7. Implement CAPTCHA in the backend

  • Implement CAPTCHA for voice calls, define thresholds when you should ask for them. For example, after the first or second unverified request.

If you’re interested in learning more, check out the resources from Twilio below:

Everything You Need to Know About Toll Fraud (White Paper under Voice and Phone)

Fraud Prevention with Twilio Account Security (Blog, 2019.0603)

How Fraudsters Can Abuse Your Voice App and What You Can Do About It (SIGNAL 2018)

Anti-Fraud Developer Guide (Dev Docs)

Rate this page:

Need some help?

We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd by visiting Twilio's Community Forums or browsing the Twilio tag on Stack Overflow.


        Thank you for your feedback!

        We are always striving to improve our documentation quality, and your feedback is valuable to us. How could this documentation serve you better?

        Sending your feedback...
        🎉 Thank you for your feedback!
        Something went wrong. Please try again.

        Thanks for your feedback!

        Refer us and get $10 in 3 simple steps!

        Step 1

        Get link

        Get a free personal referral link here

        Step 2

        Give $10

        Your user signs up and upgrade using link

        Step 3

        Get $10

        1,250 free SMSes
        OR 1,000 free voice mins
        OR 12,000 chats
        OR more