YinkoShield

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.

concrete example · agent-side cash-out

  1. Agent terminal unlock with biometric
  2. Customer MSISDN entry
  3. Amount entry + commission preview
  4. Customer biometric confirmation
  5. Cash dispense + ledger flush

Each step signed against the agent terminal's TEE-bound key, with the agent's identity declared in the trust basis; full path replayable through the Commander channel into the operator's AML pipeline.

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 can separate agent-side and customer-side execution cleanly inside their existing scoring pipeline.

  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.

where the evidence travels

From agent terminal to AML pipeline, in one signed sequence.

[ agent-banking flow · terminal-side signing ] agent terminal biometric · MSISDN amount · cash Evidence Token JWS · hardware-bound key agent trust basis signed on terminal commission engine calc · payout audit AML pipeline monitor · threshold alert audit · regulator replayable from the ledger via Commander
Token signed on the agent terminal, verified by the operator, replayable in audit. Agent/customer separation by event class is preserved end-to-end.
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.

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.

Map agent-banking AML inputs against EEI signal classes