RBAC C'est là que la passerelle commence à s'amortir. Dans une plateforme bancaire multi-locataires, l’accès ne peut pas être illimité simplement parce que l’agent est “ interne ”. Chaque locataire a besoin de sa propre matrice d’autorisations. Un commerçant qui utilise uniquement l’initiation de paiement ne devrait pas avoir accès aux outils KYC. Un agent du service client d’une région ne devrait pas avoir accès aux contrôles de cartes d’une autre région. Un workflow qui nécessite uniquement l’explication du solde ne devrait pas avoir accès à la préparation des virements.
Validation du schéma est le filtre suivant. La passerelle doit valider chaque requête par rapport aux spécifications OpenAPI approuvées ou à des contrats équivalents. Cela permet de détecter les charges utiles incorrectes : format de devise erroné, identifiant du bénéficiaire manquant, canal de paiement non pris en charge, plage de dates impossible, requête de statut KYC mal formée. Le modèle peut être « éloquent » tout en produisant une charge utile que le système doit rejeter.
Processus de validation C'est là que le modèle sans garde prend tout son sens. L'agent peut préparer une action, mais les opérations à haut risque doivent passer par une file d'attente, notamment en cas de seuils de montant, de nouveaux bénéficiaires, d'état suspect d'un compte, de procédure KYC incomplète, de signaux de fraude élevés ou de politiques spécifiques au locataire. La passerelle doit créer l’élément d’approbation, notifier l’approbateur, suivre les règles de délai d’expiration et renvoyer un statut clair à l’utilisateur ou à l’opérateur.
Journalisation des audits doit être intégré dès la conception du parcours. Pour chaque requête, la passerelle doit créer un enregistrement à ajout uniquement. Cet enregistrement doit inclure le locataire, l’utilisateur, le canal, l’état du workflow, l’outil, les paramètres après expurgation, le résultat de la validation, l’état d’approbation, la réponse en aval et l’identifiant de corrélation. Les équipes chargées de la conformité n’ont pas besoin d’un compte rendu soigné. Elles ont besoin d’une trace claire expliquant pourquoi le système a autorisé ou bloqué l’action.
Une distinction qu’il convient d’établir dès le départ : le journal prouve ce qui a été exécuté, et non qui avait la qualité pour le faire. Une trace peut parfaitement montrer qu’un transfert a été effectué de A vers B sous un jeton donné. Elle ne peut pas montrer, à elle seule, que l’action a été autorisée par un mandant reconnu par les deux parties, ni que l’autorisation n’avait pas déjà été révoquée. Dans un flux à locataire unique, cette lacune est invisible, car le journal et les enregistrements d’autorité se trouvent au même endroit. Dès qu’un litige implique un locataire ou une contrepartie, cette lacune devient le cœur du problème. L’enregistrement doit donc consigner la légitimité : quel mandat a autorisé l’appel, dans quel cadre, et s’il était toujours valide à ce moment-là. Je développe ce point dans mon article Un mandat n'est pas synonyme de gouvernance.
Disjoncteurs C'est un problème, car les prestataires bancaires présentent des défaillances courantes telles que les délais d'expiration, les pannes partielles, les réponses lentes, les statuts obsolètes et les limitations de débit. La passerelle doit détecter ce type de comportement, effectuer une nouvelle tentative avec un délai d'attente lorsque cela est sans risque, interrompre les appels répétés lorsque ce n'est pas le cas, et proposer une alternative utile à l'utilisateur. Le message “ Fournisseur AML indisponible, veuillez réessayer plus tard ” est préférable à laisser l’agent tourner en boucle, inventer un statut ou continuer à solliciter sans relâche un service dégradé.
Portée des jetons limite l'ampleur des répercussions. L'appel d'un outil doit bénéficier du niveau d'accès minimal nécessaire pour cette requête spécifique, ce locataire, cet utilisateur et cet état du flux de travail. Les jetons à durée de vie limitée et à portée restreinte sont bien plus sûrs que les identifiants de service à longue durée de vie qui circulent au niveau de la couche agent. En cas de problème, l'impact de la requête ayant échoué doit rester limité.
Nous recruter
À propos