# Transactions Mojaloop
Cette section couvre les aspects d’une transaction Mojaloop.
# Phases d’une transaction Mojaloop
Un hub de paiements basé sur Mojaloop compense (route et garantit) les paiements entre comptes détenus par des parties finales (personnes, entreprises, administrations, etc.) chez les DFSP, et s’intègre à un partenaire de règlement pour orchestrer les mouvements de fonds entre DFSP participants, soit de manière simultanée (règlement brut en continu), soit de façon différée (diverses formes de règlement net), selon un calendrier de règlement convenu.
Toutes les transactions Mojaloop sont asynchrones (afin de garantir l’utilisation la plus efficiente possible des ressources) et suivent trois phases :
Découverte, pendant laquelle le DFSP du payeur collabore avec le Hub Mojaloop pour déterminer où envoyer le paiement. Cette phase résout un alias vers un DFSP bénéficiaire précis et, avec ce DFSP, un compte individuel.
Accord sur les conditions (devis), pendant laquelle les deux DFSP parties à la transaction conviennent que la transaction peut avoir lieu (sous réserve, par exemple, de restrictions liées à un KYC par paliers) et à quelles conditions (dont frais).
Transfert, lorsque la transaction entre les deux DFSP (et, par procuration, les comptes clients) est compensée.
Ces phases s’inscrivent dans l’asynchronisme de Mojaloop : une transaction est toujours unique, ce qui garantit qu’elle ne sera traitée qu’une seule fois, quel que soit le nombre de fois où elle est soumise au traitement. Cette propriété est l’idempotence : même en cas de connectivité intermittente, le client a la garantie que son compte ne sera débité qu’une seule fois, quel que soit le nombre de tentatives.
Cette approche en trois phases, complétée par l’idempotence, a été conçue pour minimiser le risque d’échecs transactionnels ou de doublons. Mojaloop supprime ainsi le besoin technique de rapprochement transactionnel par les DFSP, réduit la plupart des causes de litiges et minimise ainsi les coûts pour toutes les parties.
Associée à l’approche Mojaloop de la gestion des risques, elle garantit que la plus petite IMF et la plus grande banque internationale peuvent participer à égalité, sans qu’aucune n’impose de risque à l’autre ni au Hub lui-même.
# API Mojaloop
Le Hub Mojaloop expose quatre API. Les deux premières concernent les transactions clients ; les deux autres, l’administration des relations avec les DFSP participants et le règlement des transactions compensées :
API transactionnelle
Mojaloop propose deux API transactionnelles fonctionnellement équivalentes pour les connexions directes avec les participants aux fins de transaction. Elles couvrent tous les cas d’usage Mojaloop et respectent les principes Level One (opens new window). Il s’agit de :- l’API FSP Interoperability (FSPIOP), une API ancienne et solidement éprouvée ;
- un schéma de messages ISO 20022, fondé sur un jeu de messages ISO 20022 provisoirement aligné entre la Mojaloop Foundation et le Registration Management Group (RMG) ISO 20022, adapté aux besoins d’un système de paiements instantanés inclusifs (SPII) tel que Mojaloop. Elle est proposée comme alternative à FSPIOP. Les détails complets de l’implémentation du schéma de messages ISO 20022 par Mojaloop et les modalités d’utilisation attendues de la part des DFSP participants figurent dans le document de pratiques de marché ISO 20022 Mojaloop.
API d’initiation de paiement par des tiers (3PPI / PISP)
Cette API gère les arrangements de paiement par des tiers — paiements initiés par des fintechs pour le compte de leurs clients depuis des comptes détenus chez des DFSP connectés au Hub Mojaloop — et permet d’initier ces paiements une fois autorisés.
API d’administration
Elle permet aux opérateurs de hub de gérer notamment :
création / activation / désactivation des participants dans le Hub ;
ajout et mise à jour des informations de endpoint des participants ;
gestion des comptes, plafonds et positions des participants ;
création des comptes du Hub ;
opérations d’entrée et de sortie de fonds ;
création / mise à jour / consultation des modèles de règlement, pour gestion ultérieure via l’API de règlement ;
consultation des détails des transferts ;
API de règlement
Elle sert à gérer le processus de règlement. Elle n’est pas destinée à la gestion des modèles de règlement.
# Caractéristiques distinctives des transactions
La plupart des fonctions de Mojaloop existent aussi sur d’autres hubs de compensation. Ce qui distingue Mojaloop :
Le flux transactionnel en trois phases et l’idempotence, décrits ci-dessus.
La phase d’accord sur les conditions (devis), qui permet aux deux DFSP de convenir qu’une transaction peut avoir lieu avant tout engagement. Cela prend en charge certains des aspects les plus complexes des transactions entre participants de types différents ; le DFSP bénéficiaire peut vérifier que le compte peut recevoir le paiement, qu’il n’est pas suspendu, que les plafonds ne seront pas dépassés. S’il accepte, il indique les frais éventuels (les frais de hub sont hors transaction). Ce n’est qu’après accord du DFSP payeur et du payeur lui-même sur ces frais et toute autre condition posée par le DFSP bénéficiaire que la transaction est initiée. L’incertitude est ainsi réduite et la probabilité de succès augmentée avant exécution.
La non-répudiation de bout en bout pendant la phase de transfert garantit à chaque partie qu’un message n’a pas été modifié et qu’il provient bien de l’émetteur déclaré. Mojaloop s’appuie sur cette technologie pour que la transaction ne soit engagée que si les deux DFSP payeur et bénéficiaire l’acceptent, sans qu’aucun puisse la nier. Cela rend le rapprochement au niveau transactionnel inutile, ce qui réduit fortement les litiges, supprime le traitement d’exceptions et diminue substantiellement les coûts pour tous les participants. Cela soutient directement les objectifs d’inclusion financière de la Mojaloop Foundation, en levant l’un des principaux obstacles à l’inclusion : le manque de certitude, et donc de confiance, dans les paiements.
La communauté Mojaloop met à disposition des outils gratuits pour connecter les DFSP au Hub ; ils restent dans le périmètre du DFSP. Outre la connexion et les transactions, ils assurent la sécurité du lien et notamment le chaînage à cette capacité de non-répudiation.
L’API PISP est exposée par le Hub Mojaloop, et non par chaque participant. Une fintech s’intègre au Hub et est immédiatement reliée à tous les DFSP connectés, sans intégration API individuelle avec chacun — ce qui réduit considérablement les coûts et améliore la fiabilité pour les fintechs et leurs clients.
# Applicabilité
La présente version de ce document correspond à Mojaloop version 17.0.0 (opens new window).
# Historique du document
| Version | Date | Auteur | Détail |
|---|---|---|---|
| 1.3 | 30 juin 2025 | Paul Makin | Précisions mineures sur la description de l’accord sur les conditions |
| 1.2 | 14 avril 2025 | Paul Makin | Mises à jour liées à la sortie de la V17 |
