> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Voice Destination Auto-Blocks (Traffic Pumping & Wangiri)

> Understand the platform's automatic per-destination voice blocks: what patterns trigger them, how long they last, where to read them, and how they relate to Verify conversion anomaly and fraud-shield triage.

# Voice Destination Auto-Blocks

Outbound voice fraud rarely spreads evenly across a country or a
prefix — a real attack concentrates on **one specific number**. The
platform's detector sweep watches your call detail records (CDRs) for
two such patterns and applies a **reversible, self-expiring block** on
the exact destination involved, without touching any other number you
call. This page explains what an auto-block is, why it triggers, how
long it lasts, and where you can see it.

Nothing on this page makes Orbit a compliance regulator for your
traffic. Auto-blocks are a **protective posture control** — a baseline
against toll-fraud billing damage — and the numbers you own remain
your responsibility.

***

## What auto-blocks are

An auto-block is a per-destination record the platform writes against
your organization when its CDR sweep detects one of two fraud
patterns. Once written, the block is enforced on the outbound-dial
path: any new call to that exact number is rejected before dispatch,
while every other destination dials normally. The record carries a
`category`, a human-readable `reason`, an `applied_at` timestamp, and
an `expires_at` timestamp, after which the number dials again with no
revert action required.

The sweep that raises them, `scheduler-voice-destination-fraud-anomaly`,
reads your tenant's recent CDRs on a rolling window and applies the
block with the category and reason the pattern matched.

### Category: `traffic_pumping`

A large volume of outbound calls to **the same destination number** in
a short window — the signature of IRSF revenue-share pumping, where a
number is dialed repeatedly to rack up billable minutes. The broader
velocity layers (per-tenant and per-country call-rate caps) may never
trip on a sustained attack confined to one hot number inside an
otherwise-normal country: each call is individually within the floor,
but the pattern is not. The auto-block closes that gap at the exact
destination.

### Category: `wangiri_callback`

Wangiri ("one ring and cut") callback bait: an attacking source number
blasts brief, unanswered inbound calls across many of your DIDs,
hoping **you** call back. The fraud payoff is the outbound leg to
that source number — and that is the leg this control stops. When the
sweep correlates the one-ring inbound pattern with call-backs to the
same source, it auto-blocks that source number as a destination.

Both categories are applied **instantly** the moment the sweep runs —
there is no approval queue, and no wait for a human to notice a
velocity chart. Each detection tick also renews the block's expiry, so
a sustained campaign stays blocked continuously for as long as the
pattern persists.

***

## Reading the blocks

`GET /settings/compliance/voice-destination-blocks` returns the
currently-active (unexpired) auto-blocks for your organization,
most-recently-applied first, rootable under the API base
`https://api.orbit.devotel.io/api/v1/settings/compliance`.
Reads are open to any authenticated member of your organization.

### Response

```json theme={null}
{
  "blocks": [
    {
      "destination": "+121655501xx",
      "category": "traffic_pumping",
      "reason": "Burst of 47 outbound calls to one destination in 5 minutes",
      "applied_at": "2026-08-28T10:14:05.000Z",
      "expires_at": "2026-08-28T12:14:05.000Z"
    }
  ]
}
```

| Field         | Type     | Notes                                                                                           |
| ------------- | -------- | ----------------------------------------------------------------------------------------------- |
| `destination` | string   | E.164 destination number (traffic-pumping) or attacker source number (Wangiri) that is blocked. |
| `category`    | enum     | `traffic_pumping` or `wangiri_callback`.                                                        |
| `reason`      | string   | One-line description of the detection that triggered the block.                                 |
| `applied_at`  | ISO 8601 | When the sweep wrote (most recently renewed) the block.                                         |
| `expires_at`  | ISO 8601 | When the block auto-expires if the pattern stops; each new detection tick extends it.           |

If you have had no detections, the endpoint returns an empty `blocks`
array. There is no delete endpoint on the read surface — entries
clear themselves at expiry, and the same `COALESCE` write that adds a
record prunes every expired sibling out of the store, so the list can
never grow unbounded over a long campaign.

***

## Dashboard

**Settings → Compliance → Active voice destination auto-blocks** lists
the same active rows with destination, category, reason, and the
applied/expires timestamps. Use it when a teammate asks "why did your
call to X fail?" before you change any configuration — a live row here
answers it.

***

## Time-bound semantics

Auto-blocks are deliberately **time-bound**, never permanent:

1. **Lifetime per tick.** One detection tick writes a block whose TTL
   tops out at two hours (the clamp in `voice-destination-auto-block.ts`,
   floor 60 seconds).
2. **Renewal while the pattern persists.** The sweep re-applies on
   every tick the anomaly still shows in your CDRs, pushing `expires_at`
   forward each time — a sustained campaign stays blocked continuously.
3. **Natural release.** Once the burst stops, no job has to revert the
   block: it expires on its own inside the two-hour window, and the
   number dials again with no operator action. The expiry comparison
   runs against `Date.now()` on every outbound dial, so an expired
   record is treated as absent.

### What a legitimate caller experiences

While a block is active, an outbound call to that destination is
rejected **422** with the category reason — a hard reject, the same
response class as the curated premium-rate prefix blocklist that runs
on the outbound-dial path. The rejection fans out through the fraud-review
choke point, so it also appears in your operator Fraud reviews queue
and your webhook / in-app notification channels. That fail-closed
instant is the point: if the number is genuinely business-critical,
you see the block listed before the second attempt, and you can weigh
whether the destination deserves a workflow exemption (dial through a
case-by-case process) rather than a silent dial-through.

***

## Relationship to Verify conversion-anomaly export

The OTP/Verify stack has its own sibling detector for the same
attacker's playbook on the verify side:
`GET /api/v1/verify/conversion-anomaly` flags destinations whose OTP
completion rate is far below your tenant baseline (OTP-pumping /
artificial traffic inflation on the SMS channel), and
`GET /api/v1/verify/conversion-anomaly/evidence-export.csv` packages
that same evidence into an RFC-4180 export for a carrier chargeback
dispute.

Voice destination auto-blocks are the **outbound-voice half** of that
same visibility: instead of only reporting convert-rate suspects, the
voice sweep acts on the number the instant the pattern appears. If you
operate both SMS OTP and outbound voice, triage them together — a
number that appears in one surface is a worthwhile review target in
the other. See
[SMS pumping protection](/guides/sms-pumping-protection) for the
Verify-side walkthrough.

***

## Relationship to fraud-shield and compliance-health

Auto-blocks **fit inside** the triage surfaces you already use; they
do not replace them:

* **[Fraud Shield](/compliance/fraud-shield)** is the org-wide triage
  ledger. A blocked destination raises a fraud-review row there with
  the same acknowledge / dismiss workflow as any other category, and
  the chargeback evidence export covers the voice blocks alongside
  IRSF and Wangiri alerts.
* **[Compliance health](/compliance/compliance-health)** stays
  unaffected in either direction: auto-blocks are protective
  enforcement against billing damage, not a compliance-readiness
  signal, and neither the presence nor the absence of a block moves
  the posture score.
* **[Posture overview](/compliance/posture-overview)** lists the
  read-only `GET /settings/compliance/voice-destination-blocks`
  endpoint on its toggle map — the row the auto-block page expands.

***

## A tenant-owned posture note

Consistent with the platform's tenant-compliance stance, auto-blocks
are not a mandate, a quota, or a gate on your use of the network —
they are a protective posture control against toll-fraud and Wangiri
billing damage. The block never routes, reroutes, or redirects a call:
it only rejects the dial at the API boundary, and outbound voice still
exits exclusively through the Devotel softswitch. You own the
decisions about which numbers matter to you; the sweep owns the
detection lane so you do not have to read CDRs by hand.