# IRSF: international revenue share fraud, explained

> How international revenue share fraud turns your calls and texts into someone else's income, how it differs from SMS pumping, and how to cap your exposure.

Canonical: https://mobilevalidate.com/blog/irsf-international-revenue-share-fraud · Last updated: 2026-09-25

![Cover: IRSF: international revenue share fraud, explained](https://mobilevalidate.com/og/blog/irsf-international-revenue-share-fraud.png)


By MobileValidate team (https://mobilevalidate.com/about) · Published: 2026-09-25 · Category: Fraud prevention · Tags: Irsf, Toll fraud, SMS pumping, OTP, Fraud prevention

International revenue share fraud (IRSF) is telecom fraud in which someone generates calls or texts to numbers they profit from, usually international or special-rate ranges, and collects part of the fee you pay. Your app becomes the traffic source. The defence is to limit where traffic can go, how fast it can grow and which line types it may reach.

## What is IRSF?

IRSF exploits how money moves between operators. When a call or message crosses networks, the originating side pays for it, and part of that payment flows to whoever terminates the traffic. If a fraudster controls a block of numbers, or has a deal with a party that does, every call or text to those numbers earns them a share. The short version is in our [IRSF glossary entry](/glossary/irsf).

The traffic can come from anywhere that places calls or sends texts to a number someone else chooses:

- **A compromised phone system** that dials expensive destinations overnight.
- **A voice or SMS verification form** that a bot fills in with the fraudster's numbers.
- **A callback or "call me" feature** on a website.
- **Stolen or trial accounts** on a communications platform.

For app developers, the second and third routes matter most. Nobody breaks into your systems. The attacker uses a feature exactly as it was built, just with numbers of their choosing and at a volume you didn't plan for.

## How is IRSF different from SMS pumping?

They are close relatives. OWASP groups both under **cost-inflation fraud** (OAT-003), the "mass use of functionality to illegitimately profit from chargeable supporting services", and lists "SMS pumping" and "toll fraud" among its other names ([OWASP](https://github.com/OWASP/www-project-automated-threats-to-web-applications/blob/master/assets/oats/EN/OAT-003_Cost-Inflation_Fraud.md)).

| | IRSF (classic) | SMS pumping |
|---|---|---|
| Channel | Mostly voice calls; texts too | Text messages |
| Typical trigger | Compromised phone systems, callback features, voice OTP | Sign-up, login and "send code" forms |
| Destinations | International, premium-rate and global-service ranges | Often ordinary mobile ranges in high-fee countries |
| Money per event | Per minute, so long calls pay more | Per message |
| First sign | A spike in call minutes to unusual countries | Codes sent rise, codes verified stay flat |

If you already defend against pumping, you have half the controls. Voice needs extra care because the cost grows with call length. See [SMS pumping: how it works and how to stop it](/blog/sms-pumping-how-it-works-and-how-to-stop-it) for the text-message side.

## Why do international premium and special ranges matter?

Most numbers belong to a country code. A few codes belong to no country. The ITU publishes the list of E.164 country codes, which includes codes assigned to global services rather than to countries ([ITU](https://www.itu.int/pub/T-SP-E.164D)). Examples are satellite systems (+881 and others) and international networks (+882, +883). The ITU also defined a numbering scheme for universal international premium rate numbers ([ITU-T E.169.2](https://www.itu.int/rec/T-REC-E.169.2/en)), carried under +979.

These ranges share three properties that suit IRSF:

1. **Termination can be expensive**, which makes the revenue share worth having.
2. **Real customers rarely use them** for sign-ups or OTP, so blocking them costs you little.
3. **They are easy to miss** in a country allow-list that only thinks in terms of countries.

Within ordinary countries, the same logic applies to premium-rate, shared-cost and universal access (UAN) ranges. A number's [line type](/glossary/line-type) tells you which kind of range it belongs to.

## Which destinations are high-risk?

We won't publish a country list. Fraud moves, and any list gets out of date the week after it is written. The telecom industry tracks the trend: the Communications Fraud Control Association publishes a periodic fraud loss survey of its members ([CFCA](https://cfca.org/fraud-loss-survey/)).

What stays stable is the pattern. Risk concentrates where:

- terminating a call or text is expensive,
- number ranges can be hijacked or sub-allocated without much oversight, and
- you have no customers, so any traffic there is suspect by default.

That last point is the one you control. One of the most effective IRSF controls is still a short list of the countries you serve.

## How do you cap your exposure?

Stack independent controls, so one gap doesn't cost you a month of revenue. This decision table covers the main layers:

| Control | Rule | Stops | Cost to real users |
|---|---|---|---|
| Country allow-list (geo permissions) | Calls and texts only to countries you serve; exceptions reviewed | Most IRSF destinations | None in your markets |
| Global-service block | Block +881, +882, +883, +979 and similar codes by default | Satellite, network and premium global ranges | Near zero |
| Line-type check | Refuse `premium_rate`, `shared_cost`, `uan`; don't call `toll_free` for OTP | Special-rate ranges inside allowed countries | Near zero |
| Per-prefix velocity | Cap sends or calls per number prefix per hour | Bots walking through a block | Low |
| Per-country ceiling | Alert and pause when a country exceeds its normal hourly volume | Sudden spikes | Low, with a manual override |
| Call-duration cap | Hang up verification calls after the message plays | Long-duration payouts | None |
| Spend cap | Daily limit on your telephony account, with an alert well below it | Runaway bills | None |

OWASP's API Security Top 10 frames this as protecting a **sensitive business flow**: the risk is not a bug, but a legitimate flow used at a scale that hurts the business ([OWASP, 2023](https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/)). The fix is the same: limit who can trigger the flow, how often and to where.

## How does a line-type check help?

Allow-lists work at country level. Inside an allowed country, a number check tells you what kind of line you are about to pay for. With MobileValidate, the [carrier lookup](/services/carrier-lookup) returns `line_type`, `carrier` and `country` for a number, and a normalization step rejects impossible numbers for free.

A test-mode request with a valid test number, a repeated number and one that can't be parsed:

```bash
curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"numbers": ["+447700900001", "+447700900001", "12345"], "checks": ["carrier"], "wait": 5}'
```

Response (excerpt of `results`, test mode):

```json
[
  {"input": "+447700900001", "e164": "+447700900001", "country": "GB", "number_status": "valid",
   "checks": {"network.carrier": {"status": "completed", "registered": true,
     "attributes": {"line_type": "mobile", "carrier": "Test Carrier", "country": "GB"}, "billed": false}}},
  {"input": "+447700900001", "e164": "+447700900001", "country": "GB", "number_status": "duplicate"},
  {"input": "12345", "e164": null, "country": null, "number_status": "invalid_number"}
]
```

The duplicate and the invalid input are never checked or charged. Your code then applies the rules:

```js
const BLOCKED_CODES = ["881", "882", "883", "979"];            // global services; extend as needed
const REFUSE = ["premium_rate", "shared_cost", "uan"];

function irsfGate(r, allowedCountries) {
  if (r.number_status !== "valid") return "refuse";
  if (BLOCKED_CODES.some((cc) => r.e164.startsWith("+" + cc))) return "refuse";
  if (!allowedCountries.includes(r.country)) return "review";
  const line = r.checks?.["network.carrier"]?.attributes?.line_type;  // undefined when unknown
  if (REFUSE.includes(line)) return "refuse";
  if (line === "toll_free" || line === "fixed_line") return "no_sms";  // voice only, under stricter limits
  return "allow";                                                  // includes unknown: fall back to your limits
}
```

An `unknown` answer means we have no data for that number. It isn't charged, and it shouldn't block anyone on its own. The prefix limits and spend caps still apply.

## What should you monitor?

IRSF shows up in cost data before it shows up anywhere else. Watch these, per hour rather than per day:

- **Minutes and messages per destination country**, against the same hour last week.
- **Verification rate per country and per prefix**: codes entered divided by codes sent. Real users verify. Fraud traffic doesn't.
- **Average call duration** on verification calls. A verification call plays a short message. Long calls deserve a look.
- **New destinations**: the first call or text ever to a country or global-service code.
- **Spend against your cap**, with an alert at a fraction of it.

Give on-call staff a per-country kill switch. An attack that starts on a Friday night is cheap to stop at 2 a.m. and expensive to discover on Monday.

## What should you do when an attack is under way?

Speed matters more than precision. Every hour of an active attack is billed, so act first and fine-tune later:

1. **Pause the destination.** Switch off calls and texts to the affected country or global-service code with your kill switch or your provider's geographic permissions.
2. **Tighten the flow.** Lower per-prefix and per-IP limits on the feature being abused, and add a bot challenge if it had none.
3. **Tell your provider.** Report the traffic with timestamps and destination ranges. Providers see fraud across many customers and can often block ranges faster than you can.
4. **Preserve the evidence.** Keep request logs, IP addresses and the destination numbers (masked where you share them internally) for the dispute and for tuning your rules.
5. **Review after the fact.** Which control would have stopped it earliest? Add that control to the default setup for every new market.

Reopen the destination only when the controls that failed have been fixed and real customers there need it.

## What are the key takeaways?

- IRSF makes you pay for calls or texts to numbers that earn the fraudster a share of the fee. Your own verification and callback features are the usual route.
- It is a close relative of SMS pumping. OWASP groups both under cost-inflation fraud.
- Global-service codes and premium or shared-cost ranges are prime targets, and real customers rarely need them.
- Cap exposure in layers: country allow-list, global-service block, line-type check, per-prefix velocity, call-duration and spend caps.
- A line-type check removes special-rate ranges before you pay. Unknown answers are free and should fall back to your default limits, not block users.

The [SMS cost reduction use case](/use-cases/sms-cost-reduction) shows the same checks from a budget angle. For the pre-send pipeline behind every code, read [OTP fraud prevention: checks to run before sending a code](/blog/otp-fraud-prevention-checks-before-sending-a-code).

## Sources

1. [OAT-003 Cost-Inflation Fraud (OWASP Automated Threats to Web Applications)](https://github.com/OWASP/www-project-automated-threats-to-web-applications/blob/master/assets/oats/EN/OAT-003_Cost-Inflation_Fraud.md) — OWASP, 2026
2. [List of ITU-T Recommendation E.164 assigned country codes](https://www.itu.int/pub/T-SP-E.164D) — ITU
3. [Recommendation ITU-T E.169.2: universal international premium rate numbers](https://www.itu.int/rec/T-REC-E.169.2/en) — ITU, 2000
4. [Fraud Loss Survey](https://cfca.org/fraud-loss-survey/) — Communications Fraud Control Association (CFCA)
5. [OWASP API Security Top 10 (2023): API6 Unrestricted Access to Sensitive Business Flows](https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/) — OWASP, 2023

## Frequently asked questions

### What is the difference between IRSF and SMS pumping?

They share the same money trail: someone earns part of the fee for traffic to numbers they control. IRSF is the older, broader term and covers calls as well as texts, often to international or special ranges. SMS pumping is the variant that abuses app forms that send one-time passcodes.

### Which countries are high-risk for IRSF?

It changes over time, so a fixed list goes stale. Risk follows expensive termination and ranges that are easy to abuse. The safest rule is to allow calls and texts only to the countries where you have customers, and to review exceptions.

### Can a line-type check stop IRSF?

It removes a whole class of destinations, such as premium-rate, shared-cost and global-service ranges, before you pay. It doesn't catch fraud on ordinary mobile ranges, which is why you also need a country allow-list, per-prefix limits and spend caps.

### Who pays when IRSF happens?

Usually the business whose account generated the traffic. Your provider charges you for the calls or messages, whether or not a real person received them.