IRSF: international revenue share fraud, explained

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.

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).

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 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). 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), 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 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).

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:

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). 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 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:

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):

[
  {"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:

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 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.