YinkoShield
Briefing

use case · mobile money

Les apps wallet survivent à la partition.
Sur vingt juridictions, un seul format signé.

Les opérateurs mobile-money font tourner des wallets sur des marchés avec des conditions réseau différentes, des régimes DPA différents, des modèles d'agent banking différents, et les mêmes adversaires. EEI signe le côté wallet du flow à l'appareil — vérifiable dans n'importe lequel de ces marchés, par le vérificateur de n'importe quel opérateur, contre la même clé publique.

réponse courte

EEI signe ce que l'app wallet fait à l'appareil — login, recherche destinataire, saisie montant, biométrie, send — sur chaque marché où l'opérateur tourne. Le même token, le même format, le même code vérificateur, quelle que soit la juridiction. Le short-code USSD qui tourne à côté du wallet n'est pas dans le périmètre ; l'app wallet l'est.

ce que les opérateurs mobile-money obtiennent

Cinq choses que l'app wallet signe et que le back-end ne voit jamais.

  1. ·01

    Abus d'overlay & accessibility-service sur l'app wallet

    Attaques d'overlay sur l'UI wallet (faux écran de saisie de PIN, faux écran de confirmation de transfert) et replays accessibility-service — observables comme signaux signés au prochain événement. Le runtime voit ce que le wallet fait, pas ce que l'écran prétend afficher.

  2. ·02

    Evidence d'interception OTP

    Quand l'OTP SMS est contourné par SIM-swap ou overlay, le runtime capture la discontinuité inline. Le token enregistre que la confirmation OTP est arrivée depuis un profil d'identité réseau différent de celui sur lequel la session a démarré.

  3. ·03

    Continuité cross-frontière

    Un abonné qui roame de la Côte d'Ivoire au Sénégal ne perd pas son identité d'appareil. La clé liée au matériel persiste ; le signal network.identity enregistre le changement ; le risk engine de l'opérateur lit les deux.

  4. ·04

    Séparation app-agent vs app-client

    Les apps de banque agent et les apps wallet client tournent du code différent avec des clés de signature différentes. L'event_name et le binding.status de l'Evidence Token déclarent quelle app, quel trust basis, quel appareil — les équipes fraude arrêtent de confondre les deux.

  5. ·05

    Evidence de litige côté settlement

    Le chemin d'exécution complet d'un transfert contesté — login, recherche destinataire, saisie montant, biométrie, send — est hash-linké dans le ledger appareil. Le canal Commander le récupère pour le back-office sur demande. Les litiges se résolvent contre des enregistrements signés, pas du narratif.

posture juridictionnelle

Une posture de privacy. Vingt régimes satisfaits à la frontière du substrat.

Le profil de privacy strict du substrat ne garde aucune PII dans l'evidence et aucun logging brut (device_id, tctx) à notre frontière. Chaque régime listé ci-dessous s'applique au déploiement de l'opérateur, pas au nôtre, parce que les données ne traversent pas notre frontière. La checklist de conformance producteur dans YEI-001 nomme chaque régime explicitement pour qu'un DPO opérateur puisse mapper les contrôles aux exigences locales sans inférer.

  • POPIA §11 Afrique du Sud

    Profil de privacy strict ; identifiants d'appareil pseudonymes ; pas de logging brut (device_id, tctx) sans base légale.

  • NDPR Nigeria

    La même posture strict satisfait la Nigerian Data Protection Regulation.

  • DPA 2019 Kenya

    La checklist de conformance producteur nomme la DPA 2019 explicitement ; le DPO de l'opérateur mappe les contrôles aux exigences ODPC.

  • DPA 2012 Ghana

    Même profil `strict` ; pseudonymie à la frontière du wallet.

  • LPDP Côte d'Ivoire

    Loi sur la Protection des Données Personnelles ; couverte par le profil producteur strict.

  • Loi 09-08 Maroc

    Posture du substrat privacy-by-design ; les exigences CNDP se réduisent à la configuration de déploiement de l'opérateur.

  • DPA Maurice · Rwanda · Ouganda · Tanzanie

    Chacune nommée dans la checklist de conformance producteur ; la garantie no-PII du substrat retire le substrat de la majorité du périmètre des données contrôlées.

  • RGPD Sujets européens

    Pour les opérateurs africains servant des citoyens européens ou des processeurs avec sub-processeurs UE, le profil strict satisfait les mesures techniques de l'Article 32.

frontière de périmètre

Ce qu'EEI signe dans un flow mobile-money. Ce qu'il ne signe pas.

Dans le périmètre — le canal app wallet : apps wallet client (Android, iOS), apps agent banking, wallets embarqués dans des super-apps, produits hybrides wallet-plus-carte. Tout ce où le runtime peut être embarqué dans le code user-land.

Hors périmètre — canaux sans runtime installable : short-codes USSD (ex. *165# en Côte d'Ivoire, *126# au Ghana), transfert de fonds par SMS, IVR. EEI ne peut pas signer ce qui s'exécute à l'intérieur de la gateway USSD du carrier parce que nous ne pouvons pas y embarquer un runtime.

Compose avec — les contrôles backend : autorisation côté serveur, pipelines AML/KYC, réconciliation de settlement, moteurs de commission agent restent là où ils sont. EEI ajoute l'enregistrement côté appareil que le back-end n'avait pas.

où cela apparaît dans les parcours

Les opérateurs mobile-money s'appuient le plus sur Réseau, Fraude, et Opérations.

Les opérateurs mobile-money réservent typiquement un briefing de 60 minutes scopé à leur carte d'estate.

Nous parcourons le flow wallet de bout en bout contre vos marchés spécifiques, nommons les régimes qui s'appliquent, et mappons vos inputs de plateforme fraude existants aux classes de signaux EEI. Vous gardez la plateforme ; vous ajoutez l'evidence.

Demander un briefing