Le Blog Amazon Web Services

Treezor : Mise en place d’une plateforme Bank-as-a-Service en utilisant les services managés AWS

Cet article a été rédigé par Nicolas Bordes, Architect Cloud chez Treezor et en collaboration avec Abderrahim Benazza, Senior Solutions Architect pour le segment Financial Services d’AWS France.

L’entreprise Treezor, Start Up/filiale du groupe Société Générale, est le leader européen du Banking As a Service en fournissant au travers d’une API un ensemble de services financiers tels que l’émission de carte bancaire, la tenue de compte, la gestion des flux SEPA permettant le développement de Fintech. Treezor accompagne plus de 100 clients dans leur projet de finance embarquée. Treezor a émit plus de 3 millions de cartes et traite plus de 40 milliards d’euros de flux par an.

Treezor a pris le virage du cloud début 2021 pour terminer la migration totale de sa plateforme en début d’année 2023. L’équipe IT a fait le choix de tout miser sur une approche Serverless et de maximiser l’utilisation des services managés AWS afin de se concentrer sur son cœur de métier en s’appuyant sur des services fiables, sécurisés et qui peuvent passer à l’échelle. Treezor a également tiré parti de la puissance du Cloud dans l’exploitation de ses données en créant un data lake basé sur Amazon S3 et Amazon Athena qui permet d’avoir une vision centralisée et consolidée des données collectées de dizaines d’applications qui composent la plateforme Treezor.

Aujourd’hui la plateforme Treezor c’est plus de 90 millions de requêtes API par mois, 3 millions d’événements envoyés par jour à ses clients via webhook et un total de plus de 500 millions d’invocations AWS Lambda mensuelles.

Challenge

Le métier de Treezor lui impose une résilience accrue en raison des contraintes réglementaires dues à son secteur d’activité d’établissement de paiement régulé par l’ACPR (Autorité de contrôle prudentiel et de résolution). De plus, les clients de Treezor attendent de la plateforme de Banking as a Service des performances constantes et une scalabilité à toute épreuve pour accompagner leur croissance.

Dans le contexte du traitement des transactions par carte bancaire, le temps de réponse pour autoriser la transaction est crucial (moins de 1500ms de bout en bout), pendant ce temps le porteur de la carte est à la caisse chez le commerçant et attend que sa transaction soit validée.

En fonction du secteur d’activité des clients, la réglementation n’est pas forcément la même et permet d’avoir plusieurs possibilités dans le traitement de ces cartes de paiement.

Prenons le cas d’une fintech qui dispose du statut d’émetteur de Titre Spéciaux de Paiement (TSP). Elle peut offrir à ses clients la capacité de pouvoir dépasser le solde journalier de paiement en titre-restaurant de 25€ (à la date de rédaction de l’article, ce montant évolue selon la réglementation en vigueur) en faisant un complément avec une carte bancaire personnelle pour pouvoir dépenser plus tout en utilisant uniquement sa carte titre-restaurant.

Pour cela pendant la phase d’autorisation de la transaction carte, la fintech est contactée par Treezor pour qu’elle puisse, si besoin, compléter le paiement en effectuant un débit sur la carte personnelle.

Une fois la réponse de la fintech obtenue, Treezor va finir ses traitements et répondre au commerçant “OK”, puis Treezor doit mettre à jour son système pour enregistrer la transaction qui vient d’être effectuée. Cet enregistrement prend du temps et Treezor a décidé de le faire de manière asynchrone. Nous parlons ici de centaines de milliers de transactions cartes reçues sur un laps de temps très court : les heures de repas le midi.

Ci-dessous le diagramme de séquence illustre le traitement d’une autorisation carte d’une transaction titre restaurant :

Solution

Afin d’être alignés avec la stratégie de Treezor dans le Cloud AWS, nous avons choisi les services AWS Lambda, Amazon SNS, Amazon SQS et Amazon Kinesis Data Firehose pour répondre à cette problématique et développer une plateforme BAAS (bank-as-a-service).

Détail des flux :

  1. Le processeur de cartes reçoit la demande d’autorisation du paiement et la transmet à la plateforme BaaS via un point de terminaisons HTTPS géré par API Gateway
  2. API Gateway va déclencher une fonction AWS Lambda en charge du traitement de la demande d’autorisation carte, elle va vérifier le format de la transaction
  3. Treezor va soumettre à son client la demande d’autorisation carte via un appel sur son API et attendre la réponse du client
  4. Treezor publie le message sur un topic SNS
  5. SNS va alors délivrer le message à deux points de terminaison
    1. SQS
    2. Kinesis Firehose
  6. SQS va alors invoquer notre fonction lambda en charge de la persistance de la transaction. Treezor s’appuie sur lacapacité de SQS à invoquer AWS Lambda tout en contrôlant le batch size et max concurency afin de gérer la pression sur la base de donnée
  7. La Lambda métier va alors persister la transaction dans la base de données sur Amazon RDS
  8. AWS Database Migration Service (DMS) va alors être notifié d’un changement dans la base de données Amazon RDS, étant configuré en mode CDC il voit passer toutes les écritures / modification des différentes bases
  9. DMS va délivrer sur S3 un fichier parquet contenant les modifications survenues durant une fenêtre de temps
  10. Dans le même temps des points 6,7,8 et 9, Firehose à quand a lui délivrer la donnée en JSON envoyé à SNS sur le même bucket S3 dans un chemin différent, ces données seront utilisées à l’étape 11
  11. Treezor utilise Athena pour croiser les informations envoyées à SNS avec les données réellement écrite dans la base de données afin de s’assurer de la cohérence des informations.

Treezor dispose ainsi d’un système résilient, scalable, avec une capacité de monitoring avancé.

Conclusion

Cette architecture a permis à Treezor d’améliorer grandement sa façon de traiter les événements asynchrones et ceux dans un contexte de contrainte métier et réglementaire fortes dans un volume de transaction variable.

  • Treezor est passé d’un temps de traitement de la persistance des autorisations cartes pouvant atteindre 3h à moins de 500ms
  • Treezor a augmenté sa capacité de rejeu en cas de problème car tous les messages bruts sont disponibles sur S3 et peuvent être rejoués au besoin
  • Treezor dispose d’un outil de contrôle de la cohérence métier en agrégeant plusieurs sources dans son Datalake piloté par Athena
  • Treezor a renforcé sa capacité de supervision de ses processus asynchrones

La stratégie du serverless et des services mangés AWS s’avère être gagnante, car Treezor arrive à faire tourner “une banque dans une fonction lambda”.

PS: Pour en savoir plus, écoutez l’épisode du podcast AWS en français consacré à treezor.