YinkoShield
Brief

use case · agent banking

Agents are deterministic.
Their terminals sign what they did.

For the bank or mobile-money operator running thousands of agents across thousands of cash-in / cash-out points: agent device identity is hardware-bound, agent vs customer execution is separated by signing key and event class, and dispute evidence is signed against the device that actually did the thing.

short answer

EEI signs cash-in / cash-out execution at the agent terminal, with a hardware-bound key. Agent-side signing is separated from customer-side signing by event class and key binding. Compromise of an agent terminal — rooted device, repackaged agent app — surfaces as a declared trust basis in every Evidence Token; the operator's policy engine combines that with their AML / commission rules.

what agent-banking operators get

Five things the agent terminal signs that the back-end never sees.

  1. ·01

    Agent device identity, hardware-bound

    Each agent terminal anchors a TEE-resident keypair at first activation. The identity is bound to the device; agent cash-in/cash-out events are signed against it. Lost or transferred agent terminals re-bootstrap visibly — the operator sees a new public key with the same agent-id and applies policy.

  2. ·02

    Agent vs customer device 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 agent. Fraud teams stop conflating agent-side and customer-side execution.

  3. ·03

    Cash-in / cash-out execution evidence

    Every cash-in or cash-out signs the full execution: agent identification, customer phone-number entry, amount, biometric (where supported), confirmation. The hash-linked sequence is replayable from the device ledger via the Commander channel. Agent-collusion fraud surfaces in execution-path attribution, not in narrative.

  4. ·04

    Offline-first for dead-zone agents

    Rural agents on 2G/3G networks frequently operate in cellular dead zones. The Local Evidence Ledger accumulates coherent records during partition; the ledger flushes back in order on reconnection. The DNS Racer module is reverse-billing compatible for zero-rated agent-banking deployments.

  5. ·05

    Commission-engine and AML inputs

    Settlement-side commission engines and AML/KYC pipelines consume the signed evidence as a structured input — alongside their existing rules. The signed sequence is what the AML investigator queries when an agent's transaction pattern looks adversarial. Disputes resolve against signed records, not narrative.

agent-banking threat surface

Where signing helps. Where it doesn't.

Agent banking has threat classes that are different from customer-side fraud. EEI handles some of them deterministically; the rest stay with the operator's AML and field-supervision programmes, where they belong.

  • agent-side

    Agent collusion

    Agent and customer collude to manufacture transactions. EEI does not prevent this on its own — agent-side execution evidence still records the path; the operator's policy engine combines signed signals with KYC and behavioural patterns to detect collusion across multiple agents.

  • agent-side

    Agent terminal compromise

    Rooted agent device, repackaged agent app, or attached debugger surfaces as a runtime signal — `runtime.environment` and `binding.status` declare the trust basis. The operator decides whether to refuse the cash-out, escalate to the field supervisor, or allow with elevated review.

  • customer

    Customer-side overlay attacks

    When a customer is using their own wallet app on the same agent's premises, customer-side EEI runs in their own app — different keys, different ledger, different signing path. The agent terminal never sees the customer's signing material.

  • ops

    Agent-id reassignment

    When a terminal is transferred between agents, the operator's onboarding flow registers a new public key with the same agent-id. The change surfaces at first transaction; re-attestation of the agent identity is the operator's policy decision.

scope boundary

What EEI signs at the agent terminal. What it doesn't.

In scope — agent-app channel: agent banking apps on Android terminals, mPOS, SoftPOS, dedicated agent firmware. Anything where a runtime can be embedded in user-land code on the agent terminal.

Out of scope — paper-based and non-app channels: agent-managed paper ledgers, voucher-based cash transfers, USSD-only agent flows. EEI requires an installed runtime; offline-paper agent operations are unaffected.

Out of scope — agent-customer collusion (alone): EEI signs what executed; it does not detect intent. Collusion patterns surface across many transactions and many agents — that's the operator's AML domain. EEI provides signed inputs to the AML pipeline.

where it shows up across journeys

Agent-banking deployments lean hardest on Integrity, Network, and Operations.

Operators with thousands of agents typically book a 60-minute briefing scoped to their agent-onboarding and AML flow.

We map your existing agent KYC and field-supervision controls to the EEI signal classes they would feed, and walk cash-in / cash-out signing end-to-end. You keep the AML platform; you add the per-agent execution evidence.

Request a briefing