Analyse technique de construction d’une
banque en ligne
Wilson Tenepo
Novembre 2024
1
Contents
1 Introduction 3
2 Trajectoire 4
2.1 Les différents models de banques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 La structure de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Étude des différents flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Les fonctionnalités possibles à proposer 7
3.1 Manipulation interne de fonds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Comment les fonds entrent et sortent de la plateforme . . . . . . . . . . . . . . . . 7
3.2.1 Transaction entre les banques et notre plateforme . . . . . . . . . . . . . . . 8
3.2.2 Paiements en ligne par carte . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Fournir des APIs de paiement . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Les possibilités es Afrique 12
4.1 L’Open Banking en Afrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Peut-on faire sans l’Open Banking ? . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Architecture et technologies pour le projet 14
6 Glossaire 15
7 Bibliographie 16
2
1 Introduction
Dans un monde en constante évolution numérique, les services financiers doivent s’adapter aux
nouvelles attentes des clients. Les technologies de l’information ont redéfini la manière dont les
utilisateurs interagissent avec les services bancaires, en particulier avec l’essor des banques en ligne
et des néobanques.
Cette analyse technique explore les différentes classifications de banques et les technologies sous-
jacentes qui permettent leur fonctionnement. Elle met en lumière les caractéristiques spécifiques
des banques traditionnelles, des banques en ligne, des néobanques et des plateformes de paiement.
L’objectif est de comprendre les infrastructures nécessaires pour la création d’une banque en ligne
moderne et les défis techniques associés.
En examinant les fondements de chaque type de structure bancaire, ce document permettra de
clarifier les besoins technologiques pour la création d’une plateforme de services financiers entière-
ment digitale.
3
2 Trajectoire
2.1 Les différents models de banques
Il est important de noter que l’architecture technique d’une banque dépend énormément du modèle
de banque à construire. Chaque banque offrant des services différents. Tout d’abord, analysons
les différents modèles de banques existants pour se faire une idée des dispositions et de la charge
technique nécessaire pour chaque modèle.
• Banques traditionnelles
Banques classiques, comme BNP Paribas ou Deutsche Bank, avec des agences physiques, une
large gamme de services (comptes courants, crédits, placements), et une infrastructure lourde
pour gérer leurs activités.
• Banques en ligne
Banques digitales qui offrent la plupart des services d’une banque traditionnelle, mais sans
agence physique. Exemples : ING, Boursorama Banque. Elles sont plus accessibles et générale-
ment moins chères en frais, mais elles fonctionnent sur une infrastructure bancaire traditionnelle.
• Néobanques
Banques entièrement numériques, souvent sans licence bancaire propre. Elles s’appuient sur
des partenariats avec des banques traditionnelles pour proposer des services de paiement et de
compte. Exemples : N26, Revolut.
• Plateformes de paiement
Transfert instantané d’argent, principalement pour des achats en ligne ou entre utilisateurs, sans
nécessiter de compte bancaire classique. Elles offrent des services de porte-monnaie électronique
et de paiement sécurisé en ligne.
Clairement, il ne s’agit pas ici de recréer un système entier de banque traditionnel (Encore que le
côté légal/certification sera un plus grand problème que le côté technique) car ce genre de système
repose sur des bases bien trop éloignées de la portée d’un nouvel entrant. Il est ici question de
se pencher sur le cas d’une banque offrant tout d’abord des services de paiement en ligne. On se
retrouve ainsi à mi-chemin entre une Néobanque et une plateforme de paiement.
2.2 La structure de la plateforme
En se rapprochant de la structure d’une néobanque ou d’une plateforme de paiement, on adopte
un modèle dans lequel l’objectif principal de la plateforme à créer est la mise en place de services
de gestion d’argent en ligne. De ce fait, la plateforme sera liée à une banque mère traditionnelle
qui possède non seulement les moyens mais aussi les accréditations nécessaires pour gérer les fonds
de la plateforme.
Il est important de comprendre ici que d’un point de vue informatique, la plateforme met à dis-
position des utilisateurs les différentes facilités de gestion numériques de leur argent sans toutefois
gérer directement une quelconque réserve de fonds réelle. Les échanges entre les utilisateurs de la
plateforme sont gérés purement informatiquement sans déplacement réel de fonds.
4
Figure 1: Enter Caption
2.3 Étude des différents flux
Une plateforme de gestion de paiement (banque), telle que la vision actuelle du projet laisse
paraître, doit avoir un minimum de fonctionnalités sans lesquelles on ne saurait entrevoir une
présence sur le marché.
• Transfert interne de fonds
Comme vu précédemment, la gestion de transfert interne est la fonctionnalité principale à offrir.
Elle se limite aux déplacements d’informations d’un compte utilisateur à un autre.
• Transferts entre la plateforme et une banque
Bien évidemment, les utilisateurs ne fabriquent pas leurs propres fonds sur la plateforme. Ils
sont tout d’abord des personnes possédant déjà des comptes bancaires de banque traditionnelles
et désireux de bénéficier des services de ”digitalisation d’argent” que l’on offre. On pense ici au
fonctionnement de plateformes comme PayPal ou Klarna. Notre plateforme ne prend du sens
que lorsque ces utilisateurs décident de transférer leurs fonds de leurs banques traditionnelles
vers notre plateforme.
• Paiements en ligne
Pour permettre des paiements en ligne il existe à notre niveau deux options:
– Mettre à disposition des utilisateurs des cartes de débit. Cela nécessite l’utilisation de
processeurs de paiement comme Visa ou Mastercard. Les utilisateurs effectuent ainsi leurs
5
achats en entrant les données de leurs cartes et le processeur de paiement se charge des
transferts (style N26, Revolut).
– Gérer le processus de paiement soi-même. Cette option requiert la mise en place d’un
système d’API de paiement assez robuste pour obtenir la confiance des sites marchands
désireux d’intégrer des moyens de paiement (style PayPal, Klarna).
• Retrait et recharge de liquidités (à penser)
Comment permettre à un utilisateur d’injecter dans le système de l’argent liquide qu’il possède?
Les fonds ne sont gérés par la plateforme que s’ils atterrissent dans les comptes de cette dernière
domiciliés du côté de la banque mère.
6
3 Les fonctionnalités possibles à proposer
Transférer de l’argent, tel est l’objectif basique fixé. La question est de savoir ce que la banque
fera de l’argent des utilisateurs, de quelle manière va-t-elle interagir avec cet argent. Répondre à
cette question nécessite une séparation du problème en plusieurs parties.
3.1 Manipulation interne de fonds
Il s’agit ici de définir la logique utilisée pour la manipulation interne de l’argent. Comment les
fonds font-ils pour tourner entre les comptes des utilisateurs sur la plateforme ?
Figure 2: Fonctionnement d’un transfert interne à la plateforme
La forme de transfert de fonds la plus simple est celle effectuée entre deux comptes de la plateforme.
Ce transfert se réduit à un changement de valeurs dans la base de données des comptes utilisateur
concernés.
3.2 Comment les fonds entrent et sortent de la plateforme
Maintenant que nous savons basiquement comment les fonds tournent en interne, il faut se pencher
sur le sujet des points d’entrée et de sortie. Comment un utilisateur fait-il pour faire entrer ses
fonds de sa banque vers la plateforme? (L’entrée des fonds en liquidité sera étudiée dans une
section ultérieure).
7
3.2.1 Transaction entre les banques et notre plateforme
Comme déjà évoqué les fonds réels de la plateforme à créer son gardés chez une banque tradition-
nelle/mère possédant les moyens techniques et les accréditations pour cela. C’est aussi grâce à
cette banque que nous obtenons les licences nécessaires pour effectuer nos transactions.
Figure 3: Comment un de nos utilisateurs fait pour déplacer ses fonds de sa banque vers notre
plateforme
• Étape 1: Initiation de la recharge
Notre utilisateur se connecte à notre plateforme via l’app mobile, par exemple, et demande à
recharger son compte. Il a donc, au préalable (à la création du compte par exemple), lié son
compte dans notre application à son compte bancaire chez sa banque.
• Étape 2: Envoie des données à nos serveurs
Les données nécessaires à la transaction sont envoyées à nos serveurs pour le traitement et le
lancement de la procédure.
• Étape 3: Ordre de virement
Nos serveurs doivent maintenant émettre un ordre de virement à l’endroit de la banque de notre
utilisateur pour demander un déplacement de fonds. Cet ordre de virement est effectué grâce à
une requête API directement vers les serveurs de la banque de notre utilisateur ou alors par une
requête à un système d’Open Banking. Les Banque mettent généralement ces systèmes d’API
en place pour les acteurs externes et les partenaires.
8
En fonction du pays et des réglementations, l’Open Banking peut prendre différentes formes,
mais les banques soumises à ces réglementations se doivent d’implémenter les services et les
règles de sécurité demandées. En Europe, par exemple, toutes les banques (à quelques ex-
ceptions près) doivent mettre en place des systèmes respectant les directives EU 2015/2366
PSD2.[Bun] On entend par là la mise au point d’APIs ouvertes permettant l’accès aux infor-
mations des clients et même l’initiation de paiement, qui est effectivement la partie qui nous
intéresse.
Malheureusement, en Afrique, l’Open Banking en est encore à ses débuts, ce qui remet lourde-
ment en question la possibilité d’automatiser les transactions. L’étude des possibilités au niveau
de l’Afrique sera faite dans une section ultérieure.
• Étape 4: Déplacement des fonds
Une fois l’ordre de virement reçu et traité par la banque de notre utilisateur, cette banque
procède au déplacement des fonds vers nos comptes dans notre banque partenaire. À ce moment,
les fonds sont à notre disposition.
• Étape 5: Réponse à l’ordre de virement
Après le lancement de l’étape 4, la banque de notre utilisateur nous renvoie une réponse (Reponse
API) confirmant la réussite de la demande. Bien que le déplacement des fonds ne soit pas
terminé (cela peut prendre plusieurs jours), nous passons à l’étape suivante car nous avons la
confirmation que le transfert de fonds va être effectué.
• Étape 6: Réponse à l’utilisateur
Le compte de l’utilisateur est crédité dans notre base de données et il reçoit les informations
correspondantes dans son interface utilisateur.
Pour faire sortir les fonds de notre plateforme vers les banques de nos utilisateurs, une suite d’étapes
similaire est utilisée. À la différence près que les fonds au niveau des banques empruntent le chemin
inverse.
3.2.2 Paiements en ligne par carte
L’un des objectifs clés du projet est de permettre aux utilisateurs d’effectuer des paiements en ligne
grâce à leurs comptes sur notre plateforme. Traditionnellement, la méthode de carte de crédit est
utilisée (pas forcément des cartes physiques). Les utilisateurs possèderont sur notre plateforme des
cartes de crédit créées chez un processeur de paiement comme Stripe Issuing, Marqeta ou Galileo
et utilisant des opérateurs de paiement comme Visa ou Mastercard.
9
Figure 4: Processus de paiement par carte
• Étape 1: L’utilisateur entre ses informations sur un site marchant
Avant toute chose, il faut noter que notre utilisateur a généré une carte virtuelle sur notre
plateforme. Cette carte est créée chez un processeur de paiement partenaire. La carte est
enregistrée dans le réseau Visa ou Mastercard, qui garantit que chaque transaction sera reconnue
et traitée correctement. Cette carte est donc utilisée sur un site marchant.
• Étape 2: Autorisation de transaction
Le site marchant envoie en principe une demande de paiement dans un réseau Visa/Mastercard
(Vu que la carte de notre client y est enregistrée). Cette partie n’est pas gérée par nous. Nous
commençons à agir lorsque nous recevons la requête d’autorisation
• Étape 3, 4: Requête d’autorisation
À cette étape, nous recevons une requête de notre processeur de paiement (Même si pour faciliter
le schéma ne fait pas de différence entre le processeur de paiement et l’opérateur de paiement
Visa/Mastercard) nous informant qu’une transaction de fond est demandée.
Notre serveur vérifie la transaction, le solde du client et toutes les contraintes de notre plate-
forme, puis lorsque tout est bon, une réponse d’autorisation est renvoyée au processeur de
paiement.
• Étape 5, 6: Vérification par l’acquéreur
Ici, il faut effectuer une vérification du côté de la banque du marchand pour s’assurer que son
compte est prêt à recevoir les fonds. Ces étapes ne sont pas gérées par nous.
10
• Étape 7, 8: initiation et traitement du paiement
Notre processeur de paiement nous envoie la demande pour déplacer les fonds vers la destination
du marchand. Cette demande a atterri logiquement en ordre de virement chez notre banque
partenaire.
• Étape 9, 10: Transfert des fonds
Les fonds sont transférés et notre utilisateur est notifié via l’application, par exemple. Bien que
dans la réalité on n’attende pas la fin du transfert de fonds pour notifier le client. Nous mettons
juste à jour le compte du client dans nos bases de données, lui envoyons la notification.
[Pat24], [JPM24], [Cor23]
3.2.3 Fournir des APIs de paiement
Les plateformes de paiement comme PayPal, Klarna, Stripe ou autres proposent des API et des kits
de développement logiciel (SDK) aux marchands. Ces outils permettent aux développeurs des sites
e-commerce d’intégrer facilement les boutons de paiement de ces plateformes directement dans leur
site web ou leur application mobile. Il serait envisageable de créer un tel système, mais cela est
très complexe pour un nouvel entrant. Il faudra tout d’abord avoir les accréditations pour le faire
(Ce qui n’est pas facile à obtenir). Puis il faut non seulement avoir la technologie et l’architecture
adéquate, mais aussi gagner la confiance du marché pour que les vendeurs utilisent nos services
sur leurs sites et applications.[Mal24]
Cette possibilité ne sera pas plus détaillée dans cette étude.
11
4 Les possibilités es Afrique
Il convient de voir ici si les fonctionnalités citées plus haut sont implémentables en Afrique. Quels
sont les pays où nous avons le plus de moyens à notre disposition?
4.1 L’Open Banking en Afrique
Comme évoqué précédemment, l’automatisation de nos transactions passe par des systèmes d’Open
Banking, du moins c’est la méthode à utiliser si nous sommes en Europe.
En ce qui concerne l’Afrique, rares sont les pays qui disposent d’infrastructures d’Open Banking.
Les pays ayant abordé le sujet sont malheureusement encore au stade de maturation du projet.
Mais le potentiel est toutefois énorme. Nous pouvons donc, pendant la phase de maturation de
notre projet, nous préparer à l’arrivée de cette technologie.
• Afrique du Sud
En juin 2023, l’Autorité de conduite du secteur financier (FSCA) en Afrique du Sud a publié
un projet de document de position sur la finance ouverte (En Afrique du Sud, le terme Open
Finance est généralement utilisé à la place d’Open Banking). Ce document présente la position
politique proposée par la FSCA et formule des recommandations pour une gestion efficace des
risques associés. Selon la FSCA, le partage des données financières des clients avec des tiers,
sous des conditions de contrôle strictes, pourrait renforcer la valeur offerte aux clients, favoriser
l’inclusion financière et stimuler la concurrence.[Mac24]
Mais jusqu’à présent, il n’y a pas d’information claire sur les disponibilités ou les dates exactes
d’arrivée de l’Open Banking. Toutefois la FSCA a publié aussi en mars 2024 un document
presentant ses recommandations pour l’Open Finance[FSC24]. Dans ce document la FSCA
propose une approche progressive, commençant par une adoption volontaire avant de la rendre
obligatoire pour tous les acteurs de l’industrie. Dans le cas de l’Afrique du Sud, il nous faut donc
mener une étude pour déterminer les banques prêtes à implémenter un système correspondant
à nos besoins.
• Nigeria
Au Nigeria, le secteur de l’Open Banking est un peu plus abouti et la Banque centrale du
Nigeria est la première banque en Afrique à introduire un Framework de régulation qui définit
les règles de sécurité d’APIs et aussi le design technique à respecter pour l’Open Banking dans
le pays.[Mac24].
Il existe déjà plusieurs négociants au Nigeria comme Rubies Bank ou même ALAT by Wema
Bank qui est la première banque 100% digitale.
Il est donc clair que le Nigeria possède un environnement compatible avec la construction d’une
plateforme comme la nôtre.
• Cameroun
Il n’existe actuellement aucun système d’Open Banking au Cameroun. De plus, il n’a été trouvé
au moment de la réalisation de cette étude aucune note portant sur une possible réglementation
du secteur.
4.2 Peut-on faire sans l’Open Banking ?
La clé est de trouver un moyen d’automatiser les transactions déjà entre la Banque mère et notre
plateforme, puis que la Banque mère puisse effectuer des virements sur un réseau Visa ou Master-
card pour les paiements en ligne.
12
Il est techniquement possible de créer une plateforme comme la nôtre (néobanque) sans faire appel
à de l’Open Banking. Cependant, cela implique des défis considérables et limite considérable-
ment les fonctionnalités et les avantages que l’Open Banking peut offrir. Il faut donc trouver une
banque qui peut jouer le rôle de banque mère et avec laquelle on implémentera des systèmes de
communication API personnalisés. Cela se négocie donc auprès de nos banques cibles.
13
5 Architecture et technologies pour le projet
Il convient de voir ici si les fonctionnalités citées plus haut sont implémentables en Afrique. Quels
sont les pays où nous avons le plus de moyens à notre disposition?
14
6 Glossaire
• API : Application Programming Interface, un ensemble d’outils, de définitions et de pro-
tocoles qui permettent à différentes applications ou services de communiquer entre eux de
manière standardisée.
• Open Banking : Concept basé sur l’utilisation d’APIs sécurisées pour permettre aux insti-
tutions financières de partager des données avec des tiers (comme des fintechs) dans le but de
proposer des services innovants, comme l’agrégation de comptes ou des paiements simplifiés.
• SDK : Software Development Kit, un ensemble d’outils logiciels, de bibliothèques et de doc-
umentation permettant aux développeurs d’intégrer des fonctionnalités spécifiques (comme
des services de paiement) dans leurs applications.
15
7 Bibliographie
References
[Bun] Deutsche Bundesbank. Règlementation PSD2 en europe. Consulté le 11.11.2024. url:
[Link]
[Cor23] WEX Corporate. What is a virtual credit card? Consulté le 12.11.2024. Sept. 2023. url:
[Link]
[FSC24] FSCA. Open Finance - FSCA Policy Recommandations. Consulté le 12.11.2024. Mar.
2024. url: [Link]
2024%20Open%20Finance_FSCA%20Position%[Link].
[JPM24] [Link]. Understanding virtual credit cards. Consulté le 12.11.2024. Mar. 2024. url:
[Link]
virtual-credit-card-and-how-does-it-work.
[Mac24] Vlad Macovei. Insights on Open Banking Evolution in Africa – interview with De-
loitte. Consulté le 12.11.2024. Feb. 2024. url: [Link]
insights-on-open-banking-evolution-in-africa-interview-with-deloitte--
1266549.
[Mal24] Alex Malyshev. How to Create a Payment App like PayPal. Consulté le 12.11.2024.
July 2024. url: [Link]
platform.
[Pat24] Parag Patel. Everything You Need To Know About Virtual Card Payments. Consulté le
12.11.2024. Apr. 2024. url: [Link]
virtual-card-payments.
16