Les systèmes back-end prouvent la réception.
Nous prouvons l'exécution.
La couche de preuve liée au terminal pour les paiements numériques. Signée à l'instant de l'action. Vérifiable sans backend fournisseur. En production depuis 2019.
voix externe · cio, banque tier-1
“Quand j'ai besoin d'identité utilisateur, j'utilise Zscaler. Quand j'ai besoin de device identity, j'utilise YinkoShield.”
CIO d'une banque tier-1 africaine faisant tourner YinkoShield en production depuis 2022, sur des millions d'endpoints. Anonymisé, pas inventé ; énoncé spontanément en revue d'architecture. Nom disponible sous NDA.
en production
Conçu et opéré par Yinkozi depuis 2013. Couche de preuve en production depuis 2019, avec une référence d'ancrage au sein d'une banque tier-1 sud-africaine.
- échelle
- 0M+ terminaux mobiles en production
- fragmentation matérielle
- ~0 configurations matérielles Android prises en charge
- géographie
- 2 implantations UAE · Afrique du Sud
- en production depuis
- 2019 référence d'ancrage : une banque tier-1 sud-africaine
Une nouvelle catégorie dans la confiance des paiements.
la politique reste chez vous
Une politique conditionnelle. Pas un simple interrupteur.
Les solutions dépendantes d'un fournisseur proposent un réglage par contrôle : activer, désactiver ou observer. Le comportement reste identique, quel que soit le contexte métier.
L'execution evidence inverse cette logique. Nous fournissons des signaux signés ; votre moteur de politique les combine avec le contexte métier. Autoriser la consultation de solde sur un terminal compromis. Refuser l'ajout de bénéficiaire sur ce même terminal. Le signal est identique. La décision dépend de l'enjeu.
dépendant fournisseur · rasp
Interrupteur par contrôle : activer, désactiver, ou observer. En mode observer, le fournisseur vous remet un event handler — votre équipe écrit la logique de politique au-dessus. Pas de moyen de rendre le contrôle context-aware sans reconstruire le moteur du fournisseur.
découplé · eei
Signaux signés livrés à votre moteur de politique. Si terminal compromis et action ajout bénéficiaire : refuser. Si terminal compromis et action consultation de solde : autoriser. Conditionnel, contextuel, écrit par vous.
Deux primitives d'infrastructure.
Un runtime de confiance qui signe ce qui s'est passé — et la couche de preuve qui le transporte. Ensemble : une nouvelle catégorie.
Trusted Runtime Primitive
Un environnement d'exécution portable plateforme qui observe ce que le runtime fait réellement et le signe avec une clé liée au matériel. Mêmes garanties d'evidence sur mobile, POS, SoftPOS, et SST — sur ~13 000 configurations matérielles.
Sans le runtime, il n'y a pas d'evidence cohérente.
LIRE →Execution Evidence Layer
L'enregistrement signé et hash-linked de ce qui s'est réellement passé sur l'appareil. Voyage avec la transaction. Vérifiable avec une clé publique seule. Rejouable depuis le ledger local quand une investigation plus profonde est nécessaire.
Sans l'evidence, le runtime n'est qu'un runtime de plus.
LIRE →Six parcours. Un seul substrat signé.
Réseau. Fraude. Expérience. Intégrité. Opérations. Autonomous. Choisissez celui que vos clients, votre équipe fraude, ou votre équipe ops nommeront à voix haute.
- paiements en réseaux contraints
Les paiements survivent à la partition.
“Mes terminaux tournent sur cellulaire et 2G/3G. Les transactions échouent dans les zones blanches. Je n'arrive pas à distinguer les retries des doublons.”
Voir le parcours → - fraude, malware, intégrité adversariale
Comportement adversarial, observable au moment de l'exécution.
“Le malware mobile devient meilleur. Mes modèles de fraude se noient dans du bruit opérationnel qui ressemble à de la fraude mais n'en est pas. Il me faut des signaux propres.”
Voir le parcours → - taux d'approbation et expérience client
Les faux refus arrêtent d'être l'option par défaut.
“Mon taux d'approbation s'érode dans des endroits que je n'arrive pas à expliquer entièrement. Redémarrages d'app, retries qui ressemblent à des doublons, pics de latence. Mes clients m'en tiennent pour responsable.”
Voir le parcours → - intégrité d'exécution et de clé
Garanties cryptographiques sur ce qui s'est exécuté.
“Il me faut une preuve vérifiable que l'exécution côté appareil est conforme à ce que la spec décrit. Voir quand les clés tournent. Savoir quels tokens ont été rejetés et pourquoi.”
Voir le parcours → - forensique et opérations proactives
Voir les incidents arriver. Les investiguer quand ils n'arrivent pas.
“Je veux savoir ce qui est sur le point de casser avant que mon client n'appelle. Quand quelque chose casse, je veux du forensique sans envoyer un ingénieur sur place.”
Voir le parcours → - paiements agentic et exécution autonome
Quand le système agit de lui-même, le substrat sur lequel il a agi devient l'audit.
“Les agents IA s'apprêtent à initier des transactions. Il me faut prouver quel agent a agi, dans quel runtime state, sur quel appareil, dans quelle séquence — sans parser des millions de logs.”
Voir le parcours →
Mobile, POS, SST. Un seul format signé sur tous.
Le même Trusted Runtime Primitive est livré sur chaque écosystème. La preuve sort dans la même forme, vérifiable de la même façon — par votre stack, votre plateforme de dispute, votre régulateur, vos partenaires.
- mobile →
Banque mobile, fintech, et superapps
Les environnements mobiles tournent en dehors d'une infrastructure contrôlée. L'état d'exécution, le contexte appareil, et les interactions utilisateur ont besoin d'une vérification indépendante — pas d'une supposition.
- Abus d'overlay & accessibility-service, observable
- SIM swap & compromission appareil, signés inline
- Continuité d'identité au fil du parcours utilisateur
- POS · mPOS · SoftPOS →
POS et estates d'acquéreur
Les terminaux standards sont opaques pour les systèmes qui en dépendent. L'état appareil, l'intégrité d'exécution, et le contexte de transaction deviennent observables à la frontière du terminal.
- Onboarding déterministe sur la flotte
- Continuité d'intégrité offline en zones réseau mortes
- Evidence vérifiable à l'instant de la transaction
- terminaux libre-service →
SST et estates de libre-service bancaire
Terminaux non-surveillés faisant tourner des sessions longues sur des parcours critiques — paiements, ouverture de compte, vérification d'identité. La runtime coherence est le substrat qui rend ces flows défendables.
- Provenance d'exécution sur sessions longues
- Adjacence Smart-ID et identité nationale
- Frontière de menace d'accès physique observable
Pensé pour les paiements africains et les marchés émergents.
- ·01 propriété
~200 octets
petit en-tête, beaucoup d'information
Token JWS-compact ES256, inline avec chaque requête. Charge de signal substantielle à coût bande passante minimal — conçu pour les estates cellulaires et 2G/3G.
- ·02 propriété
offline by design
le ledger ne dépend pas de la connectivité
L'evidence est générée et signée à l'instant de l'exécution, contre un ledger local append-only hash-linked. La partition est une condition opérationnelle, pas une exception. Les enregistrements rincent au retour de la connectivité — dans l'ordre, signés, intacts.
- ·03 propriété
compatible reverse-billing
fonctionne sous DNS zero-rated
Compatible avec les arrangements de zero-rating des opérateurs mobiles via le module réseau de la plateforme. Les clients en conditions de données limitées restent protégés sans que l'opérateur ne porte le coût des données.
Les opérateurs ne devraient jamais dépendre de nous pour vérifier.
YEI-001 est la spécification. Vérificateurs de référence en Python, JavaScript, Go, et Java. Toute partie disposant d'une clé publique peut vérifier l'evidence indépendamment. Actuellement partagée avec les régulateurs et partenaires qualifiés sous NDA.
Demander l'accès à la spécification{
"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..." }
}Nous briefons les réseaux de paiement, schemes, processeurs, et banques tier-1 sur EEI sur demande.
Pas de pitch commercial. Une conversation technique claire sur la question de savoir si l'execution evidence est le bon substrat pour le problème que vous cherchez à résoudre.
Demander un briefing