Fraud Shield — Tenant Triage & Chargeback Evidence
Orbit’s detectors continuously screen your account for fraud and abuse signals — SIM-swap, IRSF / toll-fraud, SMS pumping / artificial traffic inflation (AIT), Wangiri one-ring callbacks, spend-velocity anomalies, API-key geo-anomalies, voice-deepfake scores, and suspicious campaign send velocity. Until recently only Orbit’s operators could see those alerts. Fraud Shield puts the same ledger in your hands: you can list the alerts raised against your own account, triage each one (acknowledge or dismiss), set which severities and categories count as actionable in your view, and export a CSV evidence pack suitable for a carrier chargeback dispute. All endpoints below are rooted athttps://api.orbit.devotel.io/api/v1/compliance/fraud-reviews. Reads
are open to any authenticated member of your organization; writes
(acknowledge, dismiss, and settings changes) are restricted to owners
and admins.
Categories and severities
Categories detected by the platform:
Severities are
low, medium, high, and critical, ranked in that
order. Review statuses are open (unattended), triaged
(acknowledged), dismissed (closed by you as a false positive or
accepted risk), and escalated (closed by Orbit’s operators).
List and inspect alerts
GET /compliance/fraud-reviews returns your organization’s alerts,
sorted critical-first and newest-first. Each row carries an
actionable flag derived from your configured thresholds (see below).
Any PII in the alert details is scrubbed on the way out.
Query parameters:
GET /compliance/fraud-reviews/:id returns one alert. Because every
read is scoped to your organization, an id that belongs to another
organization returns 404 — you never see cross-tenant data, and a
guessable id leaks nothing.
Triage: acknowledge and dismiss
Acknowledging an alert means “we have seen this and are investigating.” Dismissing it means “reviewed and closed as a false positive or an accepted risk.” Both are owner/admin-only and recorded in your audit log.- Acknowledging an already-triaged alert is a no-op (idempotent).
- Dismissing an already-dismissed alert is a no-op.
- A
dismissedorescalatedalert cannot be acknowledged; anescalatedalert cannot be dismissed either way — you get a 409 explaining why.
Triage thresholds shape your view — never the alert webhook
GET and PUT /compliance/fraud-reviews/settings read and update two
fields:
actionable in your list
and on the dashboard — they do not silence the
account.fraud.alert webhook or the in-app notification. That fan-out
stays always-on so an attacker draining your wallet can never mute the
warning. critical alerts are always actionable regardless of your
notify_min_severity floor. The webhook catalog entry is documented in
the webhooks events reference.
Chargeback evidence pack (CSV)
When a vendor bills you for SMS pumping / AIT or Wangiri / toll-fraud traffic, disputing the charge takes evidence. Export the blocks Orbit raised on your account as an RFC-4180 CSV that a carrier can consume:window_days is the look-back window (1–90, default 30). The file
includes one row per eligible block — SMS pumping / AIT over messaging
and Wangiri / toll-fraud over voice — with a stable set of columns
(review_id, detected_at, source, category, severity,
status, phone_prefix, channel, rule, block_category,
risk_score, summary, report_generated_at). If no eligible blocks
exist over the window, you get a header-only file. Every export is
written to your audit log with the window and eligible row count, so
the export itself is part of the evidence trail. Verify (OTP) traffic
has its own dedicated export —
GET /verify/conversion-anomaly/evidence-export.csv.