How should regulators and payment operators divide responsibility for mobile fraud control?

How regulators and operators split the control model

The cleanest division is between rule-setting and proof. Regulators should define the minimum standard for fraud controls, evidence retention and reporting quality, while payment operators must implement those controls in the app, device and transaction stack. That split matters because the party moving the money is the one with the telemetry, operational levers and remediation capability.

For mobile fraud control, responsibility cannot stop at written policy. The operator has to demonstrate that controls are active in production, measurable and auditable, including device checks, runtime monitoring and transaction-level decisioning. Regulators can require the outcome, but they should not be expected to operate the control plane for a live payment flow.

This also means responsibility should follow practical control ownership. If the fraud path depends on the handset, the session, the authentication event or the payment initiation step, the operator owns the corresponding safeguard and the evidence that it works. Regulators then test whether the operator can prove coverage, not whether the operator has adopted a generic control statement.

Why evidence beats policy statements

Mobile fraud programs fail when governance is treated as documentation rather than operational assurance. A policy can say that devices are checked and anomalous behaviour is monitored, but regulators and auditors need evidence of what was enforced, when it was enforced and how exceptions were handled. That is the difference between compliance on paper and control in practice.

The strongest evidence usually comes from observable signals, not narrative claims. Examples include device integrity checks, runtime risk scoring, blocked high-risk attempts, alert handling records and auditable management reporting. Financial Services Identity Security Guide is useful here because it frames the control burden in regulated financial environments, where assurance, access control and accountability all have to be demonstrable.

Operators should also separate preventive controls from detective controls. A regulator may accept that no control blocks every fraud path, but it should expect the operator to detect abuse quickly, preserve evidence and show that the control set can be tuned when attack patterns change. In practice, the proof standard is stronger than the policy standard because fraud control is only meaningful when it survives real transaction pressure.

Where mobile fraud responsibility becomes operationally visible

The practical boundary shows up in three places: device trust, session trust and payment trust. Device trust asks whether the app is running in a context that the operator can reasonably trust. Session trust asks whether the current interaction looks like a genuine customer action or an assisted, hijacked or automated one. Payment trust asks whether the transfer should proceed, be delayed, or be stepped up for more friction.

This is why regulators should avoid over-specifying implementation detail while still requiring a minimum evidence pattern. Operators need freedom to choose controls that fit their channel, but they cannot use that flexibility to avoid measurable protection. Payment Fraud Guide is a useful reference for the broader fraud mechanics that sit behind those control decisions, especially where transaction authorisation, friction and dispute handling interact.

Responsibility becomes clearer when the control failure can be tied to a concrete step in the payment journey. If the weakness is an exposed app secret, an unsafe device state, a suspicious session or a missed behavioural signal, the operator owns the remediation loop. Regulators should then ask whether the operator can show control coverage, not whether it can explain the fraud after the fact.

Practitioner Guidance

What to verify: Regulators should verify that the operator can produce evidence for each control stage, not just a policy and a dashboard. Operators should be able to show what was checked, what was blocked, what was escalated and what was logged for review.

Decision rule: If a control changes whether a payment can proceed, it is an operator responsibility. If a control only defines the baseline expectation or reporting requirement, it is a regulatory responsibility.

Common mistake: Treating “we have fraud controls” as equivalent to “we can prove the controls worked in production.” For mobile fraud, that gap is where most governance failures start.

What good looks like: The operator can trace each high-risk payment decision back to device signals, runtime checks and an auditable outcome, while the regulator can test that evidence against a published standard.

Practitioner takeaway: In mobile fraud, the regulator sets the bar, but the operator must carry the burden of proof, because only the operator controls the live environment where fraud is detected, blocked and recorded.

Related resources from NHI Mgmt Group

• How should financial institutions in Kenya respond to fraud that moves across banks, mobile operators, and payment providers?
• Who is accountable when betting fraud spreads across operators and regulators?
• How should retailers secure mobile payment and loyalty flows against fraud?
• How should mobile network operators govern agentic AI in eSIM operations without losing operational control?