Open Banking aux EAU : ce que les plateformes de paiement doivent préparer

La Banque Centrale des EAU (CBUAE) fait progresser son cadre Open Finance dans le cadre du Programme de Transformation de l'Infrastructure Financière des EAU. Pour les passerelles de paiement, les plateformes de portefeuille et les opérateurs fintech agréés aux EAU, il ne s'agit pas d'une considération réglementaire lointaine - c'est une échéance d'ingénierie.

Ce qu'exige le cadre Open Finance

L'Open Finance aux EAU suit le schéma établi par la DSP2 en Europe et l'Open Banking au Royaume-Uni, adapté au contexte réglementaire et de marché des EAU. Dans son essence, il exige que les entités financières agréées exposent des APIs réglementées permettant aux prestataires tiers (TPP) d'accéder aux données de compte et d'initier des paiements au nom des clients, avec leur consentement.

Les catégories d'API clés :

• Services d'Information sur les Comptes (AIS) : accès en lecture aux soldes de compte, à l'historique des transactions et aux métadonnées de compte
• Services d'Initiation de Paiement (SIP) : initiation de paiements depuis les comptes clients par des TPP autorisés
• Confirmation de Disponibilité de Fonds (CDF) : vérification booléenne de l'existence de fonds suffisants sans exposer la valeur du solde

Chaque catégorie présente des exigences de consentement, d'authentification et de format de données spécifiées dans les normes techniques réglementaires.

Voir aussi : Construire des APIs de paiement idempotentes

Architecture d'authentification et de consentement

Le modèle de consentement est l'exigence la plus significative architecturalement. Les clients doivent explicitement autoriser chaque TPP à accéder à des données spécifiques ou à initier des paiements, avec une portée définie et une expiration définie. Ce consentement doit être révocable à tout moment, et la plateforme doit appliquer la révocation immédiatement - pas au prochain appel API ou à la prochaine connexion.

Cela nécessite :

• Un service de gestion du consentement qui stocke les octrois de consentement avec leur portée, leur expiration et l'identifiant TPP
• Un serveur d'autorisation implémentant OAuth 2.0 avec PKCE et OpenID Connect
• L'introspection de token ou des tokens d'accès de courte durée validés contre le store de consentement à chaque appel API
• Un endpoint de révocation qui invalide immédiatement tous les tokens associés à un octroi de consentement

Si votre plateforme implémente actuellement un modèle simple de clé API, la migration vers cette architecture est un projet significatif - non pas parce qu'un composant individuel est complexe, mais parce qu'elle touche l'authentification sur toute votre surface API.

Conception d'API pour la conformité réglementaire

Les spécifications d'API pour l'Open Finance des EAU sont définies par la CBUAE et référenceront des normes du Berlin Group ou de l'UK Open Banking Implementation Entity (OBIE) avec des adaptations spécifiques aux EAU. Les implications clés pour l'ingénierie :

• Formats de données : les spécifications réglementaires définissent des schémas JSON spécifiques pour les données de compte, les données de transaction et les réponses d'erreur. Vos modèles de données internes peuvent ne pas correspondre proprement à ces schémas.
• Idempotence : les endpoints d'initiation de paiement doivent être idempotents. Un TPP qui réessaie une requête d'initiation échouée ne doit pas créer un paiement en doublon.
• Limitation de débit : vous devrez appliquer une limitation de débit par TPP et par consentement client, pas seulement par clé API.
• Journalisation d'audit : chaque appel API doit être journalisé avec l'identité du TPP, la référence de consentement, les données accédées ou l'action entreprise, et l'horodatage. Les régulateurs peuvent demander ces journaux.

Voir aussi : L'observabilité pour les systèmes critiques de transaction

Considérations d'infrastructure

Les endpoints d'API réglementaires ont souvent des SLA de disponibilité plus stricts que vos APIs commerciales. Les régulateurs peuvent spécifier des exigences de disponibilité (99,5 %+ est courant) avec des rapports structurés sur les incidents d'indisponibilité.

Cela signifie que votre infrastructure d'API open banking devrait être isolée de votre infrastructure de traitement des transactions commerciales - à la fois pour protéger le SLA et pour éviter qu'un pic de trafic commercial ne dégrade votre API réglementée. Passerelle API séparée, calcul séparé, surveillance séparée et chemin d'escalade d'astreinte séparé.

Ce qu'il faut construire maintenant

L'écart entre une plateforme de paiement typique des EAU et la préparation à l'open banking représente généralement 6 à 12 mois de travail d'ingénierie, selon l'architecture actuelle. Les équipes qui commencent tôt ont le temps de le faire correctement ; celles qui commencent tard sont contraintes de prendre des décisions expéditives qui accumulent une dette de conformité.

Ordre de priorité pour la préparation :

1. Service de gestion du consentement - c'est le fondement architectural de tout le reste
2. Serveur d'autorisation OAuth 2.0 / OIDC - évaluez si construire, acheter ou utiliser un service géré
3. Passerelle API capable de limitation de débit par TPP et de validation de token
4. Infrastructure de journalisation d'audit avec les schémas de rétention et d'accès exigés par les régulateurs
5. APIs de données de compte et de transaction avec des schémas conformes à la CBUAE

Voir aussi : Les erreurs d'architecture les plus courantes dans les passerelles de paiement

---

Si votre plateforme est agréée aux EAU et que vous n'avez pas cartographié l'écart d'ingénierie vers la conformité Open Finance, une évaluation de plateforme vous donnera une vision claire de ce qui doit être construit et un calendrier réaliste.