category · reference page
Execution Evidence Infrastructure.
A new category in payment trust.
Network has idempotency. Backend has event sourcing. Card rail has EMV. Device execution is the only layer of payment infrastructure that had no equivalent. We named the missing property runtime coherence and specified the substrate that implements it. This page is the reference.
Execution Evidence Infrastructure (EEI) is the device-bound evidence layer for digital payments. It signs what the runtime did at the moment of action, against an append-only ledger that resides on the device, and is verifiable with a public key alone. No vendor backend is in the verification path.
primitive
Trusted Runtime Primitive — wraps syscalls, libc, and framework calls; signs what the runtime does.
artefact
Evidence Token — JWS compact, ES256, ~200 bytes, travels with the transaction.
property
Sovereign verification — any party with the public key verifies independently.
Every other partition layer was named — except this one.
Payment infrastructure is a distributed system. Every transaction crosses multiple independent computing nodes exchanging messages across unreliable networks. Each layer that handles partition has a name and an implementation:
- Network handles partition with idempotency — the same request safely retried produces one effect.
- Backend handles partition with event sourcing — divergent state reconciles against the log.
- Card rail handles credential validation with EMV — cryptographic authenticity at the rail level.
The device execution layer — the interval between credential use and network receipt, where ghost transactions and dispute ambiguity live — had no equivalent. No name, no spec, no infrastructure. EEI is the substrate that fills that gap. The property is called runtime coherence. The reference implementation is in production since 2019.
Composes with what you run. Replaces nothing.
Each existing category does something well. EEI sits where they don't reach — at the device-side execution layer — and produces the signed record they consume.
| Category | What it does | What it does not prove | Where EEI sits |
|---|---|---|---|
| Backend logs | Prove server-side receipt of a transaction request. | Do not prove what the device did to produce that request, or in what runtime state. | EEI signs the device-side execution; the operator combines both. |
| RASP | Detects runtime threats on the device and acts on them locally. | Does not produce portable, verifiable transaction evidence by default. | EEI provides the signed record that downstream parties verify; RASP can enforce inline. |
| Device fingerprinting | Probabilistic identification of a device across sessions. | Does not produce a deterministic, cryptographically signed record of execution. | EEI signs the event with a hardware-bound key; fingerprinting can complement identity. |
| Fraud scoring | Probabilistic risk decisions based on patterns and signals. | Does not produce deterministic evidence usable in disputes or regulatory audit. | EEI supplies a signed input the score consumes; the score remains the operator's. |
| Platform attestation | Proves device or app state at the moment of an attestation call. | Does not prove what happened between attestation calls — credential use, biometric, payload assembly. | EEI covers the interval; the two compose into a continuous trust posture. |
| APM / observability | Observes performance, latency, and error rates of distributed systems. | Not designed for cryptographic dispute proof or device-side execution integrity. | EEI rides the OpenTelemetry pipeline; APM consumes the signed evidence as a span attribute. |
Deep dives: EEI vs RASP · EEI vs Attestation · EEI vs Fingerprinting
Five layers. Two we own. Seven primitives between them.
-
layer 02
Trusted Runtime Primitive
In-process, in-app. Wraps syscalls, libc, framework calls. Signs runtime coherence with a hardware-bound key.
-
layer 03
Evidence Token
JWS compact, ES256, ~200 bytes. Travels inline with the transaction. Two profiles — Minimal and Standard.
-
layer 03
Local Evidence Ledger
Append-only, hash-linked, on the device. Operator reaches in via the Commander forensic channel — no third party in the loop.
-
key management
Zero Trust Bootstrap
Keypair generated in TEE at first init. Private key never leaves. Public key registered to the operator backend.
-
verification
Sovereign verification
Eight-step pipeline. Four reference verifiers — Python, JavaScript, Go, Java. No YinkoShield in the path.
-
boundary
Threat model
Four in-scope threat classes. Four out-of-scope, declared not silently ignored. STRIDE-aligned.
Full architecture: /architecture →
EEI is not a fraud-scoring engine. It supplies signed signals; the operator's risk engine combines them with business context.
EEI is not a replacement for backend controls. Server-side authorization, dispute systems, and reconciliation pipelines stay where they are. EEI adds the device-side record they were missing.
EEI is not a SaaS dashboard. The runtime ships embedded in the operator's app. The verifier runs in the operator's stack. There is no YinkoShield-hosted control plane in the trust path.
EEI is not a substitute for scheme certification. PCI DSS, SOC 2, ISO 27001, scheme programs (Mastercard, Visa) are out-of-scope by construction — declared in CONFORMANCE.md §8 of the spec, not silently ignored.
EEI is not a programme of certification. We do not certify operators, processors, or schemes. The spec, the four reference verifiers, and the cross-language test vectors are sufficient. Adoption is a procurement decision, not a title we issue.
Six operator journeys. One signed substrate.
Tier-1 banks, payment networks, schemes, processors, and acquirers whose decisions depend on device-side execution state. Pick the journey your customers, fraud team, or operations team will name out loud.
Network
Payments survive partition. Retries deduplicated by tctx, orphans surfaced in real time.
Fraud
Adversarial behaviour observable at execution. Overlay, repackaging, downgrade — signed signals.
Experience
False declines stop being the default. Auth context arrives with the transaction.
Integrity
Per-device attribution. Audit-grade rejection reasons, not anonymous failure.
Operations
On-demand ledger retrieval, predictive patterns, cohort outage detection.
Autonomous
Hash-linked agent flows: propose → consent → initiate → confirm. The chain breaks visibly.
Ten questions, ten answers.
The same questions Mastercard architects, scheme analysts, and Tier-1 procurement teams have asked in briefings.
- ·01
What is Execution Evidence Infrastructure?
- Execution Evidence Infrastructure (EEI) is the device-bound evidence layer for digital payments. It signs what the runtime did at the moment of action, against an append-only ledger that resides on the device, and is verifiable with a public key alone. No vendor backend is in the verification path.
- ·02
Why does this category exist now?
- Network has idempotency. Backend has event sourcing. Card rail has EMV. Device execution is the only layer of payment infrastructure that had no equivalent — until the runtime coherence property was named and the substrate that implements it was specified. EEI is that substrate.
- ·03
What does it produce?
- An Evidence Token — a JWS-compact, ES256-signed record (~200 bytes) that travels with the transaction. It carries the device id, sequence, transaction context, event name, timestamp, and a reference to the device-side ledger record. Any party with the operator-registered public key can verify it independently.
- ·04
How is EEI different from RASP?
- RASP gives you binary toggles per check (enable, disable, monitor) and decides on-device. EEI gives you signed signals your policy engine combines with business context, decides operator-side. Same threat surface, different decision point — RASP enforces, EEI testifies. They compose.
- ·05
How is EEI different from device fingerprinting?
- Fingerprinting is a probabilistic identifier derived from device traits. EEI is a deterministic, cryptographically signed record of execution. Fingerprinting answers ‘is this likely the same device?’; EEI answers ‘what did this device actually do, in what order, in what runtime state?’.
- ·06
How is EEI different from platform attestation?
- Platform attestation (Play Integrity, App Attest) establishes that the device was in a trusted state at a checkpoint. EEI establishes what happened between checkpoints — every credential use, biometric, payload assembly, request submission. Attestation is point-in-time; EEI is continuous and ordered.
- ·07
Does verification require a YinkoShield backend?
- No. The reference verifier runs inside the operator's stack against operator-stored public keys. There is no YinkoShield endpoint in the verification path, no licence check at runtime, no telemetry the operator did not ask for. A YinkoShield outage does not interrupt verification. A YinkoShield contract end does not interrupt verification.
- ·08
Where does it deploy?
- Mobile (banking, fintech, neobank, superapp), POS / mPOS / SoftPOS, and self-service terminals (SST). The same Trusted Runtime Primitive ships on every estate; the Evidence Token comes out in the same shape across ~13,000 hardware configurations.
- ·09
Who needs it?
- Tier-1 banks, payment networks, schemes, processors, and acquirers — any operator whose decisions depend on device-side execution state. The substrate has been in production since 2019 across 30M+ endpoints, anchor reference at a Tier-1 South African bank.
- ·10
What is its relationship to YEI-001?
- YEI-001 is the published specification of the EEI substrate. It defines the Evidence Token format, the eight-step verifier pipeline, the integration profiles (ISO 8583 DE 48 minimal, mobile-wallet-retail, agent-assisted-channel), the threat model boundary, and the conformance checklist. Reference verifiers ship in Python, JavaScript, Go, and Java. The spec is currently shared with regulators and qualifying partners under NDA.
YEI-001 is the contract. Not a roadmap.
Twelve sections, two annexes, eight-step verifier pipeline, four reference verifiers (Python, JavaScript, Go, Java), three integration profiles (ISO 8583 DE 48 minimal, mobile-wallet-retail, agent-assisted-channel), formal threat model, conformance checklist. Currently shared with regulators and qualifying partners under NDA.
We brief payment networks, schemes, processors, and Tier-1 banks on EEI by request.
No sales pitch. A clear technical conversation about whether execution evidence is the right substrate for the problem you are trying to solve.
Request a briefing