Le Kenya ne propose pas seulement d’ajouter de nouvelles licences à son secteur des paiements. Le projet de National Payment System Bill, 2026, publié pour consultation par le Trésor national et la Banque centrale du Kenya, déplacerait plusieurs sujets jusque-là souvent traités comme des objectifs techniques ou commerciaux vers le domaine des obligations contrôlables par le régulateur.
Le point le plus visible est l’interopérabilité. Mais le changement le plus important se trouve peut-être ailleurs : dans la manière dont le texte relie interopérabilité, incidents, sous-traitance, rapprochement, protection des fonds et traçabilité. Autrement dit, il ne demande pas uniquement que les systèmes puissent se connecter. Il cherche à déterminer qui répond de leur fonctionnement lorsque la chaîne de paiement se dégrade.
Cette analyse porte sur le projet de loi et le projet de politique nationale publiés en septembre 2026. Ils ne constituent pas encore le droit en vigueur. Les commentaires publics sont attendus au plus tard le 9 octobre 2026.
D’une interopérabilité annoncée à une obligation opposable
Le Kenya dispose déjà d’une interopérabilité mobile money relativement avancée. Le projet de politique rappelle que l’interopérabilité personne-à-personne a été introduite en 2018 et que la Banque centrale considérait, en juillet 2022, que l’interopérabilité entre les opérateurs participants couvrait aussi les paiements marchands et de factures.
Le diagnostic officiel reste néanmoins prudent : les banques, opérateurs mobile money, prestataires de services de paiement, infrastructures et plateformes publiques ne sont pas encore connectés de façon fluide pour tous les usages.
La clause 28 du projet de loi change la nature du sujet. Elle prévoit que chaque prestataire de services de paiement et opérateur de système utilise des systèmes interopérables avec ceux des autres acteurs et de leurs agents. La Banque centrale pourrait imposer la conclusion d’un accord d’interopérabilité. Le non-respect exposerait l’acteur à une mesure administrative.
La distinction est importante. Une stratégie d’interopérabilité fixe une direction. Une obligation légale crée un pouvoir d’exécution. Elle peut réduire la capacité d’un acteur dominant à retarder une connexion qui diminuerait son avantage de réseau.
Elle ne garantit cependant pas, à elle seule, une interopérabilité performante. Le texte devra encore être complété par des règles sur les API, les messages, la qualité de service, les frais, la répartition des coûts, les délais de règlement, les litiges et la responsabilité en cas d’échec. Sans ces paramètres, deux systèmes peuvent être juridiquement tenus de communiquer tout en offrant un service lent, cher ou difficile à rapprocher.
Le véritable déplacement : les opérations entrent dans le périmètre légal
Le projet rend explicitement déclarables plusieurs événements qui se trouvent au cœur du travail quotidien des équipes de paiement. La clause 33 cite notamment :
- la perte, l’accès non autorisé ou le détournement de fonds clients ;
- les écarts de rapprochement dépassant un seuil fixé par la Banque centrale ;
- une panne prolongée ou systémique affectant le traitement ou le règlement ;
- la défaillance ou la dégradation importante d’un prestataire critique ;
- une insuffisance de liquidité, un incident cyber ou une violation importante de données.
Cette liste est plus structurante qu’une obligation générale de signaler les incidents. Elle reconnaît que la résilience d’un paiement ne dépend pas uniquement de la plateforme visible par le client. Elle dépend aussi des prestataires techniques, des comptes de cantonnement, du règlement, des fichiers de rapprochement et de la capacité à détecter une différence entre ce que le système croit devoir au client et ce qui est effectivement détenu.
Le projet renforce cette logique par deux autres mécanismes. D’abord, l’externalisation d’une fonction opérationnelle nécessiterait l’accord écrit préalable de la Banque centrale lorsqu’une défaillance pourrait compromettre la continuité, la solidité ou la conformité du service. Ensuite, un audit indépendant des systèmes devrait être remis chaque année.
En pratique, une fintech ne pourrait plus considérer son processeur, son hébergeur ou son fournisseur de KYC comme une boîte noire qui porte seul le risque. Le prestataire réglementé resterait responsable de son architecture de contrôle et de la démonstration de sa résilience.
Le périmètre réglementaire suit davantage les fonctions
Le projet distingue des catégories qui correspondent à des fonctions réelles de la chaîne de paiement : initiation de paiement, information sur les comptes, acquisition marchande, wallet électronique, transfert d’argent, émission de monnaie électronique, passerelle de paiement, messagerie, schéma de cartes, switching et compensation.
Ce choix limite un problème classique : des entreprises différentes peuvent exécuter des fonctions économiques proches tout en se présentant sous des étiquettes commerciales différentes. Une supervision centrée sur la fonction permet théoriquement de rapprocher l’exigence réglementaire du risque réellement créé.
Mais la frontière devra être appliquée avec précision. Une passerelle qui ne détient pas les fonds n’a pas le même profil de risque qu’un émetteur de monnaie électronique. Un fournisseur d’information sur les comptes ne porte pas le risque de règlement d’un acquéreur. La qualité des seuils de capital, des exemptions et des règles proportionnées sera donc déterminante pour éviter que la modernisation ne crée une barrière excessive à l’entrée.
Fonds clients, finalité et traçabilité : trois protections complémentaires
Le projet prévoit que les émetteurs de monnaie électronique et fournisseurs de wallets conservent l’intégralité des fonds reçus des clients dans des comptes de fiducie ouverts auprès de banques ou de banques de microfinance. Le solde ne pourrait jamais être inférieur au montant dû aux clients. Les fonds seraient séparés de ceux de l’entreprise et protégés contre les créanciers en cas d’insolvabilité.
Cette protection concerne la solvabilité du détenteur des fonds. Elle ne remplace pas la finalité du règlement. La clause 42 traite séparément le moment où une instruction devient finale et irrévocable selon les règles du système, tout en laissant la possibilité de récupérer une opération issue d’une fraude, d’une erreur ou d’une faute selon les modalités futures.
La clause 48 ajoute une troisième couche : chaque paiement devrait conserver les informations nécessaires pour identifier l’émetteur et le bénéficiaire, ou au minimum des références uniques lorsqu’aucun compte n’est utilisé. Ces informations devraient suivre l’opération tout au long de la chaîne.
Ces trois dispositifs ne sont pas interchangeables :
| Risque | Réponse du projet |
|---|---|
| Le prestataire utilise ou perd les fonds des clients | Cantonnement et protection fiduciaire |
| Une opération réglée est remise en cause | Règles de finalité et d’irrévocabilité |
| Une transaction ne peut pas être reconstituée | Identifiants et données conservés sur toute la chaîne |
La combinaison est pertinente pour les wallets et les paiements transfrontaliers. Elle peut toutefois augmenter la quantité de données personnelles circulant entre intermédiaires. L’efficacité de la traçabilité dépendra donc du principe de minimisation, de la sécurité des échanges et des règles de conservation.
L’open finance est créée, mais pas encore définie opérationnellement
La clause 29 obligerait les prestataires et opérateurs à utiliser des systèmes capables de partager de manière sécurisée les données des clients avec des tiers. La Banque centrale pourrait imposer un mécanisme de partage après consentement du client.
Le principe est clair. Le modèle opérationnel ne l’est pas encore. Le projet renvoie à de futurs règlements. Ceux-ci devront répondre à des questions décisives : quelles données seront accessibles, selon quelles API, pendant combien de temps, avec quel mécanisme de consentement, qui supportera le coût de connexion et qui sera responsable lorsqu’une instruction ou une donnée est erronée.
Ce renvoi n’est pas un détail. Dans l’open finance, l’avantage concurrentiel ne provient pas seulement du droit d’accès. Il dépend de la qualité des interfaces, de la disponibilité des données, du coût d’intégration et de la gestion des incidents.
Ce que cette réforme peut enseigner aux autres marchés africains
Le texte kényan ne doit pas être copié mécaniquement. Les architectures de marché, les pouvoirs des banques centrales et le poids relatif des banques, opérateurs télécoms et fintechs diffèrent entre le Kenya, l’UEMOA et la CEMAC.
Il fournit néanmoins une grille de questions utile :
- L’interopérabilité est-elle un objectif politique, une norme technique ou une obligation exécutoire ?
- Les écarts de rapprochement et les pannes de tiers sont-ils définis comme des incidents réglementaires ?
- Les règles protègent-elles séparément les fonds, la finalité et la traçabilité ?
- Le régime de licence suit-il les fonctions réellement exercées ?
- Les futurs règlements précisent-ils les coûts, standards, responsabilités et niveaux de service ?
La contribution la plus originale du projet n’est donc pas de promettre davantage d’innovation. Elle consiste à placer les opérations de paiement dans le champ de la responsabilité réglementaire. Son efficacité dépendra maintenant des règlements d’application et de la capacité de la Banque centrale à transformer des principes généraux en seuils, standards et contrôles mesurables.
