Skip to main content

​
Fraud reputation: the shared cross-tenant network feed

Your tenant’s fraud defenses — the SMS-pumping scorer, the velocity windows, your outbound blocklist, Fraud Shield — all score a destination against your own history. That has a blind spot: an emerging SMS-pumping corridor that no single tenant has seen enough of to flag yet. Each tenant experiences a few sends to the corridor, sees nothing conclusive, and keeps paying carrier rates on the traffic — while the pattern is already obvious across the platform as a whole. The shared reputation feed closes that gap. Whenever any tenant’s Fraud Shield blocks or flags a send, that event also feeds one anonymized, platform-wide reputation counter per destination corridor (an E.164 prefix or an MCCMNC). Every tenant’s risk scorer then reads that aggregate back, so a corridor corroborated as fraudulent across tenants raises the score for all of them — including tenants whose own history is still empty. This is the same role Infobip Signals and Plivo Fraud Shield play on their networks; here it is built into the score you already receive. This page is about the messaging-fraud reputation feed. It is unrelated to the CAMARA network-signal APIs (SIM-swap, Scam Signal, QoD) covered in Network signals before you send — those query the mobile operator about a subscriber; this feed aggregates what the platform’s own tenants have already blocked.

​
What the feed records

Two counters per corridor, per day, over a rolling 7-day window:
  • A block count — how many Shield block/flag events the corridor accumulated that day.
  • A distinct-tenant count — how many different tenants contributed those events, tracked with HyperLogLog (a probabilistic cardinality estimator — the same sketch Redis provides — that counts distinct contributors without ever storing their identities).
Both counters are keyed by the corridor only, never by tenant. A corridor key is a destination aggregate, not a number:
  • An E.164 prefix — the first 5 digits of the destination (country code plus range), for example 1555 or 5370. This is the same 5-digit prefix the velocity windows already bucket on.
  • An MCCMNC (mobile country + network code) when the caller has already resolved one, for example 310260.
No full destination number, no tenant list, and no tenant identity is persisted anywhere in the feed — not even in an output a tenant can query. The distinct-tenant count exists only as hashed estimator state, so the aggregate cannot be enumerated back to any contributing tenant. The feed is anonymized by construction, not by convention.

​
The minimum-corroboration rule

A corridor earns a cross-tenant reputation influence only once it is corroborated across tenants:
  • At least 3 distinct tenants must have independently blocked the corridor (the fixed corroboration threshold), and
  • at least 5 block events must exist across the 7-day window.
Below that combination the feed contributes zero points to any score. The rule exists so that one noisy tenant — one aggressive Shield configuration over-blocking a legitimate corridor — cannot manufacture a platform-wide reputation. A signal only counts as a network signal when several tenants have produced it independently. Once corroborated, the corridor’s contribution scales linearly with block volume, from 5 blocks up to 50 (which earns the full weight), and is capped at 35 of the 100 points the SMS-pumping score can total. A corroborated corridor never condemns a destination on its own — it stacks with the per-tenant signals (prefix patterns, velocity, conversion, geo-spread, your blocklist) described in the SMS-pumping protection guide.

​
Where the feed is read

The pre-send SMS-pumping risk scorer reads the destination’s corridor reputation alongside the per-tenant signals, before the wallet is charged and before the send proceeds. When a send is scored — through POST /api/v1/messages/risk-signals, the composite POST /api/v1/risk/score, or a Fraud Shield evaluation — a corroborated corridor adds its points with a factor you can see in the breakdown:
The observed-signals block of the same scorer exposes the raw aggregate: network_corridor_blocks, network_corridor_distinct_tenants, and network_corridor_confirmed (whether the corroboration threshold was met). Because the scorer already feeds Fraud Shield’s allow/review/block decision, a corroborated corridor can push a borderline send over your review or block threshold even when your own history is silent — that is the point of the shared feed. If the reputation store is unreachable, the read fails open: the scorer degrades the network signal to a neutral zero rather than inventing risk — and rather than absolving a destination your own signals still flag. The feed is additive reputation only, never an enforcement gate on its own.

​
Where the feed is written

The write side is the send path itself. When your Fraud Shield blocks or flags an outbound SMS, the send path records one anonymized event against the destination’s corridor — fire-and-forget, after the decision. It never throws, never delays the send, and writes nothing tenant-scoped. You do not configure the feed. There is no setting, no subscription, and no endpoint to query it directly — it is on for every tenant whose Fraud Shield evaluates sends, and its only observable surface is the factor and observed-signals fields in the risk score you already get. The way you influence it is the way you influence the whole fraud posture: keep your Shield evaluating, and your blocks start protecting every other tenant on the platform within the rolling window, exactly as theirs protect you. For the per-tenant half of this posture — the factor weights, the bands, and the tenant-owned thresholds — see the SMS-pumping protection guide.

​
See also