YinkoShield
Brief

Knowledge Center / Evidence architecture / evidence architecture · 2026·03

Host-side correlation — composing signed evidence with operator pipelines

Once a signed Evidence Token reaches the operator, the question is not what the substrate decides — it doesn't decide anything — but how the operator joins the signed signals to the rails it already runs. Authentication, fraud scoring, AML, dispute. EEI gives each of those four pipelines a signed device-side column they did not have before. Composition, not replacement.

[ host-side correlation · what the operator does with it ] device signed Evidence Token tctx · seq · signals · sig Local Evidence Ledger on-device replay corpus submit operator boundary → authentication · risk step-up policy · decline thresholds + EEI: overlay · debugger · hook · binding column added, pipeline kept fraud · AML · scoring existing model + new feature + EEI: device + runtime + code integrity column added, pipeline kept dispute · audit · retrieval chargeback investigator · regulator + replayable signed sequence per tctx column added, pipeline kept // what changes for the operator EEI does not replace auth, fraud, AML, dispute. EEI gives each pipeline a signed device-side column it didn't have before. join key: tctx links token, auth log, score, dispute case. // composition, not replacement
Once signed signals reach the operator, value comes from joining them to the existing rails — auth, fraud, AML, dispute. EEI does not replace those pipelines; it gives each of them a device-side column they did not have.

1. What arrives at the operator

The operator’s verification endpoint receives a JWS-compact serialised Evidence Token per significant event — typically several per transaction, more in long flows. Each token carries a signal payload, the device’s boot_id, a monotonically-increasing seq, the transaction context (tctx) the host application supplied at TRP initialisation, and the device’s signature.

After verification (chain integrity, signature validity, public-key match against the registry — covered in detail under forward-chaining and Theme 6’s verification-pseudocode), the operator has a verified record of what the device observed during a specific transaction. Composition begins from there.

2. Authentication and risk

The operator’s existing authentication and risk pipeline asks: do I let this transaction proceed, do I step it up, do I decline? The inputs are typically credential strength, behavioural-session indicators, fraud history, transaction velocity, jurisdiction, and amount.

EEI adds device-side observation as a category: was an overlay active during user-confirm; was the debugger attached; did the runtime show a hook-instrumentation signature; did the binding state mismatch the registered device. Commission Delegated Regulation (EU) 2018/389 (the PSD2 RTS) [2] does not prescribe overlay or runtime-environment signals — it specifies SCA elements, dynamic linking (Article 5), and channel security requirements. An operator implementing the RTS may choose to incorporate overlay.detected and the rest of the runtime.environment class as inputs to its own SCA-environment risk assessment under the channel-security and dynamic-linking articles; the substrate is not asserting the user was misled, and the regulation is not asserting it either. Operator policy is the layer that maps device-side signals to step-up, allow-with-monitoring, or decline.

3. Fraud and AML

The operator’s fraud-scoring model and AML/CTF pipeline run parallel to authentication. Their inputs include identity provenance, transaction patterns, counterparty-risk attributes, and velocity bands. FATF Recommendations 16 (wire transfers) and 20 (suspicious-transaction reporting) [1] govern transaction-level monitoring and STR obligations under the risk-based approach.

EEI feeds device.integrity (boot-state, security-patch level, TEE attestation), runtime.environment (root, debugger, hook), and code.integrity (page-hash mismatches that indicate runtime patching) as features. The substrate is not making a fraud or AML decision — it is contributing observable signals the operator’s model can weight however the operator’s risk appetite, jurisdictional posture, and product context dictate.

The decoupling is load-bearing for AML in particular: regulators require that the operator (not a vendor) be able to explain every input to a CTF decision. EEI is auditable from the operator side because the operator holds the records and the verifier.

4. Dispute and audit

When a chargeback investigator opens a case, the question is what happened. The operator’s dispute system retrieves the original authentication record and the transaction record, joins them by case identifier, and presents the result to the investigator.

EEI adds a third record: the signed sequence of device-side events across the transaction — initial TRP setup through user-confirm to submission — replayable per transaction context (tctx). tctx is set at TRP initialisation (the start of the transaction flow), not at user-confirm; the user-confirm moment is itself a named checkpoint signal within that window, alongside any other device-side observations the runtime emits. The investigator sees what the device observed about its own runtime across the transaction window. The full dispute workflow — investigator path, back-office display, what the cardholder is shown — is covered in detail in Theme 6 under dispute-evidence-workflow.

5. The join key

The operator’s pipelines all already have a transaction key — the authorisation code, an ISO 20022 [3] message identifier (e.g. EndToEndId or TxId on credit-transfer rails), the back-office case ID. The signed Evidence Tokens are joinable on tctx, which the host application sets when it initialises TRP for the transaction. The operator wires tctx to whichever transaction key dominates the operator’s data model — there is no new join discipline to adopt.

6. What does not happen

The operator’s existing pipelines are not deprecated, replaced, or re-architected. The auth provider still authenticates. The fraud model still scores. The AML pipeline still flags. The dispute system still retrieves. Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — adds one signed column to each of their inputs and one signed sub-record to each of their dispute cases. That is the entire integration surface.

7. Cross-references

8. External references

[1] FATF. Recommendations 16 (wire transfers) and 20 (suspicious-transaction reporting). fatf-gafi.org/en/topics/fatf-recommendations.html. Cited 2026-03-30.

[2] European Commission. Commission Delegated Regulation (EU) 2018/389 — RTS on Strong Customer Authentication and Common and Secure Communication. EUR-Lex CELEX:32018R0389. eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389. Cited 2026-03-30.

[3] ISO. ISO 20022 — Universal financial industry message scheme. iso20022.org. Cited 2026-03-30.