Introduction

Le 21 novembre 2017 était une date importante pour les paiements européens car elle marquait le lancement officiel du système SEPA Instant Credit (SCT Inst).

Je pensais que cet événement était suffisamment important pour lui consacrer deux articles :

  • Dans le premier article, je me suis concentré sur les aspects métier. J’ai présenté ce qu’est SCT Inst, pourquoi il constitue une avancée fondamentale par rapport au SCT et pourquoi je pense que ce sera un succès.
  • Dans ce second article, je vais me pencher sur ce qu’il signifie pour les banques du point de vue architectural et opérationnel.

La mise en place des paiements instantanés est complexe

Si sur le plan métier les avantages du paiement instantané sont clairs, il n’en reste pas moins que du point de vue architectural et opérationnel, la mise en place du paiement instantané constitue un défi majeur.

Avant de se lancer dans les paiements instantanés, les banques européennes qui ne l’ont pas encore fait devraient mener les deux activités suivantes :

  1. Évaluation des capacités actuelles de la plate-forme par rapport aux exigences clés SCT Inst
  2. Evaluation de leurs options (partenariats etc …)

Évaluation de votre plateforme actuelle par rapport aux exigences clés de SCT Inst

Les capacités de plate-forme existante doivent être évaluées par rapport aux nouvelles exigences des paiements instantanés. Cette évaluation doit couvrir la vision d’ensemble et évaluer les capacités de tous les composants impliqués dans le traitement de bout en bout (canaux, core banking systems, moteurs de paiement, systèmes de fraude et lutte anti-blanchiment…).

Parmi ces exigences, les exigences suivantes ressortent comme étant parmi les plus difficiles à satisfaire :

SLA de bout en bout

La tenue des SLA (Service Level Agreements / Accords sur les Niveaux de Service) relatifs aux engagements de temps de réponse du service tel que défini par le schéma SCT Inst n’est pas une mince affaire pour de nombreux systèmes existants qui n’ont jusque-là pas été architecturés selon des exigences aussi strictes.

Et pourtant, lors de la mise en œuvre de SCT Inst, les banques ne devraient se limiter à la valeur imposée par le scheme. En effet, afin de maximiser leur capacité à supporter un maximum de nouveaux produits et services, les banques devraient s’efforcer de minimiser ce temps et, plus important encore, se concentrer sur la minimisation du temps écoulé par un client de l’initiation à la confirmation.

Pour répondre à ces exigences, les applications doivent être architecturées de manière à minimiser la latence (en particulier en limitant autant que possible les accès I/O avec la base de données) et à paralléliser les étapes de traitement là où c’est possible.

Enfin, avec ces nouveaux SLAs vient le besoin d’une surveillance associée qui implique la mise en place d’outils de mesure et de tableaux de bord afin de garantir que le niveau de service convenu est réellement délivré.

Paiement unique, transactions multiples

Les plateformes de paiement de masse, même celles récemment mises en œuvre, sont souvent conçues pour les paiements groupés et le traitement par lots. En revanche, le traitement SCT Inst repose sur un processus de paiement individuel, déclenchant plusieurs transactions par paiement. En présence de volumes élevés, cela constituera généralement un défi pour les plates-formes existantes. À tout le moins, cela entraînera généralement une augmentation importante de la puissance de traitement requise, en particulier pendant les heures de pointe, par rapport aux volumes équivalents par lots.

Autorisation en temps réel à tout moment

Pour permettre à son client d’émettre des SCT Inst, la banque doit avoir la capacité d’effectuer une autorisation en temps réel n’importe quel jour et à n’importe quel moment de la journée : c’est une exigence majeure car de nombreux core banking systems ne sont pas disponibles 24/7/365. Les solutions possibles comprennent des systèmes de traitements auxiliaires (Stand-In Processing systems) et / ou des comptes miroirs pour faire face aux temps d’arrêt des core banking systems.

Fraude en temps réel

Les paiements SCT Inst constituent une plate-forme très attrayante pour les fraudeurs et les blanchisseurs d’argent (disponibilité de l’argent au bénéficiaire après seulement quelques secondes, capacité à exécuter de gros volumes de petites transactions dans un court laps de temps …).

Pour un tel instrument, l’approche largement utilisée pour le SCT (analyse Lutte Anti-Blanchiment et prévention de la fraude après traitement) ne convient pas. Les transactions potentiellement frauduleuses doivent être identifiées de manière proactive avant exécution (« before the fact ») qui nécessite une notation de fraude en temps réel.

Plusieurs CSM ont vu une opportunité dans ce défi et ont décidé d’offrir des services à valeur ajoutée dans ce domaine aux banques intéressées. Les exemples comprennent :

  • STET offre un service de scoring Fraude des paiements instantanés basé sur son système de scoring Fraude carte existant.
  • EquensWorldline fournit un filtrage LAB et conformité ainsi qu’un scoring Fraude en tant que service à valeur ajoutée de ses solutions Instant Payments Channel

Gestion de la liquidité

Avec SCT Inst, les positions de liquidité des paiements évoluent en temps réel. En conséquence, il devient obligatoire de suivre de près et en temps voulu les mouvements d’entrée et de sortie afin de s’assurer que le compte de règlement bancaire reste financé.

Notifications

Le workflow conceptuel SCT Inst ci-dessous (source EPC Rulebook ) montre le rôle des notifications dans le schema.

Comme le montre le schéma, la seule communication depuis les banques vers les clients qui est dans le périmètre du scheme est celle de l’étape 7, qui impose que la Banque du Donneur d’ordre (Originator Bank) informe immédiatement le Donneur d’ordre (Originator) dans le cas où la Banque du Donneur d’ordre reçoit une confirmation négative sur la transaction SCT Inst.

Les deux autres notifications de la banque aux clients :

  • II “Notification des fonds mis à disposition” de la Banque du bénéficiaire au Bénéficiaire
  • III “Notification des fonds mis à disposition” de la Banque du Donneur d’ordre au Donneur d’ordre

sont hors du champ d’application du scheme et sont donc laissés au choix des banques.

Je ferais cependant valoir que dans un monde numérique, la capacité d’envoyer des notifications en temps réel aux clients devrait être considérée comme un must par les deux banques bénéficiaires et donneuses d’ordre.

Exploitation 24/7/365

Le fonctionnement 24/7/365 a de nombreux impacts. Certains sont universels, d’autres spécifiques à la nature de l’entreprise.

Parmi les impacts universels :

  • Impact sur l’équipe d’exploitation (augmentation de la présence dans les jours et les heures précédemment fermés).
  • Suppression des temps d’arrêt de maintenances planifiées.
  • Besoin de procédures de récupération rapide en cas de sinistre ou de défaillance du système.

Parmi les impacts spécifiques :

  • Tout traitement de fin de journée doit être repensé.
  • Besoin d’une disponibilité accrue des centres d’appels 24 heures sur 24, 7 jours sur 7, 365 jours par an pour gérer les appels potentiels des utilisateurs, ce qui constitue une évolution majeure pour les centres d’appels qui ne fonctionnent pas encore 24 heures sur 24, 365 jours par an.
  • La gestion de la liquidité ressort à nouveau. En effet, le fonctionnement sans interruption implique des procédures spéciales pour gérer les jours et les heures de fermeture de la trésorerie et le fait que les systèmes de règlement des banques centrales ne sont actuellement pas disponibles 24/7/365.

Connectivité

La connectivité nécessite à la fois une faible latence et une haute disponibilité. Cependant, les offres existantes de SWIFT en Europe ne répondent pas à ces critères. Une solution instantanée SWIFTNET a été annoncée mais elle ne sera pas disponible avant novembre 2018. En attendant, en fonction du CSM auquel elles ont l’intention de se connecter, les banques devront se tourner vers d’autres solutions telles que la gestion de leur propre réseau ou l’utilisation de partenaires spécifiques à certains CSM tels que SIANet.

Scalabilité

Les expériences passées des systèmes de paiement instantané à l’étranger montrent que la croissance de tels systèmes peut être très rapide. En conséquence, il est important que la plateforme soit scalable dès le départ.

Évaluer vos options

Après avoir effectué cette évaluation globale, chaque banque devra décider du scénario qui lui convient le mieux.

Mise en œuvre complète autonome et opérations

Pour les banques qui souhaitent implémenter et gérer les paiements SCT Inst de manière entièrement autonome, les scénarios vont de la simple mise à niveau / réparation rapide des plates-formes existantes à la construction de nouvelles plates-formes.

Cependant, pour certaines banques – généralement les plus petites, la taille des investissements et des coûts de fonctionnement associés à des scénarios autonomes sera trop lourde à supporter, les conduisant à envisager divers types d’externalisation et de partenariats pour minimiser les impacts et les coûts. Ils devraient donc considérer les solutions SaaS (Software as a Service) / PaaS (Platform as a Service) et / ou rechercher des partenariats.

Solutions SaaS / PaaS pour les paiements

C’est un marché relativement nouveau mais dernièrement plusieurs fournisseurs de moteurs de paiement ont lancé de telles initiatives. Pour les petites banques, cela pourrait valoir la peine d’être étudié.

Partenariats

Comme indiqué dans le point de vue «Real-time payments for real-time Banking», la contrainte de temps forte imposée par les schemes de paiement en temps réel est difficile à satisfaire dans les modèles de Participant Indirect / Participant Direct traditionnels ce qui crée une opportunité pour des modèles d’accès alternatifs comme illustré ci-dessous:

Submit a Comment

Your email address will not be published. Required fields are marked *