For about a week, we saw a pattern in our outbound call traffic that did not look like normal usage. A cluster of accounts, all fairly new, placing calls almost exclusively to a small set of international destinations. The calls connected. They did not sound like conversations.
This is the signature of a well-documented telecom fraud category called International Revenue Share Fraud, or IRSF. [Akamai has a good writeup](https://www.akamai.com/blog/security/understanding-international-revenue-share-fraud) of the mechanics if you want the general background. Here is what it looked like from our side, and what we changed.
What IRSF actually is
The economics are simple, which is exactly why it keeps happening across the industry. Some international phone numbers carry a revenue-share agreement: whoever terminates a call to that number gets paid a small amount per minute, funded by whoever originated the call. This exists for legitimate reasons -- it is part of how international interconnect works.
A fraud ring exploits it by controlling both ends. They sign up for an account with a voice platform, and they also control (or have arranged a payout deal on) a set of premium destination numbers in a handful of countries. They place calls from the platform to their own numbers. The calls do not need a real conversation -- an auto-answer or a silent line held open is enough to generate billable minutes. The platform pays for origination. The fraud ring collects the termination revenue share. The difference is their profit, and it is our cost.
The reason this is hard to stop with a static list is that fraud rings do not sit still. Once a specific route stops paying off -- because a carrier gets flagged, because a country's numbers get blocked -- they move to a different carrier, a different country, sometimes within days. A defense that only reacts to what happened last week is already a step behind.
How we caught it
The tell was not any single call -- it was the shape of the pattern across accounts: a cluster of recently created accounts, calling almost exclusively toward a narrow set of international destinations, with call behavior that did not resemble real usage (no real back-and-forth, consistent short durations, concentrated into a handful of specific numbers rather than spread across normal calling patterns).
None of those signals alone proves fraud. Together, clustered across multiple accounts hitting the same narrow set of destinations, they were unambiguous.
What we changed
We shipped two layers of defense, aimed at two different parts of the attack.
Before a call connects, we check where it's actually going. For international destinations, we now resolve the terminating carrier in real time and check it against a risk list before the call is placed. If the destination matches a known-bad pattern, the call is rejected before it connects -- so no billable minute is ever generated in the first place. That risk list is data we can update immediately, without shipping code, specifically because the whole point of this kind of fraud is that the bad destinations keep moving. A defense that requires an engineering release every time a fraud ring pivots to a new carrier is already too slow to matter.
We also closed the path that fed it. IRSF requires an attacker to control accounts, typically a lot of them, cheaply. We tightened how quickly a single source can spin up new accounts, cutting off the mass-signup pipeline that made the attack economical in the first place. This matters more than it sounds -- blocking the destinations stops the specific campaign; slowing account creation makes the next campaign more expensive to run at all.
When a call is blocked by this system, the customer sees a generic failure message, not a "this destination is flagged for fraud" explanation. That is deliberate. The overwhelming majority of people who ever see that error are not the fraud ring -- they are innocent customers who happened to dial an affected number for a legitimate reason, and there is no reason to expose our detection logic to anyone, legitimate or not. The specific reason is logged and reviewed on our side.
One constraint we held firm on: this system fails open. If the underlying lookup used to check a destination is ever unavailable, we let the call through rather than block it. A fraud control is not allowed to become the reason a real customer's real call fails to connect. Under-blocking for a few minutes during an outage is an acceptable cost. Blocking legitimate traffic because a dependency hiccupped is not.
What this means if you build on Dial
You should never need to know any of this happened. That is the point. Number reputation, carrier-level fraud economics, international interconnect risk -- this is exactly the kind of infrastructure problem that belongs to the platform, not to every team building on top of it.
Fraud rings adapt, which means this is not a one-time fix -- it is an ongoing part of running voice infrastructure at any scale. We treat it that way. If you are building an agent that needs to place real calls to real people, the fact that you never have to think about any of this is the actual product.