# 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 :

  1. 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.  

  2. 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).  

  3. 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 :

  1. 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.
  2. 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.

  3. 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 ;

  4. 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 :

  1. Le flux transactionnel en trois phases et l’idempotence, dĂ©crits ci-dessus.  

  2. 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.

  3. 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.

  4. 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