How Cross-Border Businesses Can Prevent SMS Verification Code Attacks: First Block Non-Business Countries, Then Rate-Limit, Verify Numbers, and Monito

When SMS verification code endpoints at cross-border businesses get abused, the most common and costly scenario is usually not data theft but SMS toll fraud, also known as SMS Pumping, Artificially Inflated Traffic (AIT), or Toll Fraud. Attackers exploit your public registration, login, and password reset endpoints to trigger large volumes of SMS to high-cost region numbers, then share the international settlement fees with local carriers. You foot the bill.

If you can only do a few things first, this order is usually the most cost-effective:

1. At the SMS gateway layer, only allow countries and regions where you actually do business;
2. Add human verification before sending codes, and confirm requests come from a complete page flow;
3. Rate limit separately by phone number, IP, and device;
4. Set hourly and daily sending caps per country, plus budget circuit breakers;
5. Monitor the ratio of send volume to verification success rate, and automatically throttle when anomalies appear.

Below, we explain each layer: what it protects against, how to configure it, and where it can accidentally block real users.

First, distinguish which attack you're defending against

There are three common attacks on verification code endpoints, each with different characteristics and defenses:

• Toll fraud: Attackers want the act of "sending" itself. Target numbers are concentrated in specific number ranges of high-cost countries, often sequential or bulk fake numbers, and the codes are never verified.
• SMS bombing: Attackers use your endpoint to harass a real user while consuming your quota. Typical sign: the same number is requested repeatedly.
• Brute force: Attackers are guessing verification codes. Typical sign: an unusually high number of verification attempts for the same number.

The first two require "send less, don't send indiscriminately." The third requires limiting verification attempts and shortening code validity. Many teams only implement per-number rate limiting, which stops bombing but not toll fraud, because attackers rotate through many numbers, sending only one or two codes per number.

Layer 1: Turn off countries where you don't do business

This is the fastest-acting step. Toll fraud requires routing SMS to remote, high-priced number ranges to profit. If you have no business there, there's no reason to send SMS there. You can set a country whitelist in your SMS provider's console or your own gateway layer, rejecting sends to countries outside the list.

For allowed countries, set hourly and daily send caps and budget thresholds separately, with automatic suspension when reached. Base thresholds on normal peaks over the past few weeks, leaving headroom. Remember to temporarily raise them before major promotions or concentrated campaigns.

One exception: some products naturally have users scattered across many countries, such as travel or study-abroad products. A blanket block would cut off real users. In that case, default to open for non-core countries but set lower thresholds, and apply stricter human verification for those countries.

Each provider's built-in anti-fraud capabilities and configuration differ. For example, Twilio offers protection options against SMS Pumping, and Alibaba Cloud and NetEase Yunxin have international SMS anti-fraud settings. Confirm what your provider already offers before deciding what you need to add yourself.

Layer 2: Confirm a human is on the other end before sending

"Send verification code" should not be a bare endpoint anyone can call directly.

• Human verification: Before the user clicks "Get code," require a slider, image CAPTCHA, or invisible behavioral verification. For high-risk cases, escalate to an interactive challenge.
• Bind to page flow: Use sessions or CSRF tokens to tie the code request to the page flow. The server only accepts requests that first opened the registration page and obtained a token. Tokens are single-use and short-lived. This blocks scripts calling the endpoint directly.
• Device fingerprinting: Attackers often use rotating residential proxy IPs, making IP blacklists quickly ineffective. Device characteristics are more stable, allowing you to group requests from the same device across different IPs.

Layer 3: Multi-dimensional rate limiting

Rate limiting on a single dimension is easily bypassed. Implement several of the following. These values are just starting points:

• Per number: At least 60 seconds between sends, with exponential backoff for subsequent retries; also set a daily cap.
• Per IP or subnet: Limit total requests in a short period. When requests from the same subnet cluster, increase human verification difficulty.
• Per device: Combined with device fingerprinting, limit how many different numbers a single device can request codes for per day. This is most effective against toll fraud where each number only receives one message.
• Verification attempts: Allow only a limited number of wrong entries per code, then invalidate it, and set a short validity period to prevent brute force.

After launch, adjust these values based on real user retry patterns. Overseas users with poor signal may retry more, and overly strict limits will hurt them first.

Layer 4: Check the number before sending

• Format validation: Check E.164 format first; reject mismatched country codes and lengths.
• Carrier lookup and risk scoring: Use services like Carrier Lookup to identify high-cost premium numbers, invalid numbers, and high-risk ranges, then block according to your policy.
• Sequential and clustered numbers: A string of adjacent numbers in a short time, or many requests from the same number range, likely indicates bulk fake numbers.

Whether to block virtual or VoIP numbers depends on your business; stricter isn't always better. Payment, financial, or platforms emphasizing one account per person often require physical SIM or eSIM numbers from local carriers. Community or tool products that reject all virtual numbers will block some legitimate users. For the difference between the two types, see What is a VoIP phone number: how it works and why it often can't receive verification codes.

Layer 5: Monitor verification success rate and trip the circuit breaker on anomalies

The most useful monitoring metric is OTP conversion rate—the percentage of sent codes that are correctly submitted within a few minutes. Normal users typically complete verification quickly after receiving the code; toll fraud numbers never verify.

At minimum, your dashboard should show send volume and success rate by country and number range, with automated rules such as:

• If a country's send volume is significantly above normal while success rate drops to near zero, automatically throttle or pause that country and notify on-call staff;
• If a number range shows concentrated high-frequency requests, automatically increase verification difficulty or block that range.

Alerts alone are not enough; the circuit breaker should execute automatically. Attacks often happen late at night, and by the time someone sees the alert, the bill may already be incurred.

Route high-risk requests differently

For requests with multiple retries, high risk scores, or from high-cost countries, you don't have to send international SMS. Use email codes, WhatsApp OTP, or voice verification instead, or guide users to passwordless login with Passkey (WebAuthn). This lowers per-verification cost and removes an abusable channel. Apply the same rate limiting and monitoring to alternative channels.

After tightening rules, regression test with real numbers

More rules mean a higher chance of blocking legitimate users. For example, the whitelist might miss a country, number-type policies might block legitimate carrier numbers, or rate limits might block normal retries. Before and after launch, ideally walk through registration, login, and password reset with real local numbers in each open country to confirm codes are delivered and rate-limit messages display correctly.

If your team lacks local numbers for each country, you can select numbers by country on NexSMS and view codes in real time on the web. Short-term numbers are sufficient for one-off checks. For regular regression testing, use long-term premium numbers: they are real local carrier numbers that can receive unlimited codes during their validity period, ideal as fixed test numbers, but must be renewed before expiry to keep them. For the difference between the two types and renewal terms, see NexSMS feature documentation. Use these numbers only for testing your own product flows.

Already being attacked: stop the bleeding first, then investigate

1. Immediately pause sending to anomalous countries or number ranges at the gateway, or temporarily require all code requests to pass human verification first;
2. Set or lower budget caps per country;
3. Export send logs, aggregate by country, number range, IP, and device to identify attack patterns and add them to the rules above;
4. Contact your SMS provider, explain the abnormal traffic, and confirm what handling mechanisms and protection options they have.