Telecom & Communications
Call Fraud Detection API
Telephony fraud is quiet and fast. The traffic looks ordinary, the bill arrives weeks later, and by then the money has left the chain.
- Carriers and MVNOs
- CPaaS providers
- Contact centre platforms
- Enterprise telephony teams
- Revenue assurance teams
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Voice fraud takes a handful of well-established forms that keep working. Traffic pumping into high-cost destinations where the fraudster shares the termination revenue. Wangiri missed-call schemes that rely on people calling back premium numbers. Compromised PBX systems dialling internationally overnight. Subscription fraud on accounts opened to generate traffic and vanish. Each is visible in call detail records, usually within minutes, and frequently not noticed for weeks.
The reason is structural. Revenue assurance teams work from billing cycles and reconciliation reports, which is the right place to find leakage and the wrong place to find an attack in progress. By the time a monthly report shows an anomaly, the traffic has stopped and the interconnect invoice is due.
Detection from call records in near real time is a well-understood problem. Destination risk, velocity, duration distribution, answer-seizure patterns and account-level deviation all carry signal. The difficulty is operational: decisions must be fast enough to stop traffic, specific enough not to block a customer's legitimate international calling, and explainable enough to survive the dispute that follows every block.
Who buys this
Carriers and MVNOs, CPaaS providers, Contact centre platforms, Enterprise telephony teams, Revenue assurance teams
What the API returns
What comes back
- Call risk scores from destination, velocity, duration and account deviation
- Traffic pumping detection with the destination ranges driving it
- Wangiri and premium-rate callback pattern detection
- Compromised PBX indicators from out-of-hours and dialling-pattern changes
- Subscription fraud signals on newly created accounts
- Account-level baselines so unusual means unusual for that customer
- Automatic blocking recommendations with graduated alternatives
- Evidence records for every flag, suitable for interconnect dispute and customer explanation
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/cdr | Ingest call detail records in near real time |
| POST | /v1/calls/score | Score a call setup request before completion |
| GET | /v1/accounts/{id}/risk | Risk profile and baseline for one account |
| GET | /v1/alerts | Open fraud alerts with evidence |
| GET | /v1/destinations/risk | Destination range risk scores |
| POST | /v1/outcome | Report confirmed fraud or a false positive |
Request and response
illustrativeRequest
{
"account_id": "acct_pbx_7714",
"window_minutes": 30,
"detectors": ["traffic_pumping", "pbx_compromise", "wangiri", "velocity"],
"include_evidence": true
}Response
{
"account_id": "acct_pbx_7714",
"evaluated_at": "2026-10-22T02:41:12Z",
"risk_score": 92,
"band": "critical",
"recommendation": "block_high_cost_destinations",
"detections": [
{
"detector": "pbx_compromise",
"confidence": 0.94,
"evidence": "214 international calls between 01:10 and 02:40; account has made 3 international calls in the prior 90 days",
"destinations": ["+252 7xx", "+371 2xx", "+676 7xx"],
"estimated_exposure": { "value": 4120.00, "currency": "EUR" }
},
{
"detector": "traffic_pumping",
"confidence": 0.71,
"evidence": "88% of traffic to 4 adjacent high-cost ranges; mean duration 182s with low variance"
}
],
"graduated_options": [
{ "action": "block_destination_ranges", "impact": "Stops 97% of exposure" },
{ "action": "rate_limit_international", "impact": "Preserves domestic service" },
{ "action": "notify_customer_and_hold", "impact": "No service impact, slower" }
],
"false_positive_check": "Account is a dental practice; no prior international pattern",
"audit_reference": "cfd_2026102202411200714"
}Where the data comes from
| Call detail records | Your own CDRs, ideally streamed rather than batched — everything in this build depends on how fresh they are |
| Interconnect rate data | Termination costs by destination range, which is what turns a call pattern into a financial exposure figure |
| Numbering and destination reference data | Range allocations and known high-cost and premium-rate ranges |
| Account and provisioning data | Customer type, service configuration and expected calling profile, used to build meaningful baselines |
| Confirmed fraud outcomes | Your own case history, including disputes you lost — the only honest way to calibrate thresholds |
| Industry fraud indicators | Shared destination and pattern intelligence where you participate in a scheme that permits its use |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Account-level baselines rather than population thresholds, because a freight firm calling West Africa nightly is normal and a dental practice doing so is not
- Destination risk scored from termination cost, historical fraud association and traffic structure together
- Duration distribution analysis, since pumped traffic shows characteristically low variance around a profitable call length
- Velocity detection across multiple windows simultaneously, as attacks run in bursts of very different lengths
- Exposure estimation in currency, which is what actually determines whether blocking now is the right call
- Graduated response options rather than a single block decision, because the cost of cutting off a legitimate customer is real
- Threshold calibration against your confirmed outcomes and your false-positive history, with both tracked as standing metrics
- Latency instrumentation on the detection path, because detection that arrives after the traffic stops has no value
What it changes for the business
Exposure containment
Attacks caught in minutes rather than at the next billing cycle, which is where almost all of the loss sits.
Fewer wrongful blocks
Account-level baselines mean a customer with genuine international traffic is not cut off for using their service.
Dispute evidence
Per-flag evidence records support interconnect disputes and customer conversations with something concrete.
Revenue assurance focus
Automated detection frees the team for the structural leakage that genuinely needs human analysis.
How it fits into your product
How it embeds
- CDR ingestion by stream, with batch supported where streaming is not yet available — freshness directly determines value
- Optional pre-completion scoring at call setup where your switch can consult an external decision point
- Alerts into your existing network operations and revenue assurance tooling
- Graduated action hooks so your policy decides between block, rate limit, hold and notify
- Deployment inside your own infrastructure, which is effectively mandatory for CDR data at carrier volumes
- Outcome reporting so confirmed fraud and false positives both feed calibration
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can it block calls automatically?
It can recommend and trigger graduated actions, and for high-confidence PBX compromise overnight that is usually the right design. But blocking a customer's traffic has a real cost, including to customers with legitimate international calling. We would build the hooks, set conservative automatic thresholds with your revenue assurance team, and keep the harder cases routed to a human.
How fast does detection need to be?
Minutes, not hours. A compromised PBX can generate several thousand euros of exposure overnight. That makes CDR freshness the binding constraint — if your records arrive in hourly batches, the best detector in the world is an hour late. Moving to streaming is often the highest-value change in the whole project.
What is the false-positive risk?
Genuine and it needs managing explicitly. Businesses legitimately change their calling patterns: a new export client, a seasonal campaign, an acquisition. Account-level baselines reduce it substantially but do not eliminate it, which is why the response includes a false-positive check and graduated options rather than a single block flag.
Can you detect fraud in traffic we do not carry?
No. This works on your own call records. Fraud occurring elsewhere in the interconnect chain is invisible to you and to us, and claiming otherwise would be dishonest. Shared industry intelligence helps with destination risk, but only where you participate in a scheme whose terms permit using that data.
Does this handle caller ID spoofing and robocalls?
Partially. Pattern-based detection catches high-volume automated calling. Verifying that a calling number is genuinely authorised is a separate problem handled by attestation frameworks that differ by country and require participation in a signing regime. We would scope that explicitly rather than imply the pattern detector solves it.
Related blueprints
Phone Number Intelligence API
Validity, line type, carrier and permitted portability data for phone numbers, returned as a lookup your signup and messaging flows can call.
Contact Centre Speech Analytics API
Transcription, topic detection, quality scoring and compliance flagging for recorded or live contact centre calls.
SMS Delivery Optimisation API
Route quality analytics, delivery prediction and fallback recommendations for platforms sending high volumes of messaging traffic.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.