technical briefing · for the cto and head of engineering
Technical briefing.
Read in seven minutes. Defend in thirty.
Why now, what proof is available on request, what changes, the pilot path, who needs to be in the room, what does not change, and the decision asked. One page, seven sections, no marketing.
Your systems know what was received. They do not always know what was true at execution.
The business outcome is not another fraud tool. It is provable execution context for authentication, fraud, disputes, and audit.
What changes / what does not
What changes
A signed device-side witness is added beside the existing journey.
What does not change
Your app, backend, fraud engine, authentication, AML, dispute process, data custody, and transaction path remain operator-owned.
YinkoShield does not sit in the transaction path. It observes execution locally, signs what matters, and gives operator-owned systems a trusted evidence token.
Why now.
Digital-payment operators can usually prove what the backend received. They are far less able to prove what the mobile, POS, mPOS, SoftPOS, or self-service device actually observed at the moment value moved.
That gap now matters for three reasons.
the hardest attacks have moved into the execution moment
As basic fraud controls improve, the hardest attacks have moved into the execution moment. They happen inside real user journeys — overlay abuse, accessibility misuse, malicious keyboards, code injection, and runtime manipulation.
The backend may see a valid login, a valid device, a valid session, and a valid transaction. What it often cannot prove is whether the execution environment was coherent when the user acted.
YinkoShield gives the operator a signed device-side witness for that moment.
the estate has fragmented faster than the controls have
A bank or payment operator no longer has one clean channel. It has mobile banking, agent devices, Android POS, mPOS, SoftPOS, self-service terminals, peripherals, offline queues, unstable networks, OS fragmentation, and dormant devices that wake up with outdated local state.
Each estate produces logs. Each control sees part of the picture. When something goes wrong, the operator still has to answer the same question: was this execution trustworthy, or did the backend only receive a clean-looking result from an untrusted edge?
YinkoShield is the common evidence layer across those estates.
stronger proof, without expanding data custody
Fraud, dispute, audit, compliance, and support teams need better evidence. Privacy, sovereignty, and data-minimisation expectations make broad backend collection harder to justify.
The answer is not to collect everything; it is to produce small, signed, device-bound evidence at the source, keep custody with the operator, and let existing systems decide what to do with it.
YinkoShield does not replace fraud, authentication, AML, or observability. It gives them execution evidence they do not have today.
The operational need already exists today across mobile, POS, mPOS, SoftPOS, and self-service estates. The same evidence substrate can later extend to delegated or agentic-payment flows.
What changes.
Three operator-side pipelines gain a signed device-side column. Composition, not replacement.
-
auth + risk
Your existing authentication policy gains a signed device-side input — overlay, debugger, hook, binding, code-integrity. The substrate does not decide; it provides the operator's policy engine with a column it did not have. Step-up thresholds, decline rules, frictionless paths — all stay where they are.
-
fraud + AML
Your fraud model and your AML pipeline gain `device.integrity`, `runtime.environment`, `code.integrity`, `binding.status` as features. The substrate is not a fraud-scoring vendor and not an AML pipeline; it is one input the operator's models weight against the operator's risk appetite.
-
dispute + audit
Your dispute system gains a replayable signed sequence per transaction context, joinable on the operator's existing transaction key. The chargeback investigator sees what the device observed at the moment the user confirmed. The chargeback process itself does not change; it just gets a column it did not have.
What proof is available on request.
Public site is the pre-qualifier. The substantive evaluation material is one request away.
- Full YEI-001 specification — twelve sections, two annexes, RFC 2119-register pseudocode, named failure-class enum.
- Cross-language conformance corpus and harness — same input, same verdict across four runtimes.
- Reference verifier source — Python, JavaScript, Go, Java.
- Formal threat model — STRIDE-aligned, in-scope vs out-of-scope declared.
- Deployment references — Tier-1 South African retail bank deployments since 2019. 30M+ endpoints. Reference available on request for qualifying operators.
The pilot path.
From the briefing call to production cutover on a single estate is roughly 10–14 weeks. Two reversible decision gates along the way; one load-bearing decision at the end.
-
·01 · 60-min technical briefing
Architecture deep-dive with operator's authorization, fraud, dispute, and DPO leads.
-
·02 · Pilot scope agreement
One estate, one journey, two-channel verification path. Decision point at week 0.
-
·03 · Verifier setup
Reference verifier deployed inside operator's perimeter. No vendor in the path. Week 1–3.
-
·04 · Key registration + policy
Bootstrap, public-key registry populated; operator wires policy thresholds. Week 3–6.
-
·05 · Scoped evaluation
Live signal stream against the operator's existing baseline. Decision point at week 8 — proceed or pause.
-
·06 · Production cutover
Promote scoped evaluation to production on the chosen estate. Week 10–12.
-
·07 · Estate expansion
Same primitive, same signed format, additional estates and journeys. Operator-paced from here.
For the underlying eight-stage operational shape across estates, see how deployment works.
Who needs to be in the room.
A briefing that lands without all the right operator-side roles present produces a second briefing. Better to invest the calendar time once.
operator side
-
CIO
Owns the architectural decision and the operator-side custody story.
-
Head of Engineering
Owns the integration plan and the runtime budget.
-
Head of Fraud
Reads the signal stream against the existing fraud model. Approves the policy wiring.
-
DPO / Compliance
Maps the strict profile to local minimisation expectations. Approves the data-flow boundary.
-
Payment-platform architect
Owns the verifier deployment, the registry, and the dispute integration.
yinkoshield side
-
Runtime architect
Walks the TRP integration, the platform attestation chain, the offline path.
-
Verifier engineer
Walks the eight-stage pipeline, the conformance corpus, the operator-side deployment shape.
-
Programme lead
Owns the scoped-evaluation gate, the measurement frame, and the cutover decision support.
What does not change.
The architectural commitments the substrate explicitly does not touch — so the CTO can answer the procurement question of which existing rails are affected and which are not.
- The auth provider stays. EEI is a signal source for it.
- The fraud-scoring model stays. EEI is a feature column for it.
- The AML / CTF pipeline stays. EEI is one input for it.
- The dispute and chargeback process stays. EEI gives it a record it did not have.
- Data residency stays where it is — no Evidence Token crosses to YinkoShield, and the private signing key never leaves the device.
- Compliance posture stays operator-side. PCI / SOC 2 / ISO 27001 are out of scope for the substrate by design; the operator's programme owns those against its own deployment.
The decision.
Three sequential commitments, each independent. Two are reversible. The third is the one the CTO actually owns.
-
·01 · decide to take
A 60-minute technical briefing with the operator's authorization, fraud, dispute, and DPO leads. Reversible. Costs an hour.
-
·02 · decide to scope
A pilot on one estate and one journey, with the operator's verifier deployed inside the operator's perimeter. Reversible at the week-8 evaluation gate.
-
·03 · decide to commit
Production cutover on the chosen estate after the scoped-evaluation gate clears. Load-bearing. Owned by the CTO. The other two are gates that lead here.
Request the technical evaluation pack.
We send the YEI-001 specification on request, the deployment-references brief, and a calendar link for the 60-minute technical briefing with the operator-side team.