use case · mobile money
Wallet apps survive the partition.
Across twenty jurisdictions, one signed format.
Mobile-money operators run wallets across markets with different network conditions, different DPA regimes, different agent-banking models, and the same adversaries. EEI signs the wallet side of the flow at the device — verifiable in any of those markets, by any operator's verifier, against the same public key.
EEI signs what the wallet app does at the device — login, recipient lookup, amount entry, biometric, send — across every market the operator runs in. The same token, the same format, the same verifier code, regardless of jurisdiction. The USSD short-code that runs alongside the wallet is not in scope; the wallet app is.
Five things the wallet app signs that the back-end never sees.
- ·01
Wallet-app overlay & accessibility-service abuse
Overlay attacks on the wallet UI (fake PIN entry, fake transfer-confirmation screens) and accessibility-service replays — observable as signed signals on the next event. The runtime sees what the wallet is doing, not what the screen claims to show.
- ·02
OTP-interception evidence
When SMS OTP is bypassed via SIM-swap or screen overlay, the runtime captures the discontinuity inline. The token records that the OTP confirmation arrived from a different network-identity profile than the session opened on.
- ·03
Cross-border continuity
A subscriber roaming from Côte d'Ivoire to Senegal does not invalidate their device identity. The hardware-bound key persists; the network-identity signal records the change; the operator's risk engine reads both.
- ·04
Agent-app vs customer-app separation
Agent banking apps and customer wallet apps run different code with different signing keys. The Evidence Token's event_name and binding.status declare which app, which trust basis, which device — fraud teams stop conflating the two.
- ·05
Settlement-side dispute evidence
The full execution path of a contested transfer — login, recipient lookup, amount entry, biometric, send — is hash-linked in the device ledger. The Commander channel retrieves it for the back-office on demand. Disputes resolve against signed records, not narrative.
One privacy posture. Twenty regimes satisfied at the substrate boundary.
The substrate's strict privacy profile keeps no
PII in evidence and no raw (device_id, tctx)
logging at our boundary. Each regime listed below applies at
the operator's deployment, not at ours, because the data does
not cross our boundary. The producer-conformance checklist
in YEI-001 names each regime explicitly so an operator's DPO
can map controls to local requirements without inferring.
- POPIA §11 South Africa
Strict privacy profile; pseudonymous device identifiers; no raw (device_id, tctx) logging without lawful basis.
- NDPR Nigeria
Same strict posture satisfies the Nigerian Data Protection Regulation.
- DPA 2019 Kenya
Producer-conformance checklist names DPA 2019 explicitly; the operator's DPO maps controls to ODPC requirements.
- DPA 2012 Ghana
Same `strict` profile; pseudonymity at the wallet boundary.
- LPDP Côte d'Ivoire
Loi sur la Protection des Données Personnelles; covered by the strict producer profile.
- Law 09-08 Morocco
Substrate posture is privacy-by-design; CNDP requirements reduce to the operator's deployment configuration.
- DPA Mauritius · Rwanda · Uganda · Tanzania
Each named in the producer-conformance checklist; the substrate's no-PII guarantee removes the substrate from most controlled-data scope.
- GDPR European data subjects
For African operators serving European citizens or processors with EU subprocessors, the strict profile satisfies Article 32 technical measures.
What EEI signs in a mobile-money flow. What it doesn't.
In scope — the wallet app channel: customer wallet apps (Android, iOS), agent banking apps, super-app embedded wallets, hybrid wallet-plus-card products. Anything where the runtime can be embedded in user-land code.
Out of scope — channels without an installable runtime: USSD short-codes (e.g. *165# in Côte d'Ivoire, *126# in Ghana), SMS-based money transfer, IVR. EEI cannot sign what executes inside the carrier's USSD gateway because we cannot embed a runtime there.
Composes with — backend controls: server-side authorization, AML/KYC pipelines, settlement reconciliation, agent commission engines stay where they are. EEI adds the device-side record that the back-end was missing.
Mobile-money operators lean hardest on Network, Fraud, and Operations.
Payments in constrained networks
2G/3G estates, retry deduplication via tctx, orphan transactions surfaced.
DNS Racermodule is reverse-billing compatible.Fraud, malware, integrity
Overlay, repackaging, accessibility-abuse — observable as signed signals at the moment of execution.
Forensics & operations
On-demand ledger retrieval via Commander; cohort outage detection visible before support hears about it.
Execution and key integrity
Agent vs customer device attribution. Audit-grade rejection reasons.
Mobile-money operators reading this typically book a 60-minute briefing scoped to their estate map.
We walk the wallet flow end-to-end against your specific markets, name the regimes that apply, and map your existing fraud-platform inputs to the EEI signal classes. You keep the platform; you add the evidence.
Request a briefing