Comment nous savons que les comptes sont justes
« Sécurité de niveau bancaire » ne veut rien dire — tout le monde l’écrit. Voici les mécanismes réels, ce qu’ils empêchent, et comment les vérifier.
Nous ne détenons pas votre argent
Les fonds restent dans le compte de cantonnement du prestataire agréé. Kobri n’est jamais dépositaire. Si Kobri disparaissait demain, les fonds ne bougeraient pas — ils ne sont pas chez nous.
Registre en partie double
Aucun solde n’est « modifié ». Chaque mouvement produit deux écritures qui s’équilibrent, et le solde est une vue dérivée, recalculable. La somme de tous les soldes vaut exactement zéro — sinon, il y a un incident.
Un franc ne peut pas apparaître
De l’argent créé sans contrepartie est rejeté par la base elle-même. Ce n’est pas une règle du code qu’un bug pourrait contourner : c’est une contrainte du moteur de base de données.
Rien ne s’efface
Les écritures et le journal d’audit sont en ajout seul. Une erreur se corrige par une écriture inverse, jamais par une modification. L’historique reste complet et opposable.
Un journal qui se dénonce lui-même
Chaque ligne du journal porte l’empreinte de la précédente. Modifier une ligne rompt la chaîne — y compris pour quelqu’un qui aurait les pleins pouvoirs sur la base de données. Nous l’avons vérifié en le faisant.
Aucune opération jouée deux fois
Chaque mouvement porte une clé d’unicité. Un réseau qui coupe au mauvais moment, un client qui appuie deux fois : l’opération n’est exécutée qu’une fois, et le rejeu renvoie le résultat d’origine.
Nous avons essayé de falsifier notre propre journal
Avec les droits d’administrateur de la base de données, déclencheurs de protection désactivés, nous avons modifié une ligne du journal d’audit — le scénario du pire, celui d’un attaquant ayant tout obtenu.
vérification de la chaîne d’audit
Rupture détectéecontenu altéré après écriture
La chaîne d’empreintes a signalé l’altération et l’a nommée. Un registre qu’on peut réécrire discrètement n’a aucune valeur devant un régulateur — c’est pour ça que celui-ci ne peut pas l’être.
Ce que ça change selon qui vous êtes
Pour le client
- Recevoir de la monnaie ne demande jamais votre code — si on vous le demande, c’est une fraude.
- Votre téléphone ne change jamais de mains : c’est vous qui saisissez le code.
- Un code volé ne vaut rien : trois minutes, un seul usage, un montant figé.
- Téléphone perdu ? L’appareil est révoqué, votre solde reste intact.
Pour le commerçant
- Vous ne pouvez pas rendre plus que ce que vous avez provisionné — la base le refuse.
- En mode code journalier, votre enveloppe plafonne la perte maximale possible.
- Vous révoquez un code ou un appareil en un clic.
- Chaque opération est traçable et rapprochable de votre caisse.
Pour la microfinance
- Les fonds ne quittent jamais votre compte de cantonnement.
- Un contrôle d’intégrité tourne en continu et se consulte à la demande.
- Le registre est en PostgreSQL standard, intégralement exportable.
- Vos dossiers de notification COBAC sont constitués et suivis automatiquement.
Les limites, dites franchement
Le service n’est pas encore audité par un tiers. Les mécanismes décrits ici sont vérifiés par nos propres tests automatisés, rejoués à chaque modification. Un audit externe est une étape distincte, à mener avant l’ouverture au public.
Le mode « code journalier » est un compromis assumé. Il expose un secret réutilisable dans la journée, pour permettre au commerçant sans caisse informatisée d’utiliser Kobri. Il est donc plafonné, révocable et surveillé — mais il est moins sûr que le mode par défaut, et nous préférons l’écrire que le taire.
Aucun système n’élimine la fraude. Ce qu’on peut faire, c’est la rendre coûteuse, borner ses effets, et la rendre visible après coup. C’est ce à quoi servent le plafonnement, le registre et le journal.
Une question technique précise ?
Nous répondons volontiers dans le détail — schéma de données, tests d’intégrité, procédure de réconciliation.