Toll fraud is the oldest attack on telephony and it survives because the economics are so good. An attacker who gets into a phone system dials numbers whose termination pays out, and collects the revenue while the calls appear on somebody else's bill. There is no data to steal and nothing to ransom: the call itself is the payload.
That shapes the defence. You cannot detect it by looking for anything unusual in the content of a call, so the controls are all about where calls may go, how many there may be, and how much they may cost.
Why is this worth defending against if my system is locked down?
Because the value of a compromise is immediate and the window is short.
A stolen SIP credential or an open PBX port is worth money the same hour, which is why automated scanning for them is constant and why fraud tends to arrive as a burst overnight or over a weekend rather than as a slow leak. The attacker's incentive is to dial as much as possible before anyone notices, and the destinations that pay best are exactly the ones a normal business never calls.
That last point is what makes an allow list effective rather than merely tidy. Most businesses call a small and stable set of countries. An attacker needs a specific and different set. Anything that forces the two to overlap costs the attacker their entire business model.
How do destination controls work?
Every country is either enabled for your workspace or not, and calls only reach the ones you turned on.
Two separate things decide what you can do with a country, and conflating them is the usual confusion:
- Availability says whether the country is yours to enable at all.
Availablemeans Bird can place calls there from your account.Not supportedmeans it cannot, and restoring it is a support conversation. - Your toggle says whether an available country is switched on. The change applies from the moment you make it.
So a country being available tells you nothing about whether calls are currently reaching it. That is the toggle, and it is the control that matters for fraud.
Some countries carry a high risk marker, which reflects both their rates and their fraud exposure. Those are the destinations an attacker is trying to reach. Keep them off unless the business genuinely calls them, and check what a call there costs before enabling one. The voice destinations page lists every country with its availability and enabled state, and voice pricing carries the rates.
When a call is refused for this reason it is rejected with destination_not_enabled, and the fix is to turn that country on rather than to retry.
One thing to expect that the toggle does not cover: availability applies to a country as a whole, so a specific number inside an enabled country can still be unreachable. That is rejected as no_route_found, and the action is to contact support with the call ID rather than to change your destination settings, which are not the cause.
What stops an attack inside a country I do allow?
Three ceilings, each of which refuses a call on its own.
| Rejection reason | The ceiling it hit |
|---|---|
daily_spend_exceeded | Your organization's daily voice spend ceiling |
concurrent_calls_exceeded | As many calls in progress as the account allows |
calls_per_second_exceeded | New calls placed faster than the account allows |
insufficient_balance | The wallet did not cover the call, so it was refused up front |
The spend ceiling is the one that behaves most like a fraud control, because it is denominated in the thing the attacker is actually taking, and it is enforced on a different path from the other two. It resets at the start of the next UTC day, so a burst that hits it is contained until then rather than merely slowed. It is also the one that does not exist until you set it: an organization with no daily voice ceiling configured has no spend ceiling enforced at all.
Two things about how the other two behave are worth knowing before you rely on them.
They are checked in order, not together. The concurrent-call ceiling is evaluated first and answers immediately, so a call that is over both ceilings reports concurrent_calls_exceeded and never mentions the dial rate. That matters for diagnosis rather than defence: a campaign dialer can hit calls_per_second_exceeded while nowhere near the concurrent ceiling, so check which one you actually got before changing any setting, since they have different fixes and raising the wrong one does nothing.
A ceiling whose own check cannot complete admits the call. If the concurrent count or the rate limiter cannot be evaluated, the call goes through rather than being refused. So these ceilings bound normal operation reliably and are not a guarantee under every condition, which is another reason the destination list matters: it is the layer that does not depend on a live lookup.
insufficient_balance deserves a mention as an accidental control. It is a hard stop on how much fraud can happen, which is an argument for thinking about automatic top-ups as a fraud decision rather than only a convenience one: a large automatic top-up removes the last backstop.
Who can send calls to my trunk in the first place?
The layer before all of this, and the one an attack has to get through.
A SIP trunk decides who may send it calls, and a call from anywhere else is rejected with source_not_allowed before any destination logic runs. Outbound calls are also checked against your verified caller IDs, so a call presenting a number that is not verified for the workspace is rejected with caller_id_not_verified rather than placed.
Those two are worth auditing on the same schedule as your destination list, because a permissive allow list undoes the rest. SIP trunks covers the IP allow list, API key authentication and session credentials, and caller IDs covers verification.
What should I actually do?
- Enable the countries you call and no others, and treat the list as something to review rather than something to set once. A country enabled for one campaign two years ago is a standing exposure.
- Set a daily spend ceiling, and size it so you would notice it being hit rather than so it never triggers. There is no ceiling until you configure one, and a ceiling that never fires is not a control.
- Tighten the trunk's allow list, since everything above only matters to calls that got that far.
- Watch for the rejection reasons themselves. A sudden run of
destination_not_enabledorcalls_per_second_exceededis what an attack looks like when the controls are working. They are not noise to filter out of your logs; they are the alert.
Voice destinations covers enabling and disabling countries, and the call log lists every rejection reason with its fix.