use case · mobile money
Wallet apps survive the partition.
Across the jurisdictions our customers operate in, 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 — in each of the markets 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.
concrete example · agent cash-in
- Agent login
- Customer MSISDN entry
- Amount entry
- Biometric confirmation
- Ledger flush
Each step signed against the agent terminal's TEE-bound key; full path replayable from the Local Evidence Ledger via the Commander channel.
Five things the wallet app signs that the back-end did not previously have a record of.
- ·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 — so fraud teams can separate the two cleanly inside their existing scoring pipeline.
- ·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.
From wallet app to dispute pipeline, in one signed sequence.
One privacy posture. Designed to simplify operator compliance mapping across jurisdictions.
The substrate's strict privacy profile keeps no
PII in evidence and no raw (device_id, tctx)
logging at the YinkoShield boundary. Each regime listed below
applies at the operator's deployment, not at YinkoShield's —
no Evidence Token, no private signing key, no telemetry, and
no operator data of any kind crosses to YinkoShield by
construction. 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 designed to support operator compliance with 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; designed for deployment under 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 posture is designed to keep the substrate outside the operator's controlled-data perimeter.
- GDPR European data subjects
For African operators serving European citizens or processors with EU subprocessors, the strict profile supports Article 32 technical-measure mapping.
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.
Map wallet-app evidence against your USSD split