How to stop Twilio SMS pumping and toll fraud

What SMS pumping and toll fraud actually do

SMS pumping fraud happens when fraudsters take advantage of an open phone number input field - like a sign-up form, an app download link, or a one-time passcode prompt - to trigger messages to a range of numbers. These destination numbers are controlled by a specific mobile network operator (MNO) that shares the generated messaging revenue with the fraudster.

Toll fraud, also known as International Revenue Sharing Fraud (IRSF), uses the exact same economic model but attacks voice endpoints instead. An attacker writes a script that triggers your application to place high volumes of international voice calls to premium rate numbers they control. While an SMS might cost a few cents, international calls can cost dollars per minute. The victim of the toll fraud bears the entire financial responsibility for each minute of the call, which makes voice abuse far more damaging to a small team.

Neither attack is trying to compromise your database or steal user credentials. They are treating your API credentials as a cash dispenser, routing traffic through billing corridors where they get an automated payout on the other end. If you want to understand how this fits into broader infrastructure cost spikes, see our breakdown of What is a denial-of-wallet attack, and how do I defend against it?.

Restrict SMS Geo Permissions in the console

By default, a newly created Twilio account only allows messages to be sent to your home country, which Twilio determines from the phone number you verified when you registered. Trouble starts when a team expands overseas and checks every box on the list, opening up hundreds of international destinations that genuine users will never touch.

To lock this down, navigate to Console > Messaging > Settings > Geo Permissions. You can toggle off every country where you do not have an active customer base. Saved changes take effect immediately. If your application attempts to deliver an SMS to a destination in a country where permissions are disabled, Twilio rejects the API request and returns Error 21408.

For security reasons, Twilio does not let anyone modify SMS Geo Permissions programmatically via the API. Only team members with Account Owner and Account Admin profiles can change these settings in the console. If you try to turn on permissions for a destination flagged as high risk, Twilio presents a Risk Acknowledgement Confirmation Dialog where you have to manually tick the "I Acknowledge this risk" checkbox and click "Enable Geo Permissions".

Keep subaccounts in mind if you isolate environments. A subaccount inherits the SMS Geo Permissions of its parent account by default, and inheritance only works between a single parent and its owned subaccounts. If you want to manage a subaccount independently, an Account Owner or Account Administrator must first disable inheritance on that subaccount. In a Twilio Organization with multiple accounts, no permissions inherit from the organization level, meaning you must set each account individually.

You can audit these adjustments in the console under Monitor > Insights > Audit > Audit Event Logs. If you track changes programmatically, query the Monitor Event REST API for the resource type sms-geographic-permissions, which reports creation, updates, and deletion events.

Configure Verify Fraud Guard protection levels

If you use Twilio Verify, turn on Verify Fraud Guard. It monitors your historical SMS traffic for unusual patterns, watching for traffic spikes and destination anomalies, and blocks the destination prefix of the suspected fraud automatically. Once enabled on a Service, protection begins immediately without any extra code changes on your server.

To switch it on for an existing service, go to Twilio Console > Verify > Services, click your Service, go to the SMS tab under Service settings, and adjust the Enable Fraud Guard setting. When Fraud Guard steps in to block a fraudulent delivery, you will see Error 60410 in your error logs, and Twilio will send an email alert with a direct link to your Verify logs. You can review all blocked activity on the Verify SMS Fraud Insights dashboard under Monitor > Insights > Verify > Fraud, where you can also export performance metrics as a CSV file.

Fraud Guard offers three protection levels depending on your footprint:

Standard is the default setting for a reason. It catches the vast majority of destination spikes while keeping false positives below 1%. If you operate in known high-risk territories, jump up to Max.

Fraud Guard may temporarily block traffic to regions known for pumping, destinations your account has never messaged before, or requests exhibiting non-human behavior. If a legitimate user gets caught, add their number to the Verify Safe List through the Safe List API or directly in the Blocked Verifications tab of Verify Logs. Numbers on the Safe List are never blocked by Fraud Guard or Geo permissions. You can also pass the RiskCheck parameter during verification to override fraud filters when you have already vetted the session upstream, or use Verify Geo Permissions to disable Fraud Guard for specific business-critical destinations. Custom verification codes are supported on both Standard and Max.

Keep in mind that Fraud Guard protects only the SMS channel. It does not support the Voice channel at all.

Harden voice verification and form logic

Because Fraud Guard leaves voice unprotected, automated toll fraud requires custom application guards. If you do not need voice passcodes, disable the Voice channel entirely. In the Twilio Console, select your Service under Verify, open the Voice tab, and switch the channel off. That eliminates IRSF exposure on your verification routes in one click.

If your product genuinely needs voice fallback, never offer it upfront. Twilio recommends keeping any "Call me instead" button hidden until the user has completed at least 3 time-delayed SMS attempts. Bots scraping simple forms will rarely wait through multiple delayed SMS cycles to find the voice button.

At the application layer, apply strict rate limits. Twilio recommends configuring Service Rate Limits so your app will not send more than 1 message per X seconds to the same mobile number range or prefix. Layer this alongside rate limits tied to the user session, client IP, or device identifier. Why let an anonymous client hit your endpoint twenty times a minute?

You should also integrate the Twilio Carrier Lookup API before firing off an SMS. It allows you to inspect the line type so you can restrict SMS delivery exclusively to mobile numbers, dropping landlines and VoIP ranges that fraudsters frequently abuse. Lookup also identifies the carrier, allowing you to drop specific MNOs associated with artificial traffic. If you do not want the paid lookup overhead for every request, Twilio provides a free Lookup formatting API that you can use to maintain a programmatic allow list or block list based on country codes.

Watch your conversion metrics closely. Calculate your one-time passcode conversion rate as the number of OTPs validated by end users divided by the number of OTPs sent. When bots pump your forms, they never validate the generated codes, causing this ratio to collapse. If your conversion rate suddenly drops in a specific country, wire an alert for manual review and configure account usage triggers to warn you when aggregate spending crosses an expected baseline.

If you spot active messaging abuse that slips through, gather your Account SID, Product Type, Date/time Range, To/Recipient Country, Workspace SID, and a brief description of the activity, and email fraud@twilio.com immediately.

Track runaway spend before it compounds

Application defenses stop known attack patterns, but configuration mistakes happen. A developer might enable global permissions during testing, or a new subaccount might bypass your rate limiter. Because Twilio has no hard spend cap, unmonitored toll fraud can burn through cash for days before anyone notices.

This is where Costbrake helps. Costbrake watches what you spend across 23 cloud, AI and SaaS providers, including Twilio, AWS, and OpenAI, tracking your usage against budget thresholds and baseline spending patterns. Checks run hourly on the Free plan ($0 for 2 connections) and every 5 minutes on Pro ($12 a month). During an active spike, Costbrake checks Twilio every 2 minutes for the next 2 hours.

If an attacker floods your Twilio endpoints, Costbrake fires a spike alert as soon as an hour costs more than 3x your 7-day hourly baseline and at least $5 above normal. Alerts can route through email, Slack, Discord, webhooks, or PagerDuty.

Costbrake also includes an opt-in, reversible killswitch called brakes on Pro and Team plans. A brake never fires automatically; an administrator must review the alert and confirm the action. For Twilio, Costbrake can block high-risk voice destinations by updating your voice geo permissions to disable calling to high-risk special and toll-fraud numbers while leaving normal routes open, or it can suspend an abused subaccount completely. It connects using a restricted API key with only read permissions for usage records, keeping credentials encrypted with AES-256-GCM. To connect Twilio or learn how usage monitoring works, read How do I set up Twilio usage alerts before a bill spikes? or follow the agent setup instructions.