Network API business, fraud and digital identity teams

Tell a bank whether the SIM changed, with the customer's consent recorded

A bank's app is about to move money. Before it does, it asks the network whether the number's SIM was changed in the last day.

Request a working session The product that runs it: CAMARA & GSMA Open Gateway APIs

Read the journey; a working session shows it running.

Seen by the customer · API

From the record, not a run: what would reach them, on API.

The case

Annotated from the record

What happened

A bank's app is about to move money, and asks the network whether the number's SIM was changed in the last day.

A bank's app is about to move money. Before it does, it asks the network whether the number's SIM was changed in the last day.

What it reads

The API's launch state in this network
Token scope and the consent record
The identifier presented and the SIM-change record
Rate limits and territory policy

Checks before anything is sent

API launched in the network, token scope, consent, supported identifier, rate limit and territory checks pass.

Every option considered, including doing nothing

Return the last SIM-change signal for the authorised numberConsidered
Request consent, where none is held for this purposeConsidered
Rate-limit or route to an alternate operatorConsidered
No answer, where the token, the identifier or the territory does not permit itConsidered

Doing nothing is one of the outcomes, and it is recorded with its reason. The options are the record's own; a run decides between them.

Evidence record

Preview

Reference: The reference of the saved run.
Decision: One of the options, including no action, with the reason.
Checks: API launched in the network, token scope, consent, supported identifier, rate limit and territory checks pass.
Evidence kept: Request
response trace
token scope
consent record
conformance result
meter record
settlement
The measures: Calls answered within the agreed latency, and the fraud the bank reports stopped, against calls refused.
Connection: Written on every record: the systems the run read, and the sample it ran on.

The shape of the record, with no values. A reference appears only after a run is saved.

The improvement, and how it is measured

Hypothesis

A bank that can ask the network answers a fraud in seconds; one that cannot finds out after the money has moved.

Modelled

The mechanism that could produce the result, stated; the figure is measured in the pilot.

Observed

Measured in a pilot’s validate stage, on your systems, against a comparison agreed first.

The result, the mechanism, the measurement, and the record’s five answers

Desired result

API revenue; faster enterprise integration; reduced fraud/friction; improved application experience

Mechanism

Onboard app → issue credentials → receive request → authenticate/consent → call capability → return → meter → monitor → invoice/settle → support

Measurement

Developer funnel cohort; sandbox-to-production conversion; usage/revenue ledger; API-specific success and latency SLO; partner holdout where applicable

Measured on: Active developers; time to first call; success rate; p95 latency; API calls; paying applications; revenue; margin; fraud loss; SLA compliance

01
Desired result
The result wanted.
API revenue; faster enterprise integration; reduced fraud/friction; improved application experience
02
Mechanism
The mechanism that could produce it.
Onboard app → issue credentials → receive request → authenticate/consent → call capability → return → meter → monitor → invoice/settle → support
03
Evidence required
The records kept to show it.
Request/response trace; token scope; consent record; conformance result; meter record; invoice/settlement; SLA report
04
Costs and risks
The cost, and the ways it can go wrong.
Costs: Per-call; tiered subscription; revenue share; enterprise contract; minimum commitment; paid SLA; setup/integration fee
If it fails: Return standard error; never expose raw network data; idempotent retry; circuit-break capability outage; preserve meter/audit consistency
05
Measurement approach
The measure that shows it helped.
Developer funnel cohort; sandbox-to-production conversion; usage/revenue ledger; API-specific success and latency SLO; partner holdout where applicable
Measured on: Active developers; time to first call; success rate; p95 latency; API calls; paying applications; revenue; margin; fraud loss; SLA compliance

Measured in the pilot's validate stage, on your systems, with the comparison agreed first. Every line above is the record's own design intent.

The business side

The change: Calls answered within the agreed latency, and the fraud the bank reports stopped, against calls refused.
Running cost: Per-call; tiered subscription; revenue share; enterprise contract; minimum commitment; paid SLA; setup/integration fee
What evidence supports it: Request and response trace, token scope, consent record, conformance result, meter record and settlement.

The journey in detail

Step by step, from both sides

Step	What the customer experiences	What the operator does
The momentThe moment that started it.	A bank's app is about to move money, and asks the network whether the number's SIM was changed in the last day.	Reads the api's launch state in this network, token scope and the consent record, the identifier presented and the sim-change record, rate limits and territory policy.
The decisionThe decision to be made.	The customer's screen is unchanged.	Returns the last SIM-change signal for the authorised number, requests consent where none is held, or denies.
The safeguardsThe conditions that stop it.	Still unchanged: the action waits until every check has passed.	API launched in the network, token scope, consent, supported identifier, rate limit and territory checks pass.
The actionThe action that reaches the customer.	Return the signal so the bank's own policy steps up, pauses or proceeds; meter the call and settle it. Reaches them on API.	Recommends. The system that holds the right confirms, charges or provisions.
When it goes wrongThe failure, and the recovery.	The bank's token carries the wrong scope and the call is refused during a live transfer, so the customer's payment stalls with no explanation.	The refusal names the scope in the response, the bank's policy proceeds on its own evidence, and the conformance result is kept so the scope is corrected before the next call.
The resultThe change it made.	What changed for them is what is counted; nothing else is claimed.	Calls answered within the agreed latency, and the fraud the bank reports stopped, against calls refused.
The proofThe proof anyone can check.	Can be answered for, later, from the record.	Request and response trace, token scope, consent record, conformance result, meter record and settlement.

Operator systems remain authoritative. HeuriTel reads these to propose an action; it does not decide on their behalf.

The failure, and the recovery

What goes wrong

The bank's token carries the wrong scope and the call is refused during a live transfer, so the customer's payment stalls with no explanation.

What happens then

The refusal names the scope in the response, the bank's policy proceeds on its own evidence, and the conformance result is kept so the scope is corrected before the next call.

The products in this journey

Runs the decision
CAMARA & GSMA Open Gateway APIs
Number verification, SIM swap, know-your-customer, location and device signals are exposed through CAMARA and GSMA Open Gateway interfaces, metered and operated within the operator's API policy.
Contributes
Fraud, Identity & Customer Protection
the risk decisions this signal feeds on the operator's own side
Contributes
Enterprise & SME
the business customer who integrates the interface
The definition it demonstratesHeuriTel SIM Swap API
Results it movesTurn network capabilities into enterprise services · Reduce fraud and identity risk

Available to see today

Read the journey; a working session shows it running.

Request a working session