Skip to content
HeuriTel
Sign in

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

No demonstration is configured for this journey yet.

Seen by the customer · API, English

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

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

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

No action is a valid outcome, and it is recorded with its reason. Nothing is computed on this page: the options are the record's own, and no run has decided anything.

Evidence record

Preview
Reference
Issued when a run is saved. An evaluation that was never saved has none.
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
Stated on every record. In the demonstration no operator system is connected, and each record carries that state.

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.

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

Modelled not observed

No figure is modelled for this journey. The mechanism that could produce the result is stated instead.

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

Observed

Nothing yet. Measurement begins in a pilot’s validate stage, on your systems, against a comparison agreed first.

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

Assumptions, costs and the record’s five answers
  1. 01
    Desired result

    The result wanted.

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

  2. 02
    Mechanism

    The mechanism that could produce it.

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

  3. 03
    Evidence required

    The records kept to show it.

    Request/response trace; token scope; consent record; conformance result; meter record; invoice/settlement; SLA report

  4. 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

  5. 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

Nothing has been observed for this product. Every line above is the record's own design intent; measurement begins in a pilot's validate stage, on your systems, with the comparison agreed first.

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
What the customer experiencesWhat 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.Nothing reaches the customer yet.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 nothing. No action is sent 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, in English.Recommends. The system that holds the right confirms, charges or provisions.
When it goes wrongRefusal, failure and 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.

Refusal, failure and 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

Available to see today

No demonstration is configured for this journey yet.

Request a working session Request a working session