# Matrice des fonctionnalités par participant
Ce document présente une matrice détaillée des types de participants, de leurs exigences et des solutions de connectivité recommandées pour l’intégration Mojaloop.
# DFSP et cas d’usage paiement
| Catégorie de participant | Description | Cas d’usage attendus | Exigences d’infrastructure pour l’intégration Mojaloop | SLA de production attendu | Réglementation probablement pertinente | Exigences de sécurité particulières | Options de solution |
|---|---|---|---|---|---|---|---|
| Petit DFSP en auto-hébergement | - Petite institution financière à agence unique. - Postes de travail propres - Cloud et/ou SaaS minimaux. | - Tous les types de transfert Mojaloop sauf masse. - Open banking (y compris PISP, AISP) | - Mini-PC dédié bon marché bas de gamme (p. ex. RPi) - Connexion Internet haut débit petite entreprise unique - Système bancaire cœur auto-hébergé p. ex. Mifos - Pare-feu OS/logiciel sur le même nœud matériel que la couche d’intégration. | - Une certaine indisponibilité acceptable en cas de panne matérielle. - Certains schémas peuvent exclure les DFSP qui ne respectent pas un SLA d’indisponibilité donné. - L’achat de matériel de remplacement en cas de panne totale peut prendre plusieurs jours/semaines. - Jeu complet de fonctions de sécurité Mojaloop : mTLS, JWS, ILP - ~10 TPS de pic soutenu pendant 1 heure. - Capacité max. 864000 sur 24 heures. | - Tenue des registres ? - Sécurité ? | - Pas besoin d’intégration avec les plateformes de sécurité d’entreprise existantes. - Solution entièrement sécurisée « prête à l’emploi » suivant les bonnes pratiques du secteur pour les services exposés à Internet, y compris pare-feu. | Le « Standard Service Manager » est recommandé : solution minimale basée sur l’Integration Toolkit (accessible localement via un outil BI). Elle peut être hébergée sur un serveur de base, d’un serveur milieu de gamme pour une grande IMF ou une petite banque jusqu’à un Raspberry Pi pour les plus petits DFSP avec des exigences de continuité de service moins strictes et des volumes de transaction plus faibles. Le Standard Service Manager ne prend pas en charge les paiements de masse. - Couche d’intégration basée sur Docker Compose. - Couche d’intégration minimale autonome. |
| DFSP faible-moyen en auto-hébergement | - Petite institution financière à une ou deux agences. - Propre « centre de données », c.-à-d. placard à balais avec quelques serveurs, routeur, pare-feu, etc. - Quelques connaissances cloud et/ou usage SaaS. | - Tous les types de transfert Mojaloop - Masse (milliers de transferts). - Open banking (y compris PISP, AISP) | - Nœud matériel serveur de qualité entreprise unique. - Pare-feu OS/logiciel sur le même nœud matériel que la couche d’intégration OU pare-feu matériel dédié. | - Une certaine indisponibilité acceptable en cas de panne matérielle. - Certains schémas peuvent exclure les DFSP qui ne respectent pas un SLA d’indisponibilité donné. - Le remplacement du matériel en cas de panne totale peut prendre des heures. - Jeu complet de fonctions de sécurité Mojaloop : mTLS, JWS, ILP - ~50 TPS de pic soutenu pendant 1 heure. | - Tenue des registres ? - Sécurité ? | - Peut nécessiter une intégration avec les plateformes de sécurité d’entreprise existantes, p. ex. pare-feu, passerelles, etc. ?? à préciser | Le « Enhanced Service Manager » est recommandé : il étend le « Standard Service Manager » décrit précédemment en ajoutant un déploiement Kafka et la prise en charge des paiements de masse. Il peut être hébergé au minimum sur un serveur de base dans le « centre de données » du DFSP. - Couche d’intégration basée sur Docker Compose ou Docker Swarm. - Couche d’intégration minimale autonome. |
| DFSP moyen-élevé en auto-hébergement | - Petite institution financière à une ou deux agences. - Propre « centre de données », c.-à-d. placard à balais avec quelques serveurs, routeur, pare-feu, etc. - Quelques connaissances cloud et/ou usage SaaS. | - Tous les types de transfert Mojaloop - Masse (milliers de transferts). - Open banking (y compris PISP, AISP) | - Pour tolérer la panne d’un nœud matériel, 3 nœuds matériels ou plus sont requis (2n+1). | - Indisponibilité limitée (minutes) acceptable en cas de panne matérielle. - Certains schémas peuvent exclure les DFSP qui ne respectent pas un SLA d’indisponibilité donné. - Matériel de rechange disponible ou services de remplacement très rapides en cas de panne. - Jeu complet de fonctions de sécurité Mojaloop : mTLS, JWS, ILP - ~50 TPS de pic soutenu pendant 1 heure. | - Tenue des registres ? - Sécurité ? | - Peut nécessiter une intégration avec les plateformes de sécurité d’entreprise existantes, p. ex. pare-feu, passerelles, etc. | Le « Enhanced Service Manager » est recommandé : il étend le « Standard Service Manager » décrit précédemment en ajoutant un déploiement Kafka et la prise en charge des paiements de masse. Il peut être hébergé au minimum dans une configuration multi-serveurs redondante du « centre de données » du DFSP. - Couche d’intégration basée sur Kubernetes - Peut disposer déjà d’une technologie d’intégration. |
| Grand DFSP en auto-hébergement | - Institution financière mature multi-agences avec forte capacité informatique interne - Dispose de son propre centre de données et d’experts pour gérer les systèmes - À l’aise avec le cloud et les applications hybrides - Dispose d’une capacité d’ingénierie logicielle interne. | - Tous les types de transfert Mojaloop y compris masse. - Masse (millions de transferts dans une transaction par paquets de 1000, triés par DFSP bénéficiaire). - Open banking (y compris PISP, AISP) | - Haute disponibilité de l’infrastructure interne nécessaire - Plusieurs instances actives de tous les services d’intégration critiques réparties sur plusieurs nœuds matériels. - Stockage de données répliqué haute disponibilité. - peut être multi-site / zone de disponibilité / région. | - Aucune indisponibilité acceptable - Haute disponibilité de la connectivité. - plusieurs connexions actives par des routes diversifiées. - Stockage persistant facultatif. - Le SLA de connexion au schéma et de la couche d’intégration doit s’aligner sur le SLA de l’infrastructure interne existante. - Jusqu’à 800 TPS de pic soutenu pendant 1 heure pour les FXP par exemple. | - Tenue des registres ? - Sécurité ? | - Peut nécessiter une intégration avec les plateformes de sécurité d’entreprise existantes, p. ex. pare-feu, passerelles, etc. | Le « Premium Service Manager » est recommandé : service de type Payment Manager pleinement fonctionnel pour les grands DFSP. Son exploitation demande des ressources importantes ; il doit être hébergé soit dans le centre de données existant du DFSP, soit dans le cloud. - Couche d’intégration basée sur Kubernetes - Peut disposer déjà d’une technologie d’intégration. |
# Fintechs utilisant PISP et/ou AISP
| Catégorie de participant | Description | Cas d’usage attendus | Exigences d’infrastructure pour l’intégration Mojaloop | SLA de production attendu | Réglementation probablement pertinente | Exigences de sécurité particulières | Options de solution |
|---|---|---|---|---|---|---|---|
| Petit PISP/AISP en auto-hébergement | - Petite organisation « agence » unique avec un ou deux produits. - Postes de travail / serveurs propres - Cloud et/ou SaaS minimaux. | - Paiements de masse relativement modestes, p. ex. salaires pour PME | - Mini-PC dédié bon marché bas de gamme (p. ex. RPi) - Connexion Internet haut débit petite entreprise unique - Système bancaire cœur auto-hébergé p. ex. Mifos - Pare-feu OS/logiciel sur le même nœud matériel que la couche d’intégration. | - Une certaine indisponibilité acceptable en cas de panne matérielle. - Certains schémas peuvent exclure les DFSP qui ne respectent pas un SLA d’indisponibilité donné. - L’achat de matériel de remplacement en cas de panne totale peut prendre plusieurs jours/semaines. - Jeu complet de fonctions de sécurité Mojaloop : mTLS, JWS, ILP - SLA interface masse ? - Comment le définir ? Taille de lot ? Temps d’envoi du lot via API ? Délai de réponse aux callbacks ? - Taille max. de lot ~10k paiements - L’envoi de 10k paiements via l’API masse doit prendre < 30 secondes. - La réponse aux callbacks doit prendre < 5 secondes. | - Tenue des registres ? - Sécurité ? | - Pas besoin d’intégration avec les plateformes de sécurité d’entreprise existantes. - Solution entièrement sécurisée « prête à l’emploi » suivant les bonnes pratiques du secteur pour les services exposés à Internet, y compris pare-feu. | - Couche d’intégration basée sur Docker Compose. - Couche d’intégration minimale autonome. |
| PISP/AISP faible-moyen en auto-hébergement | - Petite organisation à une ou deux agences. - Propre « centre de données », c.-à-d. placard à balais avec quelques serveurs, routeur, pare-feu, etc. - Quelques connaissances cloud et/ou usage SaaS. | - Paiements de masse relativement modestes, p. ex. salaires pour PME - Agrégation de comptes | - Nœud matériel serveur de qualité entreprise unique. - Pare-feu OS/logiciel sur le même nœud matériel que la couche d’intégration OU pare-feu matériel dédié. | - Une certaine indisponibilité acceptable en cas de panne matérielle. - Certains schémas peuvent exclure les DFSP qui ne respectent pas un SLA d’indisponibilité donné. - Le remplacement du matériel en cas de panne totale peut prendre des heures. - Jeu complet de fonctions de sécurité Mojaloop : mTLS, JWS, ILP - SLA interface masse ? - Comment le définir ? Taille de lot ? Temps d’envoi du lot via API ? Délai de réponse aux callbacks ? - Taille max. de lot ~25k paiements - L’envoi de 25k paiements via l’API masse doit prendre < 60 secondes. - La réponse aux callbacks doit prendre < 10 secondes. | - Tenue des registres ? - Sécurité ? | - Peut nécessiter une intégration avec les plateformes de sécurité d’entreprise existantes, p. ex. pare-feu, passerelles, etc. ?? à préciser | - Couche d’intégration basée sur Docker Compose ou Docker Swarm. - Couche d’intégration minimale autonome. |
| PISP/AISP moyen-élevé en auto-hébergement | - Petite organisation à une ou deux agences. - Propre « centre de données », c.-à-d. placard à balais avec quelques serveurs, routeur, pare-feu, etc. - Quelques connaissances cloud et/ou usage SaaS. | - Paiement de masse pour grandes organisations, p. ex. ministères - Agrégation de comptes | - Pour tolérer la panne d’un nœud matériel, 3 nœuds matériels ou plus sont requis (2n+1). | - Indisponibilité limitée (minutes) acceptable en cas de panne matérielle. - Certains schémas peuvent exclure les DFSP qui ne respectent pas un SLA d’indisponibilité donné. - Matériel de rechange disponible ou services de remplacement très rapides en cas de panne. - Jeu complet de fonctions de sécurité Mojaloop : mTLS, JWS, ILP - SLA interface masse ? - Comment le définir ? Taille de lot ? Temps d’envoi du lot via API ? Délai de réponse aux callbacks ? - Taille max. de lot ~100-200k paiements - L’envoi de 100-200k paiements via l’API masse doit prendre < 300 secondes. - La réponse aux callbacks doit prendre < 120 secondes. | - Tenue des registres ? - Sécurité ? | - Peut nécessiter une intégration avec les plateformes de sécurité d’entreprise existantes, p. ex. pare-feu, passerelles, etc. | - Couche d’intégration basée sur Kubernetes - Peut disposer déjà d’une technologie d’intégration. |
| Grand PISP/AISP en auto-hébergement | - Organisation mature multi-agences avec forte capacité informatique interne - Dispose de son propre centre de données et d’experts pour gérer les systèmes - À l’aise avec le cloud et les applications hybrides - Dispose d’une capacité d’ingénierie logicielle interne. | - Paiement de masse pour grandes organisations, p. ex. ministères | - Haute disponibilité de l’infrastructure interne nécessaire - Plusieurs instances actives de tous les services d’intégration critiques réparties sur plusieurs nœuds matériels. - Stockage de données répliqué haute disponibilité. - peut être multi-site / zone de disponibilité / région. | - Aucune indisponibilité acceptable - Haute disponibilité de la connectivité. - plusieurs connexions actives par des routes diversifiées. - Stockage persistant facultatif. - Le SLA de connexion au schéma et de la couche d’intégration doit s’aligner sur le SLA de l’infrastructure interne existante. - SLA interface masse ? - Comment le définir ? Taille de lot ? Temps d’envoi du lot via API ? Délai de réponse aux callbacks ? - Taille max. de lot ~1M paiements - L’envoi de 1M paiements via l’API masse doit prendre < 600 secondes. - La réponse aux callbacks doit prendre < 300 secondes. | - Tenue des registres ? - Sécurité ? | - Peut nécessiter une intégration avec les plateformes de sécurité d’entreprise existantes, p. ex. pare-feu, passerelles, etc. | - Couche d’intégration basée sur Kubernetes - Peut disposer déjà d’une technologie d’intégration. |
# Historique du document
| Version | Date | Auteur | Détail |
|---|---|---|---|
| 1.0 | 9 juin 2025 | Tony Williams | Version initiale |