SBC Toll Fraud Prevention in Real Time: How Detection Actually Works at the Call-Setup Window

Toll fraud is a latency problem. The longer it takes to recognise a fraudulent call, the more money the call earns the attacker and the less of it can be charged back. Every minute that an International Revenue Share Fraud session stays connected is revenue arriving in someone else’s premium-rate account. By the time the carrier bill lands four weeks later, the money is gone.

“Real-time” in this context is not a marketing adjective. It is a specific position on a timeline. A Session Border Controller is the only network element that sits in the SIP signalling path with the authority and the latency budget to act inside the call-setup window, before the called party answers and before any toll cost accrues. Network firewalls run too low in the stack to read the SIP message. Billing systems run too late in the workflow to stop the call. The SBC is the one place where detection and prevention can happen in the same operation.

This article is about the mechanics of that operation: what an SBC can actually see during call setup, which fraud typologies leave signals that are visible in flight, how the detection pipeline runs inside a programmable SBC, and how operators turn those mechanics into a working detection practice. For the broader threat overview and the five-layer security stack the SBC provides, see the SBC Security guide.

What “Real-Time” Actually Means for Toll Fraud Detection

Most toll fraud articles use “real-time” to mean “sporadic, not made in batch”, because making calls in batch is an easy hint to detect while sporadic calls are hard to design against. For an SBC, real-time detection lives on a three-window timeline, and each window has a different cost profile and a different set of available signals.

The call-setup window runs from the moment the SBC receives an inbound INVITE to the moment a final response is sent (200 OK to answer, or a 4xx/5xx/6xx to reject). The full latency budget for any in-flight decision is here, typically a few hundred milliseconds before the originating party starts to perceive setup delay. A call blocked inside this window costs the operator nothing, because no media is established and no termination charges are billed. This is the only window where prevention is genuinely free.

The mid-call window runs from the 200 OK to the BYE. The call is connected, media is flowing, and any termination minutes are already accruing. An SBC can still terminate the call mid-session if a downstream signal indicates fraud, but every second between detection and termination is billable. Mid-call cuts are most useful for slow-burn fraud such as a long-running call to a premium-rate destination that did not match any pre-call signal.

The post-call window runs from BYE onward, into the CDR record. This is where pattern analysis lives: trailing-window aggregates, cross-trunk correlations, attacker fingerprinting. None of it stops the current call, but it is the loop that improves detection for the next one. A fraud event that escapes the first two windows shows up in post-call analytics within minutes if the data pipeline is set up correctly, and the resulting block list flows back into the call-setup window in time to stop the rest of the wave.

Genuine real-time toll fraud defence uses all three. A practical SBC deployment runs scoring in the call-setup window for every call, runs anomaly detection in monitoring dashboards for the mid-call window, and feeds post-call signals back into the call-setup rules. The article that follows focuses on the first window, because that is the one that matters for stopping the call cost-free, but the other two are how the first one stays sharp.

The Five Toll Fraud Typologies an SBC Has to Recognise

Toll fraud is not a single attack. It is a family of schemes that share the goal of converting somebody else’s voice minutes into the attacker’s revenue. Each typology has a distinct call-pattern signature, which is what makes real-time detection possible at all.

Recognising the typology matters because the response is different in each case. An IRSF call should be blocked at the SBC with a 603 Decline, because the destination itself is the fraud vector. A PBX-hacking call should be blocked and the customer should be alerted, because the SIP trunk is the fraud vector and the customer almost certainly does not know it. A traffic-pumping call should be rate-limited rather than blocked outright, because the destination range may be legitimate at low volumes and only fraudulent in bulk.

The Detection Signals Visible During the Call-Setup

The SBC sees the SIP INVITE before any decision is made about routing. Everything in that message, plus everything the SBC has learned from prior calls on the same trunk and from prior calls to the same destination, is available for evaluation. There are six families of signal that matter.

Destination signals are the strongest single predictor of toll fraud and the easiest to act on. The B-number prefix, the country code, and the rate-zone classification can be looked up against an internal block list, a partner block list, or a real-time scoring service. ProSBC exposes the B-number directly to the routing script and supports parallel queries against external fraud APIs during the same call-setup pass.

Source signals are the calling number reputation and the originating trunk identity. The SBC keeps source statistics per NAP (its term for a SIP peer) and exposes them to the routing script for use in scoring.

Velocity signals are short-window aggregates. CPS spikes, concurrent-call jumps, sudden ACD changes, and ASR collapses are all visible in the SBC’s internal counters and accessible from the routing chain. These signals catch fraud events that are not visible from any single call but become obvious across a trailing five-minute window.

Behavioural signals are pattern-match signals. Repeated short-duration attempts to the same destination from rotating A-numbers, identical SIP headers across calls that should be unique or random rather than repeated, INVITEs that retry on a sub-second interval, registration patterns that look automated rather than human. None of these are conclusive on their own; combined, they reliably indicate an active fraud event.

Identity signals are the STIR/SHAKEN verification result and the CNAM lookup result, when available. A call that arrives with a failed Identity-header verification or with an A-number whose CNAM record is missing or recently changed gets a worse fraud score than one that verifies cleanly. Identity signals do not catch fraud on their own, but they sharpen every other signal, particularly for spoofing-driven schemes like Wangiri. The STIR/SHAKEN call authentication guide covers the verification flow in detail.

Context signals are the time of day, day of week, and business-pattern signals against the historical baseline of the trunk. A customer trunk that has originated 50 calls per day to North American destinations during business hours and suddenly originates 500 calls per hour to a Caribbean destination at 2 AM is producing a context signal that no single call would expose.

The discipline is to use the signals in combination. A B-number on a watchlist by itself can be a false positive (legitimate businesses do call premium-rate numbers). A CPS spike by itself can be a false positive (a marketing campaign just launched). The combination of a watchlist B-number plus a CPS spike plus a non-business hour is reliably fraud, and the routing script can compute that combination in the call-setup window.

How the Detection Pipeline Runs Inside the ProSBC

ProSBC processes each inbound INVITE through a Ruby routing chain. The chain has three filter stages: before_filter (runs before route selection), after_filter (runs after route selection but before message remap), and after_remap_filter (runs after the outbound INVITE has been constructed). Real-time toll fraud detection is a before_filter operation by design, because the goal is to block, divert, or throttle the call before it ever advances to an outbound route.

A typical detection chain runs in this sequence. First, local block-list and allow-list modules (BlackWhiteListing, blacklist.csv, whitelist database) eliminate calls that match static rules. These are zero-latency checks. Second, the routing script queries one or more external scoring services. TransNexus ClearIP is the most common production integration; SecureLogix and YouMail are also supported. The query runs over SIP redirect (the deployed pattern) or HTTPS (the alternate capability) and returns a verdict carried in the SIP response code. Third, Reason Cause Mapping converts that response into a routing action: 603 Decline stops the call, 404 advances to the next route, 503 advances to the failover route, 302 redirects to a fraud analysis queue. Fourth, velocity and concurrency checks run against ProSBC’s internal counters to catch fraud that no single-call scoring service can see.

The latency budget for this whole chain is a few hundred milliseconds during call setup. External scoring queries are the dominant contributor, and they are designed to fit inside the natural ring-back delay so that the originating party does not perceive any added wait. If a scoring service fails to respond inside its configured timeout, Reason Cause Mapping handles the failure path explicitly: the script can fall through to a static decision (route, block, or divert) rather than block the call by accident.

The architecture matters because static rules cannot keep up with toll fraud at scale. IRSF actors rotate destination ranges every few hours. Wangiri waves use new A-numbers each round. PBX-hacking sessions distribute themselves across customer trunks to stay below per-trunk thresholds. A working detection pipeline has to query live intelligence on every call and compose that intelligence with local signals in the routing script. ProSBC’s filter chain is built for exactly that pattern; the SBC REST API call routing integration guide covers the integration mechanics in depth.

What to Do When Detection Triggers

Detecting fraud is half the work. The harder half is responding in a way that stops the attacker without breaking legitimate traffic. There are four practical responses at the SBC, and each fits a different confidence level.

Block is the right response when the score is unambiguous. The SBC returns 603 Decline (or another configured cause) and the call never advances. No media, no termination cost, no customer-visible artefact other than a failed call. This is the default for high-confidence IRSF and for any call to a number range on a hard block list.

Divert is the right response when the score is high but the cost of a false positive is also high. The SBC redirects the call to a fraud-analysis queue: a separate trunk, an IVR that challenges the caller, or a human analyst. ProSBC supports redirect routing via 302 Moved Temporarily and via internal route advancement. Divert is most useful for inbound Wangiri investigation and for borderline PBX-hacking patterns where the caller (A-number) needs to authorise the destination before the call proceeds.

Throttle is the right response when the underlying source might be legitimate but the volume looks abusive. ProSBC’s percentage-based greylisting lets the operator block a configurable fraction of calls from a source while letting the rest through. A 90% greylist effectively starves a fraud campaign of revenue without cutting off the source entirely. This is the standard response to suspected wholesale arbitrage and to traffic-pumping campaigns where the destination range has legitimate users.

Alert is the right response when the SBC has detected an anomaly but cannot yet act with confidence. The call proceeds, the event is written to the CDR with the score and the rule that fired, and a downstream system (monitoring dashboard, SIEM, ticketing system) raises a human-reviewable alert. Alert-without-action is necessary for any operator running a fraud detection practice; it is the only way to learn what the false-positive rate of a new rule actually is before promoting it to block.

The four responses compose. A typical configuration blocks the worst category outright, diverts the medium category to a queue, throttles the borderline category, and alerts on the noise floor. Promotion between categories is a tuning exercise that runs over weeks: a rule that consistently catches fraud at the alert tier earns the right to move up to throttle, then to divert, then to block.

Building a Real-Time Detection Practice (Operator Playbook)

The mechanics above only matter if the operator has a practice that uses them. Four KPIs make the difference between a working detection pipeline and a configured-but-ignored one.

The first is block rate, the fraction of inbound calls the SBC declines on suspected fraud. Most carriers settle into a single-digit percentage on enterprise trunks and a higher rate on wholesale trunks. A block rate that drifts toward zero usually means the rules have stopped firing because the attackers have rotated past them; a block rate that suddenly spikes means a real fraud wave is hitting and the rules are working. Both directions are worth alerting on.

The second is false-positive rate, the fraction of blocked calls that turn out to have been legitimate. False positives are measured by complaints, by retry success rates after a block, and by manual review of a sampled cohort. A working detection practice keeps the false-positive rate below 1%; a stricter posture (closer to 0.1%) is normal on wholesale trunks where blocked legitimate traffic is contractually painful.

The third is detection latency, the time between the start of a fraud event and the first SBC action against it. For events caught by a real-time scoring service in the call-setup window, this is the few hundred milliseconds of the query latency. For events caught by trailing-window analytics, it is whatever the post-call pipeline takes to produce a new block rule. The number worth tracking is the median latency across events, because tail events that took an hour to detect skew the mean and mask a working median.

The fourth is fraud loss per million minutes, the residual financial damage that escaped the first three KPIs. This is the only number that translates the detection practice into business terms. A detection practice that drops fraud loss from $50 per million minutes to $5 per million minutes is doing its job, regardless of what the block rate looks like.

The practice itself is a weekly loop. Review the CDR records from the past week for blocked, diverted, and alerted calls. Sample the alerts and confirm whether they were fraud or noise. Promote rules that earned their promotion, retire rules that no longer fire, and update partner block lists. The SBC is the substrate; the practice is the work that makes the substrate useful.

When Real-Time Isn’t Enough

Some fraud is invisible during the call-setup window. A sophisticated IRSF actor uses fresh number ranges that no block list has seen yet. A patient PBX-hacking campaign stays below every static threshold by design. A wholesale-arbitrage operator distributes traffic across multiple trunks to evade per-trunk velocity caps. In these cases, the call-setup window will let the fraud through; detection has to move to the other two windows.

The mid-call window catches fraud that becomes visible after the call connects. The classic signal is duration: an IRSF actor wants the call to stay up as long as possible to maximise the revenue share, so an outbound call to a borderline destination that crosses a duration threshold is worth a mid-call cut. The SBC can send a BYE on its own initiative when a routing-script-driven monitor fires, and ProSBC’s CDR stream and SIP message log expose enough signal for this to be wired up in production.

The post-call window catches everything else. Trailing-window aggregation across CDRs surfaces patterns that no single call can show: rotating A-numbers, destination concentration, ACD anomalies, source-reputation drift. The signal is then fed back into the call-setup pipeline as new block-list entries and new rule thresholds. A well-built fraud detection practice closes this loop within minutes for high-confidence patterns and within a day for everything else.

None of this replaces call-setup detection. It complements it. The call-setup window catches the fraud that is recognisable from a single call’s worth of information. The other two windows catch the fraud that requires aggregation across calls. An SBC that sits in the signalling path is the only network element that has visibility into all three.

Frequently Asked Questions