YinkoShield
Brief

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

Signal / verdict separation — the substrate observes, the operator decides

The architectural separation that distinguishes EEI from a fraud-scoring system or a RASP product is the cut between signal and verdict. The substrate signs what was observed — overlay active, debugger attached, boot integrity failed. The operator decides what to do about it — block, step up, allow with alert. The same signed signal stream is replayable into many policy regimes without re-signing.

[ signals · verdicts · the load-bearing separation ] signals — signed by the device observation · no decision · spec-fixed · overlay.detected TYPE_APPLICATION_OVERLAY active · debugger.attached ptrace / lldb attach · boot.integrity verified-boot state · hook.present Frida / Xposed signature · binding.status device-key / install id mismatch · network.identity carrier / SIM id swap · code.integrity page hash mismatch policy decoupling → verdicts — decided by the operator action · jurisdiction-specific · re-policed without re-signing policy A — bank EU overlay → step-up · debugger → block verdict: PSD2-aligned policy B — wallet ZA overlay → review · debugger → block verdict: SARB-aligned policy C — agent banking overlay → allow + alert · debugger → block verdict: agent-network specific one signal stream · three regimes · zero re-signing
The substrate signs what was observed. The operator decides what to do about it. One signal stream feeds many policy regimes; the same signed evidence is replayable, re-policed, and portable across jurisdictions.

1. Signal and verdict

A signal is a typed, signed observation: a fact about the device’s runtime at a specific moment, recorded by the TRP and committed to the ledger. A verdict is a policy output: the operator’s decision, computed from a signal stream, about whether to permit, challenge, decline, or queue a specific transaction.

EEI signs signals and only signals. It does not sign verdicts. The operator computes verdicts inside the operator’s perimeter, against the operator’s policy, with the operator’s accountability. The substrate stays out of the decision.

2. Why the cut sits where it sits

The placement is not stylistic. Three pressures push the boundary to this exact line:

  • Legal accountability. Under GDPR Article 22 [3] and analogous jurisdictional rules, the operator is accountable for automated decisions about a data subject. If the substrate were producing verdicts, the operator would be either passing accountability to a vendor (regulators discourage this) or layering policy on top of vendor policy (which is fragile). Signal-only separation keeps decision accountability cleanly with the operator.
  • Policy heterogeneity. A wallet operator running across multiple jurisdictions sees the same signal class (overlay.detected) trigger different verdicts in different regimes — under the PSD2 SCA RTS [1] in the EU, an overlay during SCA may be the trigger an operator policy uses to step up authentication; under a South African operator’s own conduct policy (the operator’s design, informed by its own Prudential Authority and SARB obligations rather than by any named directive), it may be a flag for manual review; under a different operator’s product context, it may be allowed with alert. One signal stream, multiple verdicts, no re-signing.
  • Auditability. A regulator auditing a refused transaction wants to ask two questions independently: was the signal observation correct, and was the policy decision lawful. Signal / verdict separation lets them be answered independently. The signal is signed and replayable; the policy is the operator’s document.

3. What signals look like

The taxonomy of signal classes is fixed by the YEI-001 spec — operators do not invent new signal classes; they read what the TRP emits. The classes covered by Standard profile include:

  • device.integrity — verified-boot state, security-patch level, attestation chain
  • runtime.environment — root, debugger, hook framework, emulator
  • code.integrity — page-hash invariants, runtime patching
  • binding.status — registered-device match, install-id continuity
  • network.identity — carrier and connectivity-state observations the platform exposes to the host app (Android TelephonyManager fields under the permissions the host app holds; iOS CTCarrier/network-info APIs subject to platform deprecation — ICCID enumeration is unavailable on iOS 16+ and gated on Android, so the field set is platform-and-permission-bounded)
  • overlay.detected — surfaces from MotionEvent.FLAG_WINDOW_IS_OBSCURED / FLAG_WINDOW_IS_PARTIALLY_OBSCURED [4] on touches received on a sensitive surface (per-touch flags, not a continuous “overlay active” query — Android’s package-visibility rules do not expose other apps’ active overlay windows to a host app)
  • accessibility.active — surfaces from Settings.Secure.ENABLED_ACCESSIBILITY_SERVICES [5] (Android, world-readable to the host app); iOS exposes only the host app’s own accessibility state (UIAccessibility queries) and cannot enumerate third-party assistive features from another app — the iOS surface is correspondingly narrower

Each signal is a typed observation with a documented schema. The spec fixes the wire format; operators read it; regulators audit against it.

4. What verdicts look like

Verdicts are not a YEI-001 concept. The spec does not define them. Operators design verdict policies appropriate to their product, their jurisdictions, and their risk appetite. Some operators compute verdicts inside an existing fraud-scoring engine (EEI signals enter as features); some compute them in a rules engine; some combine the two.

What the substrate does is hold a signed record of what the device observed at the moment the operator made the decision. If the operator declined a transaction citing overlay risk, the substrate-signed evidence shows whether overlay.detected was actually true at the moment of decline. If it was not, the operator’s decision was operator-policy-error, not substrate-evidence-error. The cut between the two is what makes the audit clean.

5. One stream, many regimes

The same signed evidence stream produced for one transaction can be re-policed against multiple regimes. An operator running a multi-country wallet receives signals from a device in Lagos and applies one policy regime; the same signal record can be presented to an NDPA 2023 audit, to the operator’s internal audit, to a card-scheme investigator, to a regulator in a transit jurisdiction — without re-signing. The signature commits to the signal, not to the verdict. Re-signing would be required only if the underlying observation changed, which it cannot.

6. What this is not

The separation is not “the substrate is dumb on purpose.” The TRP is sophisticated about what to observe and how to record it accurately under adversarial runtime conditions. It is deliberately silent about what to decide. Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — keeps observation sophistication where the substrate has the right vantage point, and decision authority where the operator has the right accountability.

7. Cross-references

8. External references

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

[2] Republic of South Africa. Protection of Personal Information Act (POPIA). popia.co.za. Cited 2026-04-03.

[3] EU. GDPR Article 22 — Automated individual decision-making. gdpr-info.eu/art-22-gdpr. Cited 2026-04-03.

[4] Android Developers. MotionEvent — FLAG_WINDOW_IS_OBSCURED / FLAG_WINDOW_IS_PARTIALLY_OBSCURED. developer.android.com/reference/android/view/MotionEvent. Cited 2026-04-03.

[5] Android Developers. Settings.Secure.ENABLED_ACCESSIBILITY_SERVICES. developer.android.com/reference/android/provider/Settings.Secure. Cited 2026-04-03.