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 multi-rails. Signée au cœur du parcours de paiement, vérifiée dans votre infrastructure, sans backend YinkoShield.
Une preuve cryptographiquement signée — vérifiable indépendamment, et liée au terminal et à la séquence d'exécution.
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 sur demande.
en production
Déploiements en banque de détail Tier-1 sud-africaine depuis 2019. 30M+ terminaux. Référence disponible sur demande.
- échelle
- 30M+ terminaux mobiles en production
- fragmentation matérielle
- ~13,000 configurations matérielles Android prises en charge
- géographie
- 2 implantations UAE · Afrique du Sud
- en production depuis
- 2019 une banque tier-1 sud-africaine
Que se passe-t-il dans l'exécution que votre back-end ne voit jamais ?
Un client peut tenter un paiement à plusieurs reprises dans une application bancaire, tandis qu'un marchand peut tenter à plusieurs reprises de l'accepter via un terminal ou un appareil mobile. Dans les deux cas, une défaillance applicative, réseau ou de rail peut interrompre le parcours avant qu'un enregistrement back-end valide n'existe.
Le back-end ne voit rien. Le client ou le marchand en subit l'impact.
YinkoShield conserve une preuve d'exécution signée au cœur du parcours logiciel. L'opérateur peut vérifier cette preuve dans sa propre infrastructure et l'utiliser dans ses systèmes existants.
sans EEI
avec EEI
Le même principe s'applique au-delà des paiements : authentification, changements de bénéficiaire, flux OTP, vérifications d'identité, remboursements, opérations sur les clés, sessions en kiosque, workflows hors-ligne — et de plus en plus, les actions d'agents autonomes.
Une fois vérifiée, la même preuve peut soutenir l'investigation et la résolution des litiges, le service automatisé, la surveillance de la stabilité du parc, l'investigation de fraude et les processus d'audit de l'opérateur.
YinkoShield produit et signe la preuve. L'opérateur la vérifie et conserve le contrôle de chaque politique, décision et action.
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.
Format Evidence Token identique sur tous les parcs ; vérifications de cohérence d'exécution calibrées par plateforme.
- mobile →
Banque mobile, fintech, et superapps
Les environnements mobiles tournent en dehors d'une infrastructure contrôlée. Les menaces qui comptent n'y sont pas bloquées à la frontière — elles deviennent une preuve d'exécution signée que vos propres systèmes vérifient et exploitent de façon indépendante.
- Abus d'overlay & accessibility-service, observable
- SIM swap & compromission appareil, signés inline
- Continuité d'identité au fil du parcours utilisateur
- Acceptation marchande · POS · mPOS · SoftPOS →
Acceptation marchande et estates d'acquéreur
L'acceptation marchande ne vit plus seulement sur des terminaux certifiés — elle s'exécute sur POS, SoftPOS, smartphones ordinaires et applications marchandes. L'état appareil, l'intégrité d'exécution et le contexte de paiement deviennent observables à la frontière logicielle.
- Onboarding déterministe sur la flotte
- Continuité d'intégrité offline en zones réseau mortes
- Evidence vérifiable à l'instant de l'exécution
- 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 disponible sur demande.
Demander l'accès à la spécification{
"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…"
}
}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