Who Is Really Calling? Caller ID, Spoofing and Verifiable Fraud Signals

BEREC describes Calling Line Identification spoofing as manipulation of CLI information so that the call appears to originate from another, often trusted, number.4

Latvia's Numbering Fraud Prevention Rules similarly treat full or partial alteration of the calling number as a fraud indicator, subject to the specific exception defined in the rules.2

This is an important technical distinction.

The number displayed on screen is a calling-line identification value.

The user tends to interpret it as the identity of the organisation or person.

Those are not the same thing.

A voice call can contain several distinct identity layers:

• the displayed number;
• the numbering resource and its allocation;
• the operator currently serving the number;
• the actual origin and routing path of the call;
• the subscriber or organisation controlling the identifier;
• the person or system that initiated the specific call;
• the organisation's policy for how that number is allowed to be used.

Knowing one layer does not automatically establish the others.

The last row is where trust interfaces become dangerous.

Identity verification can remove one fraud path without removing fraud.

A legitimate organisation's account can be compromised. An insider can abuse a system. A contact-centre configuration can be wrong. A fraudster can move the attack to SMS or a phishing domain. A genuine bank employee can call from a legitimate channel while the customer should still never disclose authentication secrets.

verified must not become a synonym for safe.

Section 66 of Latvia's Electronic Communications Law defines the Numbering Database as a state information system containing information on numbering rights, numbering use, number-portability outcomes and other defined data.1

SIA “Elektroniskie sakari” also publishes numbering-allocation information through Latvia's Open Data Portal; the Q2 2026 dataset is published on a quarterly cycle.5

That is useful evidence when the question is:

Has this numbering resource been allocated, and to whom?

It does not, on its own, answer:

Did the call reaching me a moment ago originate from the organisation I associate with that number?

That requires another evidence layer.

In its 28 August 2026 reply to my inquiry, SIA “Elektroniskie sakari” said that public Numbering Database information was available through its website and the Open Data Portal, while the machine-readable exchange/API access I had proposed was not planned.8

That response illustrates a useful design principle:

before building another identity API, define precisely what the underlying source can authoritatively assert.

It would also be inaccurate to describe the Latvian problem as though no technical controls were operating.

In a 4 September 2026 reply, Latvia's Public Utilities Commission (SPRK) told me that mobile electronic-communications providers had already developed and deployed a common technical solution for numbering-fraud prevention that checks the compliant use of public mobile-network numbers. The regulator said that several million fraudulent or non-compliant call attempts had already been blocked.9

The reply does not publicly document the full architecture, all fields or signals used, or the access model outside participating operators.

Those details should not be invented.

The important point is that a real operator-level control already exists.

A sensible next question is therefore not:

How do we build another duplicate anti-spoofing system?

It is:

Which minimal, trustworthy conclusions from existing controls could safely support other anti-fraud functions, where law and architecture permit it?

Latvia added a particularly concrete signal in 2026.

Article 98(8¹) of the Electronic Communications Law, effective from 2 April 2026, requires an electronic-communications provider receiving a call in interconnection from a foreign operator to process terminal-location information for the prevention of fraud or other unlawful activity, including information about whether the terminal is roaming.1

That can support an inconsistency test.

For example:

• a call arrives through foreign interconnection;
• the CLI presents a Latvian mobile number;
• network context indicates that the associated terminal is not roaming.

That inconsistency can be much stronger fraud evidence than the fact that the number exists in a database.

It still does not identify the human caller.

The signal addresses a narrower question:

Is the technical origin context of this call consistent with the identifier being presented?

If I were designing a status for another system or for an end-user interface, I would avoid:

It hides too much.

A more defensible model keeps three dimensions separate.

1. Identifier control

What is known about the number or other identifier?

For example:

• the number is allocated;
• an organisation has demonstrated control of it;
• that control assertion is valid until a defined date;
• control has been revoked or requires renewal.

2. Origin consistency for this communication

What do network or channel signals say about the particular call or message?

For example:

• origin path is consistent;
• routing/roaming context conflicts with the displayed identifier;
• evidence is unavailable;
• authentication does not survive the complete communications path.

3. Fraud risk

Are there independent signals about the communication or campaign itself?

For example:

• known fraud campaign;
• malicious domain in the message;
• corroborated user reports;
• payment-recipient risk where a lawful sector-specific mechanism exists;
• anomaly requiring further review.

These dimensions should not collapse into one truth bit.

Caller identity cannot always be verified end to end. A forwarding arrangement, unsupported originating network, recent porting event or missing authentication signal may leave the system without enough evidence.

The safe interpretation is not SAFE and not FRAUD; it is unknown for this specific claim. The API-level distinction between unknown, unsupported, stale and temporarily unavailable evidence is defined in Anti-Fraud Network APIs in Europe. BEREC's review of European anti-spoofing measures also shows why no single mechanism currently covers every communications path.4

An SMS application may show a name rather than a number:

BANK

TAX AUTHORITY

POLICE

To the user, that text looks like identity.

Technically, it is an alphanumeric sender ID.

Latvia's Ministry of Transport included possible registration of alphanumeric sender identifiers among the anti-fraud measures discussed by the sector in January 2026.3

BEREC's 2025 report also describes SMS sender-ID registries as one regulatory model: identifiers are registered and operators can block messages using unregistered sender IDs.4

That can be a valuable anti-impersonation control.

It still does not mean:

registered sender ID = safe message.

A legitimate messaging account can be compromised.

A genuine channel can distribute a malicious or incorrect link.

A payment request can still be fraudulent for reasons unrelated to sender-ID spoofing.

Identity control removes one attack technique. It does not validate the entire transaction.

STIR/SHAKEN is often presented as the technical answer to caller-ID spoofing.

BEREC describes it as a mechanism in which providers authenticate and digitally sign caller-identity information.4

That is meaningful.

There are still several boundaries.

First, BEREC notes the need for effective cross-jurisdictional deployment.

Second, it is tied to all-IP communications; transitions between different technologies can break or reduce authentication continuity.

Third, even perfect caller-ID authentication does not answer:

Is this organisation behaving legitimately in this interaction?

The user interface should therefore avoid translating a technical attestation into an unconditional “trusted call”.

Suppose a bank can demonstrate that:

• it controls a particular number;
• it uses the number for customer service;
• another published number is never used for outgoing calls;
• a particular SMS sender ID is authorised;
• links in legitimate messages use only defined domains.

That information is useful.

But it contains several claim types.

“The organisation controls this number” is an identifier-control assertion.

“This number is never used for outbound calls” is channel policy.

“This call arrived through an origin path consistent with the organisation's authorised use” is event-level technical evidence.

“This call is safe” is a broader conclusion.

A trustworthy system should not hide those differences.

Sometimes the most useful assertion is negative:

This number is never used to originate calls.

BEREC describes do-not-originate registries as lists of numbers that should never appear as the calling party; calls presenting those numbers can therefore be blocked.4

This is attractive because it does not have to solve the entire philosophical question of caller identity.

It tests a narrow and verifiable policy:

Does this event violate a declared rule for the identifier?

Narrow assertions are often more operationally useful than large composite trust scores.

Any caller-identity or fraud status shared between systems still needs enough context to be interpreted safely: who issued it, what exact claim type it represents, when it was observed, how long it remains valid, and how it can be corrected or revoked.

The full interoperability profile — provenance fields, freshness, UNKNOWN, aggregation and conformance behaviour — belongs to Anti-Fraud Network APIs in Europe. The point needed here is narrower: a registry fact, network observation, organisation assertion, user report, model score and competent-authority decision are different evidence classes. A caller-trust interface should not flatten them into one universal authority score.

A caller-facing status can inform a decision without itself creating legal authority.

Latvian law already contains situations where a provider has a statutory duty to stop routing in cases of detected numbering fraud.1 That legal effect must not be confused with a private risk score, network observation or organisation assertion. My 2026 proposal therefore kept risk signals, assessments, architecture-level “authoritative status” and binding decisions conceptually separate.6

The API-side version of this boundary is treated in Anti-Fraud Network APIs in Europe.

A sophisticated backend can still create a dangerous front end.

Consider the badge:

✓ VERIFIED

What is the user expected to infer?

• the number exists?
• the organisation controls it?
• the call origin was authenticated?
• the call is not fraudulent?
• it is safe to disclose a banking authentication code?

If the product cannot answer that, the badge is itself a social-engineering surface.

Safer interface language is narrower:

Organisation control of this number has been verified

Network-origin check passed

Origin could not be fully verified

Call context conflicts with the displayed number

Fraud-risk signal detected

None of the positive states should say:

Safe to trust

In BEREC's 2025 workshop, the Latvian regulator also described a likely shift of fraud toward OTT and messaging platforms as traditional telephony controls improve.4

That is predictable.

When voice spoofing becomes harder, attackers can use:

• messaging apps;
• social-media profiles;
• SMS sender IDs;
• phishing domains;
• advertising;
• email;
• counterfeit mobile applications.

This is why the term communication identity in my 2026 proposal was intentionally broader than telephone numbering.6

It does not justify a central database of everything.

A healthier architecture is federated: each competent source answers only the question it can factually and legally support.

On 24 August 2026 I proposed a limited 90-day feasibility study on interoperability of anti-fraud signals and communication identities.6

The initial scope covered:

• numbering fraud;
• CLI spoofing;
• SMS sender IDs;
• roaming/location signals for inbound international calls;
• standardised network interfaces.

The boundary was as important as the proposal itself: a feasibility study would not create new powers to block communications, obtain protected data or otherwise affect individual rights.

After replies from SIA “Elektroniskie sakari” and SPRK, I clarified the proposal on 8 September: existing registries and operator mechanisms should be reused before any new infrastructure is created, and shared layers should preferably expose minimal, traceable status or signals rather than copy sensitive source data.7

The Ministry's 4 September reply described the proposal as a possible cross-sector cooperation/interoperability approach and invited me to present the communication-identity, fraud-signal and interoperability ideas at the sector meeting scheduled for 23 September.10

As of 25 September 2026, I did not find a public Ministry summary of the meeting outcome. This article therefore does not claim that the proposed architecture has been adopted or implemented.

A pilot does not need to begin with real bank customers or fraud victims.

A synthetic scenario is enough.

Suppose:

1. a synthetic bank controls a declared number;
2. another number is declared inbound-only;
3. a test call arrives from a foreign interconnection while presenting the inbound-only CLI;
4. roaming context is inconsistent;
5. an SMS uses an authorised sender ID but includes a synthetic domain marked malicious in a test threat feed;
6. no component automatically creates a legally binding decision beyond its authority.

The test can then measure:

• signal freshness;
• provenance;
• preservation of UNKNOWN;
• false-positive correction;
• separation between identity and fraud evidence;
• auditability of the warning shown to the user.

That is already a useful interoperability test.

It does not require a “national AI fraudster database”.

A phone number on screen is not an identity document.

A numbering registry can establish one fact.

A telecom operator can observe another.

An organisation can attest control of its own channel.

Call authentication can provide evidence about origin consistency.

A fraud-detection system can add risk evidence.

None should be renamed into a universal truth claim.

A better communication-trust architecture keeps separate:

who controls the identifier;

what is known about the origin of this particular communication;

what fraud signals exist;

and who is legally authorised to take the resulting action.

That precision is what can make verified a security feature rather than another tool for social engineering.

Legal and institutional status was checked on 25 September 2026. “Communication identity”, “authoritative source/status”, the three-dimension model and the proposed assertion fields are the author's architecture working concepts, not statutory categories in Latvian electronic-communications law. No public Ministry of Transport outcome summary for the 23 September meeting was located at the time of checking; the author's proposal is not presented as adopted government policy.

This article analyses electronic-communications security, anti-fraud architecture and regulatory context. It is not individual legal advice.