Runtime coherence: the missing partition layer

Payment systems are distributed systems

Payment infrastructure is typically described in terms of its participants — issuers, acquirers, networks, processors — and its security mechanisms: cryptographic credentials, device attestation, fraud scoring, network monitoring. These are the correct dimensions to secure. They are not, however, the correct frame for understanding the structural problem this document addresses.

The correct frame is distributed systems theory. Every payment transaction involves multiple independent computing nodes exchanging messages across unreliable networks. The device is one such node: it holds local state, performs local computation, and can experience failure, partition, and state divergence independently of the rest of the system.

In distributed systems, a node that loses connectivity does not stop computing. It continues to execute, accumulates local state, and operates under partial information. When connectivity is restored, the system must reconcile the diverged state. This is the structural problem at the heart of every ghost transaction.

What the existing standards observe — and what they do not

The payment industry has built sophisticated infrastructure for securing the card credential and the transaction rail. EMV chip and contactless specifications define how credentials are authenticated and how transactions are validated at the network level. EMV 3DS collects device environment data at authentication time: browser fingerprint, SDK-collected device attributes, providing a snapshot of device state at one moment in the flow.

What none of these standards instrument is the device execution state across the full transaction flow. EMV data answers: did a valid credential authorise this transaction on this rail? It does not answer: what was the device’s runtime state when that credential was used, in what execution sequence, and was that sequence coherent?

Platform attestation mechanisms — including those provided by mobile OS vendors — address device integrity at the moment of the attestation call. They establish whether the device is in a trusted state at a checkpoint. They do not establish what the device did between checkpoints, in what sequence, or whether the execution path between the attestation result and the network request was coherent. This is the interval that runtime coherence instruments. The two are complementary: attestation establishes the checkpoint; runtime coherence establishes what happened between checkpoints.

EMV 3DS and EEI — where one stops and the other begins

EMV 3DS 2.x and EEI are adjacent, not overlapping. 3DS collects a descriptive snapshot of the device at authentication time and hands it to the issuer’s ACS. EEI signs the runtime trajectory between that snapshot and network receipt. The shape of the delta:

The two are designed to compose. 3DS answers can this credential authorise this transaction at this moment? EEI answers what did the runtime do between that moment and the network receipt, and was the sequence coherent? Operators that consume both have a closed loop between credential identity and execution evidence.

The state of partition handling across the stack

Network-layer partition handling has a name: idempotency. Backend state reconciliation has a name: event sourcing. Card-rail credential validation has a name: EMV. These names exist because they map to specified infrastructure that implements a well-defined property — a property that was identified, named, and then built.

Device execution coherence — the ability to establish what a device did, in what order, in what runtime state, between a credential use and a network receipt — does not have an equivalent name in payment infrastructure standards. It does not have a name because it does not have an implementation. This document names it runtime coherence and specifies the infrastructure that implements it.

Runtime coherence is a new infrastructure category, not an extension of an existing one. It addresses the device execution layer: the interval between credential use and network receipt which no existing standard instruments, names, or specifies. EEI is the reference implementation of this category.

The four properties of runtime coherence

Why this gap has not been filled

The device execution layer is the last unresolved partition problem in payment infrastructure. It is reasonable to ask why, if the gap is this clear, it has not already been addressed by the major participants in the ecosystem.

The answer is engineering cost, not awareness. Filling this gap requires operating infrastructure that does not exist inside standard payment engineering organisations:

• Device population coverage at production scale. Consistent evidence guarantees across tens of millions of endpoints require a hardware abstraction layer that has been validated against the full distribution of real-world device configurations — not a representative sample. The tail of the distribution is where production failures occur.
• Continuous regression across hardware fragmentation. TEE availability, Keystore behaviour, and platform API coverage change with every manufacturer release cycle. Maintaining consistent evidence guarantees requires device farms, continuous regression pipelines, and engineering capacity dedicated to tracking hardware variance, not application behaviour.
• Chaos engineering for partition scenarios. Ghost transactions, offline queuing, dual-SIM swap, RTC-only clock environments, and retry storms under degraded networks are not reproducible in standard test environments. Validating ledger coherence under these conditions requires purpose-built network simulation and execution interruption infrastructure.
• Adversarial runtime validation. Evidence integrity under active compromise — not static presence of a threat, but a triggered, dormant, or injection-based attack against the evidence generation layer — requires adversarial test automation that goes beyond standard security testing tooling.

This infrastructure cost is the reason execution evidence does not exist as a native capability inside payment stacks. The operational problem of device-side ambiguity has been observed in production environments — in false decline rates, reconciliation overhead, and dispute resolution cost — but the engineering investment required to solve it at the infrastructure layer has not been made, because it sits outside the core competency of payment infrastructure organisations, whose engineering is optimised for message processing, credential management, and risk scoring, not device-layer execution observation.

YinkoShield’s production deployment represents the resolution of this infrastructure cost, not its avoidance. The edge cases documented in the spec’s production characteristics are not theoretical. They are the cases that surface when execution evidence infrastructure runs at scale across heterogeneous device populations under real-world network conditions. Solving them is the barrier to entry.

What runtime coherence enables, in concrete terms

The Evidence Token, in two profiles

Evidence is delivered as a JWS-compact-encoded ES256 token, embedded with each significant transaction event. Two profiles are defined.

The Minimal Profile (~200 bytes) is the default. It carries the minimal claims required to verify the execution step, correlate retries deterministically, and assess device state, without fetching the full Evidence Record from the device ledger.

{
"eid": "8f1e3a90-2b4c-4f81-b6d7-1c9c3a1f4d12",
"seq": 1044,
"tctx": "01J0T8VQ4F",
"event": "payment.initiated",
"ts": 1714323105421,
"did": "did:yks:Z2gXf...",
"kid": "k.2025-Q2.r3",
"sig_ref": { "url": "yks-ledger://...", "hash": "0x9c4a..." }
}

The Standard Profile (~300 bytes) adds connectivity-state context inline — boot_id, net.connected, net.type, scope — so the gateway can absorb retry logic, offline-queued execution, and SIM continuity decisions in the same request, with no additional roundtrip.

Where the operator places control

Because evidence is portable and verifiable with a public key alone, the operator chooses where in their stack to evaluate it. This is an architectural property of EEI, not a deployment option.

The same evidence can be consumed at multiple control points simultaneously. An edge gateway verifies the token inline; the issuer applies risk policy in the authorization path; the dispute platform retrieves the full ledger record asynchronously. No duplication of evidence generation is required.

In one sentence

For as long as mobile devices have been payment endpoints, the execution interval between device action and network receipt has been the structural blind spot of payment infrastructure. The Trusted Runtime Primitive makes it observable. Runtime coherence makes it verifiable. Policy-execution decoupling makes it operationally flexible. The evidence travels with the transaction, or waits in the ledger until it is needed.

References and standards alignment

EEI is a new architectural category at the device-execution layer, not an extension of an existing standard. The lineage that the spec actually cites or composes with:

• RFC 2119 — Key-words discipline used throughout the normative spec.
• RFC 7515 — JWS — Evidence Token envelope: JWS compact, ES256, three base64url segments.
• RFC 4648 §5 — Base64url-without-padding encoding used for signatures.
• RFC 6979 — Deterministic ECDSA option for the producer’s signing-nonce discipline (CSPRNG also accepted).
• ISO 8583 — DE 48 / DE 124 / DE 125 carry the Evidence Token via the 0xF0 BER-TLV envelope — a private-class, constructed tag chosen specifically because it does not conflict with defined Mastercard or Visa subelement ranges.
• EMV / EMV 3DS — Credential authentication and rail validation. Adjacent and orthogonal to EEI; scheme-authentication outcomes link to EEI events only when an operator’s program explicitly says so.
• STRIDE — Methodology used in the spec’s THREAT_MODEL.md for the in-scope-vs-residual-risk table.
• POPIA §11 — Producer conformance for South African consumers requires the strict privacy profile; no raw (device_id, tctx) logging without a documented lawful processing basis.

See the full standards-alignment table on the specification page →