Anti-Fraud Network APIs in Europe: Why Common Syntax Is Not Enough

An anti-fraud network API should be thought of as a narrow interface to a network capability or network-derived fact.

It is not necessarily a repository of fraudsters, suspicious phone numbers or cross-sector behavioural histories.

Existing Open Gateway/CAMARA capabilities already demonstrate the narrower model. The SIM Swap API lets an authorised consumer query the timing of a SIM change or whether one occurred within a defined period. Number Verification can check whether the number presented by an application corresponds to the mobile number associated with the device in the network context.23

The application does not need the operator’s entire internal dataset. It needs a bounded answer to a bounded question.

That principle is worth preserving as anti-fraud use cases expand.

Fraud systems routinely combine evidence that has very different epistemic and legal status.

This distinction should survive the API chain.

If a downstream service receives a network observation and converts it into fraud=true, it has added a conclusion that the source did not make. That may be a legitimate internal decision, but it should not be confused with the meaning of the upstream evidence.

A portable anti-fraud profile therefore needs to preserve the class of assertion, not only its value.

I use the word assertion here as an architectural term: a bounded statement by an identified source about a specific fact or assessment. It is not a new legal category.

BEREC’s 2026 Call specifically asked to what extent current network APIs are truly interoperable across operators and network vendors.1

That question cannot be answered by checking whether two implementations use CAMARA-compatible payloads.

A sandbox can make the first layers look excellent.

Fraud-prevention failures often happen lower in the table.

Suppose an API checks whether the presented calling identity is consistent with available origin context.

A useful result space might distinguish:

CONSISTENT

INCONSISTENT

NOT_AVAILABLE

The third state is not a negative finding. It says that the system cannot establish the answer.

That distinction is easy to lose in integration code. A boolean interface encourages developers to map unavailable evidence to false, which can silently turn “we could not check” into “no problem was found”.

Anti-fraud systems should keep separate states for:

• negative evidence;
• unknown evidence;
• unsupported capability;
• temporary unavailability;
• authorisation failure;
• stale evidence.

These are not implementation details. They change the decision that can safely be made downstream.

A fraud signal may travel through several organisations before it reaches an application.

The operator may observe the underlying fact. An aggregator may perform routing and contracting. A cloud or CPaaS provider may expose the API to a developer. A bank or platform may combine the result with its own evidence.

At the end of that chain, RISK is not enough.

The consumer may need to know:

• who originally issued the result;
• what class of source produced it;
• when the underlying observation occurred;
• which policy, ruleset or model version applied;
• how long the result is considered fresh;
• whether the result has been superseded or revoked.

This is the provenance and freshness layer.

It is particularly important in aggregated markets because the organisation answering the HTTP request may not be the organisation that controls or directly observes the underlying network fact.

Aggregators are valuable. They can reduce operator-by-operator discovery, routing, commercial contracting and integration work.

They should not become the apparent origin of every fact they relay.

If the MNO directly observes a SIM change, the MNO remains the source of that network fact even when an aggregator delivers the answer. If a national registry supplies a numbering-policy state, the registry remains the source even when a CPaaS platform exposes the result.

A portable profile should therefore preserve issuer and source class separately from the commercial or technical channel used to deliver the response.

Without that distinction, auditability and correction become unnecessarily difficult.

Some fraud signals age rapidly.

A recent SIM swap matters because it is recent. Roaming and call-origin context can change between events. A sender-ID authorisation or protected-number policy can be updated. A false-positive classification can be corrected.

An anti-fraud API therefore needs a way to communicate observation time and, where relevant, expiry or freshness.

If results are cached, relayed or federated, correction becomes equally important:

when the source changes or revokes an earlier result, how quickly does that change reach consumers that may still be acting on the old one?

A standard API without a standard correction model can propagate stale mistakes very efficiently.

A single number is easy to integrate.

risk=82

Apply a threshold and continue.

The difficulty is that two services can reach 82 from completely different evidence. One may use SIM-swap recency, another call-origin inconsistency, another behavioural telemetry, another a proprietary blacklist. A model update can also change the meaning of the score without changing the API schema.

For this reason, my August 2026 public contribution to BEREC proposed prioritising portable reason codes and an evidence class over a single opaque cross-provider fraud score.4

Services can still calculate risk. The interoperability layer should make it possible to understand what kind of evidence contributed to the assessment.

Operators may need access to protected traffic, signalling, location or related network data in order to answer a fraud question.

That does not mean a third-party application needs those underlying records.

Article 6 of the ePrivacy Directive establishes a specific regime for traffic data. Article 6(5) includes fraud detection among the functions performed by persons acting under the authority of communications providers, within the limits of Article 6; it does not create a general cross-sector entitlement to receive raw traffic data.5 Where personal data are processed, GDPR purpose limitation, data minimisation and a lawful basis remain relevant.6

A useful architectural default is therefore what I called local resolve in the BEREC contribution:

1. the authoritative or directly observing source evaluates protected context internally;
2. it answers a predefined, purpose-specific question;
3. the external consumer receives only the minimum assertion and provenance necessary for the authorised use.

A fraud-prevention service may need to know that a presented calling identity is inconsistent with origin context. It does not necessarily need the location or signalling records from which that answer was derived.

Local resolve is a design proposal, not a term imposed by EU law.

The legal-effect boundary should be explicit in the data model.

Article 97(2) of the European Electronic Communications Code requires Member States to ensure that national regulatory or other competent authorities can require providers, on a case-by-case basis, to block access to numbers or services where justified by fraud or misuse.7

That is a statutory authority mechanism.

An API result such as INCONSISTENT, RISK_SIGNAL or HIGH_RISK is different. It is evidence or an assessment that a downstream organisation may use within its lawful decision process.

The two should never become indistinguishable merely because both can eventually result in a blocked transaction or communication.

The same principle applies to automated controls. Automation may be lawful and appropriate in a specific context, but the authority for the action comes from the relevant law, contract and governance model — not from the existence of an API field.

Fraud-prevention architecture often focuses on detection.

Correction receives less attention.

Suppose an operator corrects an erroneous status, but an aggregator retains the old response in cache. Or a registry changes a protected-number policy but downstream systems continue to act on the previous state. Or a customer wins a complaint, but there is no standard way to propagate the corrected status.

The ecosystem is then semantically inconsistent even if every endpoint remains available.

A serious profile should therefore support:

• supersession or revocation;
• correction timestamps;
• traceable source identity;
• service-specific correction propagation targets;
• redress paths where false positives materially affect users.

This becomes more important as telecom signals are reused by banks, platforms, CPaaS providers and other sectors.

BEREC’s 2026 Call treats GSMA Open Gateway and CAMARA as central to the developing network API ecosystem.1

An anti-fraud interoperability profile should build on that work rather than create another transport and authentication stack.

Existing capabilities such as SIM Swap and Number Verification should be reused where they answer the question.23

The additional work is mostly about composing and extending meaning across fraud use cases. Examples proposed in my BEREC contribution included:

• calling-line/origin consistency;
• protected-number or do-not-originate policy status;
• alphanumeric SMS sender-ID authorisation status;
• roaming/origin consistency;
• freshness, correction and revocation;
• advisory fraud assessment with reason codes and evidence class.

Those items were explicitly presented as proposals, not as claims that CAMARA had already standardised every capability.4

That distinction matters. Standardisation work should begin from the actual capability catalogue, not from a policy paper pretending proposed enums already exist in production.

Latvia illustrates why an interoperability project should start with capability mapping rather than a new-system assumption.

BEREC’s 2025 report on number misuse recorded that the Latvian regulator, SPRK, was considering a decentralised anti-fraud API focused on call-origin legitimacy. The report also said Latvia was trialling an approach used in Lithuania and Estonia, saw cross-border potential, and expected cooperation beyond telecoms to become increasingly relevant as fraud shifts toward messaging and OTT channels.8

In August 2026 I separately submitted proposals to SPRK, the Latvian Ministry of Transport and SIA “Elektroniskie sakari”, asking them to assess communication-identity and fraud-signal interoperability.9

The replies narrowed the problem in useful ways.

SPRK stated on 4 September that Latvian mobile providers had already developed and deployed a common technical solution for numbering-fraud prevention that checks the appropriate use of public mobile-network numbers, and that several million fraudulent or non-compliant call attempts had already been blocked using that solution.10

SIA “Elektroniskie sakari” separately said that public Numbering Database information was available through its website and Latvia’s open-data portal, but that the dedicated machine-readable exchange or API access proposed in my submission was not planned.11

These facts do not establish a need for another Latvian anti-fraud API.

They establish the opposite starting point: map what already exists, identify its boundaries and only then decide whether an interoperability gap remains.

The Ministry of Transport subsequently invited me to present the broader communication-identity, fraud-signal and interoperability proposal at its 23 September sector meeting.12 An invitation to discuss a proposal should not be described as policy adoption.

Latvia’s Electronic Communications Law already contains a legal framework for numbering fraud, including regulator/operator information flows and obligations relating to call routing and access where numbering fraud or misuse is detected. The law also establishes the Numbering Database as a state information system.13

Those rules do not create a developer-facing anti-fraud API.

They do show that anti-fraud interoperability would have to connect to an existing legal and institutional architecture rather than invent a parallel one.

That is exactly why the API layer should expose narrowly scoped facts and assessments while preserving the authority of the actors that already hold statutory powers.

A useful first profile does not need to define a giant European fraud ontology.

It can start with seven things.

Signal class. Network fact, registry/policy fact, advisory assessment or another clearly defined category.

Status semantics. Positive, negative, unknown and unavailable remain different.

Provenance. Issuer, source class and, where relevant, intermediary.

Time. Observation time, freshness/expiry and correction/revocation state.

Reason code. Why the result was produced, without exporting more protected data than necessary.

Version. Which ruleset, policy or model version applies.

Legal-effect class. Technical evidence cannot look like a statutory blocking or enforcement order.

That is enough to make multi-provider integration substantially safer without dictating one national anti-fraud architecture.

A schema validator is necessary and insufficient.

A cross-border or multi-operator pilot should run the same synthetic cases against multiple providers and test whether:

• the same case produces semantically equivalent results;
• UNKNOWN never silently becomes “safe”;
• source and observation time survive aggregation;
• corrected or revoked assertions propagate within a defined window;
• changing aggregator does not require rewriting the core fraud-decision semantics;
• raw traffic or location data are not exposed where a minimised assertion is sufficient;
• advisory output cannot be mistaken for a statutory blocking order;
• audit evidence can reconstruct issuer, ruleset/version, observation time and decision path.

Those tests reveal interoperability failures that an OpenAPI linter cannot see.

BEREC should not become a European fraud database, a police function or a cross-sector enforcement operator.

Its relevance is in the layer between national regulators and a cross-border API market: interoperability, portability, transparent market access, operator/aggregator roles and the consistency of network capabilities.

BEREC’s 2026 Call explicitly asked about ecosystem roles, market adoption, technical and regulatory challenges and actual interoperability.1 My anti-fraud interoperability profile was published by BEREC as one of the public contributions received on 23 August.4

BEREC’s 2026 Work Programme scheduled a summary report from this work item for later in 2026.14 As of the 25 September status check for this article, the public consultation register contains the stakeholder contributions, but the planned final summary report for this work item has not yet been published.15

It is therefore accurate at this stage to describe anti-fraud API interoperability as a stakeholder proposal within an active BEREC workstream, not as an adopted BEREC policy.

Common syntax is necessary for European network APIs.

For fraud prevention, it is only the first layer.

Real interoperability begins when operators, aggregators and applications can preserve the answer to six harder questions:

What does the signal mean? Who issued it? When was it true? What does an unknown result mean? How is an error corrected? What legal effect does the result not have?

Without those answers, standardised APIs can carry inconsistent evidence very efficiently.

Europe does not need a central raw-data fraud repository in order to improve this layer. It needs a sufficiently precise shared language so that existing network, registry and risk signals can travel across providers and borders without losing their meaning.

Public and legal sources were checked on 25 September 2026. The proposed assertion semantics in this article are the author’s interoperability design, not an adopted BEREC, CAMARA or GSMA standard unless explicitly identified as such.

This article analyses technical, regulatory and interoperability architecture. It is not individual legal advice.