YinkoShield
Brief
see live

Backend systems prove receipt.
We prove execution.

The device-bound evidence layer for multirail digital payments. Signed inside the payment journey, verified inside your infrastructure, with no YinkoShield backend required.

Cryptographically signed evidence — independently verifiable, and tied to the device and execution sequence.

Request a briefing See where it sits

external voice · cio, tier-1 bank

“When I need user identity I use Zscaler. When I need device identity I use YinkoShield.”

CIO of an African Tier-1 bank running YinkoShield in production since 2022, across millions of endpoints. Anonymised, not invented; said unprompted in an architecture review. Name available on request.

in production

Tier-1 South African retail bank deployments since 2019. 30M+ endpoints. Reference available on request.

scale
30M+ mobile endpoints in production
device fragmentation
~13,000 Android hardware configurations handled
geography
2 offices UAE · South Africa
in production since
2019 a Tier-1 South African bank
An editorial triptych: a young woman on her phone at an agent-banking corridor (mobile); a market trader processing a payment on a small POS terminal (POS); a man at a self-service banking kiosk in a branch (SST).
invisible execution

What happens inside the execution your backend never sees?

A customer may repeatedly attempt a payment inside a banking app, while a merchant may repeatedly attempt to accept one through a terminal or mobile device. In both cases, application, network or rail failure can stop the journey before a valid backend record exists.

The backend sees nothing. The customer or merchant experiences the impact.

YinkoShield preserves signed execution evidence inside the software journey. The operator can verify that evidence inside its own infrastructure and use it within its existing systems.

without EEI

Execution begins No backend event No evidence No confident action

with EEI

Execution begins Signed execution evidence Operator verification Operator policy or action

The same principle applies beyond payments: authentication, beneficiary changes, OTP flows, identity checks, refunds, key operations, kiosk sessions, offline workflows — and increasingly, autonomous agent actions.

Once verified, the same evidence can support the operator's dispute investigation and resolution, automated servicing, fleet-stability monitoring, fraud investigation and audit processes.

YinkoShield produces and signs the evidence. The operator verifies it and retains control of every policy, decision and action.

where it sits

A new category in payment trust.

continuous · ordered → ← point-in-time ↑ sovereign ↓ vendor-coupled point-in-time · sovereign Open authentication primitives Verifiable, but only at the moment of authentication. Silent in between. point-in-time · vendor-coupled Vendor attestation services Device posture at a checkpoint, verified back to the vendor cloud. continuous · vendor-coupled Mobile observability & RASP Continuous, but flowing to a vendor data plane. Policy bound to the vendor. continuous · sovereign · open Execution Evidence Infrastructure Continuous, signed, ordered execution record. Verifiable by anyone with the public key. Policy stays with the operator.

policy stays with you

Conditional policy. Not a binary toggle.

Vendor-coupled tools give you a switch per check — enable, disable, or monitor. The check fires the same way regardless of what the user is trying to do.

Execution evidence inverts that. We supply signed signals; your policy engine combines them with business context. Allow a balance check on a rooted device. Refuse to add a new beneficiary on the same device. The signal is the same; the response is conditional on what's at stake.

vendor-coupled · rasp

Per-check switch: enable, disable, or monitor. In monitor mode, the vendor hands you an event handler — your team writes the policy logic against it. No way to make the check context-aware without rebuilding the vendor's engine.

decoupled · eei

Signed signals delivered to your policy engine. If rooted device and action is add beneficiary: refuse. If rooted device and action is view balance: allow. Conditional, contextual, written by you.

what we built

Two infrastructure primitives.

A trusted runtime that signs what happened — and the evidence layer that carries it. Together: a new category.

·01 Layer 02 · foundation

Trusted Runtime Primitive

A platform-portable execution environment that observes what the runtime actually does and signs it with a hardware-bound key. Same evidence guarantees across mobile, POS, SoftPOS, and SST estates — across ~13,000 hardware configurations.

Without the runtime, there is no consistent evidence.

READ →
·02 Layer 03 · evidence layer

Execution Evidence Layer

The signed, hash-linked record of what actually happened on the device. Travels with the transaction. Verifiable with a public key alone. Replayable from the local ledger when a deeper investigation is needed.

Without the evidence, the runtime is just another runtime.

READ →
pick the journey you want to improve

Six journeys. One signed substrate.

Network. Fraud. Experience. Integrity. Operations. Autonomous. Pick the one your customers, fraud team, or operations team will name out loud.

where it deploys

Mobile, POS, SST. One signed format across all of them.

The same Trusted Runtime Primitive ships across every estate. The evidence comes out in the same shape, verifiable the same way — by your stack, your dispute platform, your regulator, your partners.

Same Evidence Token format across estates; runtime coherence checks calibrated per platform.

Mobile banking · fintech POS terminals · agents SST kiosks · branches ONE EVIDENCE FORMAT JWS · ES256 · ~200 bytes CONSUMED BY · ANY PARTY WITH THE PUBLIC KEY issuers · schemes · acquirers · risk engines dispute platforms · partners · regulators
built for the conditions

Designed for African and emerging-market payments.

  • ·01 property

    ~200 bytes

    tiny header, big information

    JWS-compact ES256 token, inline with each request. Substantial signal payload at minimal bandwidth cost — designed for cellular and 2G/3G estates.

  • ·02 property

    offline by design

    the ledger does not depend on connectivity

    Evidence is generated and signed at execution time, against a local append-only hash-linked ledger. Partition is an operating condition, not an exception. Records flush when connectivity returns — in order, signed, intact.

  • ·03 property

    reverse-billing compatible

    works under zero-rated DNS

    Compatible with mobile network operator zero-rating arrangements through the platform's network module. Customers in low-data conditions stay protected without the operator carrying the data cost.

specification

Operators should never depend on us to verify.

YEI-001 is the specification. Reference verifiers in Python, JavaScript, Go, and Java. Any party with a public key can verify evidence independently. Currently available on request.

Request access to the specification
evidence token · minimal profile
{
  "eid":   "8f1e3a90-2b4c-4f81-b6d7…",
  "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…"
  }
}

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