YinkoShield
Briefing

use case · agent banking

Les agents sont déterministes.
Leurs terminaux signent ce qu'ils ont fait.

Pour la banque ou l'opérateur mobile-money qui fait tourner des milliers d'agents sur des milliers de points de cash-in / cash-out : l'identité d'appareil agent est liée au matériel, l'exécution agent vs client est séparée par clé de signature et classe d'événement, et l'evidence de litige est signée contre l'appareil qui a réellement fait la chose.

réponse courte

EEI signe l'exécution cash-in / cash-out au terminal agent, avec une clé liée au matériel. La signature côté agent est séparée de la signature côté client par classe d'événement et key binding. La compromission d'un terminal agent — appareil rooté, app agent repackagée — remonte comme trust basis déclaré dans chaque Evidence Token ; le moteur de policy de l'opérateur combine cela avec ses règles AML / commission.

ce que les opérateurs agent-banking obtiennent

Cinq choses que le terminal agent signe et que le back-end ne voit jamais.

  1. ·01

    Identité d'appareil agent, liée au matériel

    Chaque terminal agent ancre une paire de clés résidant dans le TEE à la première activation. L'identité est liée à l'appareil ; les événements cash-in/cash-out de l'agent sont signés contre elle. Un terminal perdu ou transféré re-bootstrape visiblement — l'opérateur voit une nouvelle clé publique avec le même agent-id et applique la policy.

  2. ·02

    Séparation appareil agent vs client

    Les apps agent banking 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 agent. Les équipes fraude arrêtent de confondre l'exécution côté agent et côté client.

  3. ·03

    Evidence d'exécution cash-in / cash-out

    Chaque cash-in ou cash-out signe l'exécution complète : identification agent, saisie du numéro client, montant, biométrie (où supportée), confirmation. La séquence hash-linkée est rejouable depuis le ledger appareil via le canal Commander. La fraude par collusion d'agents remonte dans l'attribution du chemin d'exécution, pas dans le narratif.

  4. ·04

    Offline-first pour agents en zone morte

    Les agents ruraux sur réseaux 2G/3G opèrent fréquemment en zones cellulaires mortes. Le Local Evidence Ledger accumule des enregistrements cohérents pendant la partition ; le ledger se rinse en ordre à la reconnexion. Le module DNS Racer est reverse-billing compatible pour les déploiements agent banking zero-rated.

  5. ·05

    Inputs moteur de commission et AML

    Les moteurs de commission settlement et les pipelines AML/KYC consomment l'evidence signée comme input structuré — à côté de leurs règles existantes. La séquence signée est ce que l'investigateur AML interroge quand le pattern de transactions d'un agent semble adversarial. Les litiges se résolvent contre des enregistrements signés, pas du narratif.

surface de menace agent banking

Là où la signature aide. Là où elle n'aide pas.

L'agent banking a des classes de menaces différentes de la fraude côté client. EEI gère certaines déterministiquement ; le reste reste avec les programmes AML et de field-supervision de l'opérateur, là où ils appartiennent.

  • côté agent

    Collusion d'agents

    Agent et client collaborent pour fabriquer des transactions. EEI ne prévient pas cela à lui seul — l'evidence d'exécution côté agent enregistre tout de même le chemin ; le moteur de policy de l'opérateur combine les signaux signés avec le KYC et les patterns comportementaux pour détecter la collusion sur plusieurs agents.

  • côté agent

    Compromission terminal agent

    Appareil agent rooté, app agent repackagée, ou debugger attaché remonte comme signal runtime — `runtime.environment` et `binding.status` déclarent le trust basis. L'opérateur décide s'il refuse le cash-out, escalate au superviseur de terrain, ou autorise avec revue élevée.

  • client

    Attaques d'overlay côté client

    Quand un client utilise sa propre app wallet sur les locaux du même agent, l'EEI côté client tourne dans son app — clés différentes, ledger différent, chemin de signature différent. Le terminal agent ne voit jamais le matériel de signature du client.

  • ops

    Réassignation d'agent-id

    Quand un terminal est transféré entre agents, le flow d'onboarding de l'opérateur enregistre une nouvelle clé publique avec le même agent-id. Le changement remonte à la première transaction ; la ré-attestation de l'identité agent est la décision de policy de l'opérateur.

frontière de périmètre

Ce qu'EEI signe au terminal agent. Ce qu'il ne signe pas.

Dans le périmètre — canal app agent : apps agent banking sur terminaux Android, mPOS, SoftPOS, firmware agent dédié. Tout ce où un runtime peut être embarqué dans le code user-land sur le terminal agent.

Hors périmètre — canaux paper-based et non-app : ledgers papier gérés par l'agent, transferts de cash basés sur voucher, flows agent USSD-only. EEI exige un runtime installé ; les opérations agent offline-papier ne sont pas affectées.

Hors périmètre — collusion agent-client (à elle seule) : EEI signe ce qui s'est exécuté ; il ne détecte pas l'intention. Les patterns de collusion remontent sur de nombreuses transactions et de nombreux agents — c'est le domaine AML de l'opérateur. EEI fournit des inputs signés au pipeline AML.

où cela apparaît dans les parcours

Les déploiements agent banking s'appuient le plus sur Intégrité, Réseau, et Opérations.

Les opérateurs avec des milliers d'agents réservent typiquement un briefing de 60 minutes scopé à leur flow d'onboarding agent et AML.

Nous mappons vos contrôles existants de KYC agent et de field-supervision aux classes de signaux EEI qu'ils alimenteraient, et parcourons la signature cash-in / cash-out de bout en bout. Vous gardez la plateforme AML ; vous ajoutez l'evidence d'exécution par agent.

Demander un briefing