deployments · where we run
Three estates. One Trusted Runtime Primitive. One signed format.
Mobile, POS, and self-service terminals are different environments with different threats. The substrate ships across all three, observes what each one does, and produces evidence in the same shape — verifiable by your stack, your dispute platform, your regulator, your partners.
Three estates converge to one evidence record.
From briefing to production cutover, in eight stages.
A CIO planning a pilot needs the operational shape, not the marketing. The same eight stages apply across mobile, POS, and SST estates — different scoping, identical primitive.
-
·01 · pilot scope
60-min technical briefing with operator's authorization, fraud, and platform-engineering leads. Estate sized; pilot boundary agreed; success criteria written down.
-
·02 · integration path
SDK / runtime module embedded in the application's user-land. No daemon, no out-of-band agent. See platform.
-
·03 · verifier setup
Operator deploys one of four reference verifiers (Python / JS / Go / Java) inside their own infrastructure. See sovereign verification.
-
·04 · key registration
Devices generate a TEE-resident keypair on first boot; public keys register one-way to the operator. See zero-trust bootstrap.
-
·05 · policy wiring
Signed signals feed the operator's existing fraud, AML, and risk pipelines. The substrate signs; the operator's policy decides. See threat model.
-
·06 · scoped evaluation
Pilot runs against the operator's own data and risk thresholds. Success criteria from stage 01 measured; scope expanded or rejected.
-
·07 · production cutover
Phased rollout across the estate. Existing fraud / authorization flows unchanged; signed evidence layered alongside. No backend dependency on YinkoShield.
-
·08 · support model
Flat annual fee, scoped to estate. No per-event metering, no licence beacon. Founder-led briefings; direct engineering contact for production incidents.
- ·01 deployment
Mobile
mobile banking · fintech · neobank · superapp
Mobile execution becomes evidence instead of inference.
The OS, network, user, and runtime can all change between credential and request. We sign what happened in that interval — and surface overlay attacks, SIM swap, app repackaging, and identity continuity along the way.
- overlay & accessibility abuse
- SIM swap, mid-session
- app repackaging
- identity continuity
- restart & lifecycle context
Densest deployment for five of the six journeys.
SEE WHAT WE DO HERE → - ·02 deployment
POS · mPOS · SoftPOS
acquiring · terminal fleets · agent banking
Opaque terminals become deterministic assets.
Standard terminals are opaque to the systems that depend on them. We establish a verifiable trust boundary at the device — replacing server-side assumption with cryptographically attested evidence at the moment of execution.
- terminal-level integrity
- offline ledger continuity
- fleet onboarding
- hardware-key-bound evidence
- agent-banking economics
Carries the load for Network and Operations journeys.
SEE WHAT WE DO HERE → - ·03 deployment
Self-service terminals
bank kiosks · citizen identity · branch fleets
Long-session execution provenance, end-to-end.
Multi-step kiosk flows — payment, account opening, identity verification — are signed and hash-linked from the first touch to the last. Citizen-grade audit substrate for unattended terminals.
- long-session execution
- smart-ID adjacency
- physical-access boundary
- branch-fleet coherence
- multi-step workflow attribution
Audit-grade integrity for citizen-facing workflows.
SEE WHAT WE DO HERE →
The Trusted Runtime Primitive is the same module on every surface.
The TRP interposes on the security-relevant call paths across framework, libc, and syscall boundaries — and runs continuous coherence checks — whether it is embedded in a mobile banking app, a POS terminal's firmware, or a kiosk's service shell. The signed evidence has the same shape regardless of where it ran.
Read the TRP deep article