YinkoShield
Brief

[ reference policy pack ]

We sign what executed.
The operator decides what to do about it.

Five decisions only signed, sovereign-verifiable evidence makes possible — across mobile, POS, SST, cross-estate, and operations.

what this is

What it is: five reference decisions that only the substrate enables — replayable proof, sovereign verification, hash-chained continuity, vendor-neutral cross-party verification, and asynchronous signed-ledger retrieval.

What it is not: a wrapper for what other tools already do. Each decision below is reachable only with cryptographically signed, sovereign-verifiable evidence. Not a generic risk-engine input list — generic step-up, hold-for-review, and fraud-score composition belong to RASP, attestation, fingerprinting, telemetry, and the existing fraud stack.

five worked decisions

Mobile, POS, SST, cross-estate, and operations.

decision 01 · Mobile

Cryptographic dispute defense, months after the fact

Setting
Customer disputes a transaction 90 days post hoc — "I never confirmed this."
Substrate properties
evidence_token.signature: es256_tee_anchored
evidence_token.payload_hash: amount_payee
predecessor.hash: links_session
verification.path: operator_pubkey
Decision
Issuer or scheme verifies the Evidence Token against the operator-stored public key. The proof of what executed on the device is reproducible 90 days later — no vendor call, no SaaS in the path.
Boundary note
Does not adjudicate the dispute — supplies cryptographic evidence the dispute process can rely on.
EEI-only because
Signed at execution + sovereign verification → replayable indefinitely without vendor lock-in. RASP and behavioural telemetry produce verdicts that decay with the vendor relationship.

decision 02 · POS / SoftPOS

Offline fleet replay for compliance audit

Setting
An MPoC reviewer or scheme auditor verifies monitoring claims across a 12,000-terminal estate.
Substrate properties
local_evidence_ledger: hash_chained_signed
verification.path: offline_bulk
vendor_in_path: none
Decision
Auditor verifies the entire archive offline against operator-stored public-key material. No per-terminal SaaS call. The signed chains are the audit.
Boundary note
Does not produce the certification — supplies the cryptographically verifiable evidence the audit's conclusion rests on.
EEI-only because
SaaS attestation requires a per-event vendor call — does not scale to bulk compliance review. Only operator-stored signed chains support offline fleet replay.

decision 03 · SST / kiosk

Continuous-timeline forensics for contested workflows

Setting
A multi-step citizen workflow ended in a contested outcome. The user claims they didn't see or confirm what the receipt says.
Substrate properties
local_evidence_ledger: hash_chained_signed
binding.status: continuous_since_bootstrap
predecessor.hash: no_gap
surface.signals: per_step_captured
Decision
Operator reconstructs a verifiable timeline of what the kiosk displayed and what the user confirmed at each step, with cryptographic proof of no gap. Court or regulator verifies independently.
Boundary note
Does not establish user intent — establishes what the device displayed and what was signed in continuous sequence.
EEI-only because
Hash-chained Local Evidence Ledger → continuous-timeline proof. Point-in-time attestation cannot prove no gap; behavioural telemetry isn't signed.

decision 04 · Cross-estate

Scheme arbitration with vendor-neutral evidence

Setting
Cross-border transaction dispute between acquirer and issuer. Different telemetry vendors. No shared SaaS.
Substrate properties
evidence_token.signature: es256_operator_pubkey
verification.path: independent_per_party
vendor_in_path: none
Decision
Acquirer, issuer, and scheme arbitrator each verify the same Evidence Token against the merchant's operator-stored public key. The verification protocol is identical; the conclusion is shared.
Boundary note
Does not replace scheme arbitration rules — supplies cryptographically uniform evidence all parties can agree on.
EEI-only because
Signed against a public key all parties can hold → uniform verification across vendors. Vendor-specific telemetry produces vendor-locked conclusions.

decision 05 · Operations

Asynchronous fleet investigation with signed-ledger retrieval

Setting
A cohort of devices producing anomalous transactions — a subset isn't online right now. Stabilisation needs to start before each device reconnects on its own schedule.
Substrate properties
commander.channel: end_to_end_encrypted
device.response.signature: es256_ztbp_anchored
ledger.retrieval: on_demand
Decision
Operator issues a cohort command (retrieve ledger window, run integrity self-test) via the Commander. Devices pick up on next connectivity, execute, return signed responses. Stabilisation actions follow from cryptographically attested evidence.
Boundary note
Does not replace MDM or EMM device-management — operates alongside, focused on signed-evidence retrieval and cryptographically attested test execution, not device-policy enforcement.
EEI-only because
Commander's PGP-analogous channel (operator-owned verifying key) + signed responses → forensic-grade asynchronous investigation. MDM and EMM responses run through vendor SaaS, not via the device's ZTBP-rooted signing key.
sovereignty

The operator owns the policy. We produce signed inputs.

Each decision above turns on a property only the substrate provides — signing at execution, sovereign verification, hash-chained continuity, vendor-neutral cross-party verification, and asynchronous signed-ledger retrieval. The operator owns the policy; the substrate owns the cryptography. See sovereign verification for the property in full.

Walk these four through your fraud, risk, and auth stack.

Sixty minutes with engineering. We map each decision shape to the inputs your existing policy engine already consumes; you keep the rules, the policy, and the verifier.

Request a policy-pack walkthrough