YinkoShield
Brief
see live

Backend systems prove receipt.
We prove execution.

The device-bound evidence layer for digital payments. Signed at the moment of action. Verifiable without a vendor backend. In production since 2019.

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 under NDA.

in production

Built and operated by Yinkozi since 2013. Witness layer in production since 2019, anchor reference at a Tier-1 South African bank.

scale
0M+ mobile endpoints in production
device fragmentation
~0 Android hardware configurations handled
geography
2 offices UAE · South Africa
in production since
2019 anchor reference: 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).
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.

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 shared with regulators and qualifying partners under NDA.

Request access to the specification
evidence token · minimal profile
{
  "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..." }
}

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