Intégration du système bancaire central à goAML : options API, SFTP et CSV
Comment intégrer les systèmes bancaires centraux (T24, Finacle, FlexCube) à une plateforme de déclaration goAML par API REST, transfert de fichiers SFTP ou import CSV. Guide de correspondance des champs inclus.
Toute plateforme de déclaration goAML de lutte contre le blanchiment de capitaux et le financement du terrorisme (LBC/FT) ne vaut que ce que valent les données qui l'alimentent. Le moteur de génération XML le plus sophistiqué, le modèle de notation des risques le plus finement calibré et le workflow de conformité le mieux conçu sont tous compromis si les données de transactions sous-jacentes sont incomplètes, mal formatées ou ressaisies manuellement à partir d'un rapport du système bancaire central (core banking) par un analyste conformité qui a mal lu un champ de date.
L'intégration entre le système bancaire central d'une banque et sa plateforme de déclaration LBC/FT est la décision technique la plus lourde de conséquences de toute la mise en œuvre. Réussie, elle permet à la fonction conformité de travailler sur des données de transactions exactes, complètes et à jour, avec un minimum d'interventions manuelles. Ratée, elle contraint l'équipe de conformité à consacrer autant de temps à valider la qualité des données qu'à l'analyse de conformité proprement dite.
La bonne nouvelle, c'est que les trois méthodes d'intégration disponibles — API REST, transfert de fichiers SFTP et import CSV/Excel — couvrent tout l'éventail des capacités techniques des institutions financières d'Afrique de l'Est, des banques nativement numériques dotées de systèmes bancaires centraux cloud natifs aux institutions de proximité équipées de plateformes anciennes et d'une infrastructure informatique limitée.
Pourquoi l'intégration compte pour la conformité goAML
GIGO : données erronées en entrée, XML erroné en sortie
Le schéma XSD goAML est strict. Chaque document XML transmis est validé par rapport au schéma et aux règles métier propres à chaque pays. Un montant stocké dans le système bancaire central sous forme de chaîne avec séparateur de milliers (« 1,250,000 ») doit être transformé en valeur décimale à exactement deux décimales (« 1250000.00 »). Une date stockée au format DD/MM/YYYY doit devenir YYYY-MM-DD. Un type de transaction stocké sous forme de code numérique (« 01 » pour un dépôt en espèces) doit être mis en correspondance avec la valeur d'énumération goAML (« CASH_DEPOSIT »).
Si ces transformations ne se font pas automatiquement dans une couche d'intégration bien conçue, elles doivent se faire manuellement — et la préparation manuelle des données est à l'origine de la plupart des erreurs de transmission goAML. Même des responsables de la conformité très compétents commettent des erreurs de transcription lorsqu'ils convertissent manuellement des données d'un format à l'autre sous la pression des délais.
Une couche d'intégration robuste effectue toutes les transformations de manière automatique et systématique. Elle impose la qualité des données au point d'ingestion, avant que les données n'entrent dans le workflow de conformité, tandis que l'attention de l'équipe de conformité se porte sur l'analyse plutôt que sur le nettoyage des données.
La ressaisie manuelle est à l'origine de la plupart des erreurs goAML
Dans les banques dépourvues d'intégration automatisée avec le système bancaire central, le processus type est le suivant : l'équipe informatique exécute un rapport de transactions dans le système bancaire central et le livre sous forme de fichier Excel ; l'analyste conformité exporte les données pertinentes, fait correspondre manuellement les champs à la structure XML goAML, remplit un modèle goAML et effectue la transmission. Chaque étape manuelle crée des occasions d'erreur.
Parmi les erreurs les plus courantes dues à la ressaisie manuelle figurent : les inversions de format de date (le 6 mars saisi comme le 3 juin), les erreurs de position de la virgule décimale (125 000 KES saisis comme 12 500 KES ou 1 250 000 KES), la troncature des champs de nom, l'inversion de chiffres dans les numéros de compte et les incohérences de codes devises. Chacune de ces erreurs fait échouer le XML transmis soit à la validation du schéma, soit à la validation des règles métier sur le portail de la cellule de renseignement financier (CRF).
L'intégration supprime l'étape de transcription humaine
Une intégration directe entre le système bancaire central et la plateforme LBC/FT signifie que les données de transactions circulent par voie électronique, avec des règles de transformation définies, appliquées de manière programmatique et cohérente. L'analyste conformité ne touche jamais aux données de transactions brutes — il travaille sur des données de dossier prévalidées et préformatées, dans une interface structurée. Son temps est consacré à l'analyse et au jugement, et non à la préparation des données.
Méthode d'intégration 1 : API REST
Fonctionnement
L'intégration par API REST permet à la plateforme LBC/FT de demander des données de transactions à la couche API du système bancaire central, de manière planifiée ou déclenchée par des événements. La plateforme LBC/FT s'authentifie auprès de l'API du système bancaire central, demande les transactions répondant à des critères précis (période, type de transaction, seuil de montant), reçoit la réponse au format JSON ou XML et fait correspondre les champs de la réponse au modèle de données interne de la plateforme LBC/FT.
Cette méthode permet un accès aux données en temps réel comme en quasi temps réel. Pour la génération d'alertes de STR — lorsqu'un schéma de transactions suspect doit être signalé à un responsable de la conformité le plus rapidement possible après sa survenue —, une interrogation de l'API en quasi temps réel toutes les 15 à 60 minutes fournit les données les plus récentes.
Pour la surveillance du seuil des CTR, l'ingestion par API permet une détection en quasi temps réel, transaction par transaction, au regard du seuil équivalant à 15 000 USD, de sorte que les transactions concernées peuvent être signalées pour la création d'un dossier de CTR dans le délai de déclaration fixé au vendredi de la semaine.
Systèmes bancaires centraux dotés d'API REST en Afrique de l'Est
Temenos T24 R20+ comprend le composant T24 API Server, qui expose des requêtes (enquiries) basées sur TAFJ sous forme de points de terminaison RESTful. La récupération des données de transactions nécessite, dans T24, une définition d'enquiry précisant les champs et les critères de filtrage, exposée par l'API Server. T24 API Server prend en charge l'authentification OAuth 2.0 par identifiants client (client credentials).
Infosys Finacle 10 et 11 comprennent le Finacle Connect API Gateway, qui fournit des points de terminaison REST pour les données de comptes, de clients et de transactions. Le cadre d'API de Finacle prend en charge à la fois les requêtes synchrones et la notification asynchrone des événements de transaction par webhook.
Oracle FlexCube (FCUBS 12+) fournit une couche de services RESTful au moyen de son Service Framework. Les services REST de FlexCube nécessitent les configurations d'orchestration de services appropriées et prennent en charge l'authentification OAuth 2.0 par jeton porteur (bearer token).
Mambu est nativement API-first. La Mambu Core Banking Platform expose une API REST complète, sans configuration supplémentaire. Les données de transactions sont disponibles au moyen des points de terminaison Loans, Savings et Current Account, avec de nombreuses options de filtrage et de pagination.
Authentification
L'intégration par API s'authentifie soit au moyen du flux OAuth 2.0 client credentials (recommandé pour l'intégration de serveur à serveur), soit par clé d'API. La plateforme LBC/FT stocke les identifiants dans un coffre de secrets chiffré et les présente à chaque requête. Toutes les communications API s'effectuent en HTTPS/TLS 1.2 ou version supérieure.
Cas d'usage recommandés
L'intégration par API REST est la méthode à privilégier pour :
- La génération d'alertes de STR en temps réel ou en quasi temps réel à partir de la surveillance des transactions
- La détection transaction par transaction du seuil des CTR, au regard de l'équivalent de 15 000 USD, avec conversion des devises en temps réel
- L'enrichissement des données KYC (connaissance du client) des clients (date d'ouverture du compte, profession déclarée, classification des risques)
- Les données de transactions de mobile money issues de l'API Daraja ou de l'API Airtel Money
Description de l'architecture d'intégration
Le service d'ingestion de données de la plateforme LBC/FT exécute une tâche planifiée qui interroge l'API du système bancaire central à un intervalle configurable. Le service s'authentifie, demande les transactions postérieures à l'horodatage de la dernière interrogation réussie, fait correspondre les champs de la réponse au modèle de transaction interne (en appliquant la normalisation des dates, le formatage des montants, le transcodage et le rapprochement des entités) et écrit les enregistrements normalisés dans la base des transactions. Les appels d'API ayant échoué sont relancés avec une temporisation exponentielle (exponential backoff) et journalisés avec l'intégralité du contexte d'erreur, pour assurer la visibilité de l'équipe d'exploitation.
Méthode d'intégration 2 : transfert de fichiers SFTP
Fonctionnement
L'intégration SFTP repose sur des transferts de fichiers planifiés du système bancaire central vers un serveur SFTP partagé. Le traitement par lots du système bancaire central (généralement configuré dans le cadre du traitement de fin de journée) génère un fichier d'extraction des transactions dans un format défini — CSV, délimité par des barres verticales ou à largeur fixe — et le dépose dans un répertoire SFTP désigné. Le service d'ingestion de la plateforme LBC/FT surveille le répertoire SFTP, détecte les nouveaux fichiers, les télécharge et les traite, puis les déplace vers un répertoire d'archivage une fois le traitement réussi.
Il s'agit d'un modèle bien établi et largement pris en charge, qui ne requiert aucune modification du système bancaire central hormis la configuration d'un rapport d'extraction et d'une tâche SFTP. La plupart des systèmes bancaires centraux déployés en Afrique de l'Est disposent d'une capacité d'export SFTP dans leur installation standard.
Formats de fichiers pris en charge
Le CSV (valeurs séparées par des virgules) est le format le plus courant pour les extractions T24 et Finacle. Les en-têtes de colonnes de la première ligne définissent la correspondance des champs. La configuration d'ingestion de la plateforme LBC/FT fait correspondre les noms de colonnes CSV aux champs du modèle de données interne et applique les règles de transformation.
Les fichiers délimités par des barres verticales sont courants dans les exports T24 COB (Close of Business), en particulier dans les installations T24 anciennes. Le caractère barre verticale (|) utilisé comme délimiteur évite toute ambiguïté avec les virgules susceptibles de figurer dans des champs texte comme les libellés de transactions.
Les fichiers à largeur fixe se rencontrent dans les installations FlexCube anciennes, où chaque champ occupe un nombre défini de positions de caractères. Le traitement des fichiers à largeur fixe nécessite une spécification de la disposition des champs (quelles positions de caractères correspondent à quel champ), documentée dans la configuration d'extraction du système bancaire central.
Planification et calendrier
L'intégration SFTP fonctionne par nature par lots. Le calendrier standard est une extraction de fin de journée couvrant toutes les transactions depuis l'extraction précédente. Pour la surveillance du seuil des CTR, le traitement par lots de fin de journée est faisable, mais serré : avec un délai de déclaration fixé au vendredi de la semaine, une transaction du lundi doit être détectée, examinée, approuvée et transmise en quatre jours ouvrables, et une transaction du jeudi en un seul. Le SFTP de fin de journée est acceptable pour les institutions dotées de processus de conformité matures, mais plusieurs extractions intrajournalières — ou le passage à une ingestion par API — réduisent sensiblement le risque de délais manqués.
Pour les institutions qui ont besoin d'une détection intrajournalière des seuils (afin d'identifier les transactions en espèces égales ou supérieures à l'équivalent de 15 000 USD dès leur comptabilisation), une extraction intrajournalière supplémentaire peut être configurée, généralement à la mi-journée. Certains systèmes bancaires centraux prennent en charge des extractions déclenchées à des intervalles intrajournaliers configurables.
La méthode la plus répandue pour T24 et Finacle
L'extraction SFTP est de loin la méthode d'intégration la plus déployée dans le secteur bancaire d'Afrique de l'Est. Ses atouts sont la simplicité, l'universalité (tous les systèmes bancaires centraux la prennent en charge), l'absence totale de dépendance à la disponibilité de la couche API du système bancaire central, et la maturité des outils disponibles pour la surveillance et le traitement SFTP.
Les institutions qui n'ont pas immédiatement accès aux ressources de configuration de T24 API Server, ou dont le Finacle Connect Gateway ne fait pas encore l'objet d'une licence, peuvent mettre en œuvre l'intégration SFTP avec une configuration de rapport standard et un identifiant SFTP — des tâches à la portée de la plupart des équipes d'exploitation informatique, sans ressources de développement spécialisées.
Sécurité : protocole SFTP, authentification par clé, fichiers chiffrés
Le SFTP (SSH File Transfer Protocol) assure un chiffrement robuste au niveau de la couche transport, contrairement au FTP classique, qui transmet les données en clair. L'authentification par clé SSH élimine les risques de sécurité liés aux mots de passe. Les fichiers d'extraction de transactions contenant des données clients doivent en outre être chiffrés au repos, au moyen de PGP ou d'un chiffrement AES-256, avant leur dépôt sur le serveur SFTP, puis déchiffrés par la plateforme LBC/FT après téléchargement. Cette sécurité en couches garantit que, même si les identifiants SFTP sont compromis, les fichiers de données de transactions ne sont pas lisibles sans la clé de déchiffrement.
Méthode d'intégration 3 : import CSV/Excel
Cas d'usage
L'import manuel CSV/Excel est proposé comme méthode d'intégration de repli pour les institutions qui ne disposent pas de l'infrastructure ou des ressources informatiques nécessaires à une intégration automatisée par API ou SFTP. Cela concerne en particulier les petites SACCO (coopératives d'épargne et de crédit), les institutions de microfinance de niveau 3 et les banques communautaires, qui ne disposent pas toujours d'un personnel dédié à l'exploitation informatique.
Le responsable de la conformité (ou un membre désigné du personnel informatique) exporte un rapport de transactions depuis le système bancaire central, le télécharge au format CSV ou Excel et le téléverse dans la plateforme LBC/FT au moyen de l'interface d'import. La plateforme valide la structure du fichier, fait correspondre les colonnes au modèle de données, signale les problèmes de qualité des données pour examen et charge les transactions dans le workflow de conformité.
Format du modèle standard
La plateforme LBC/FT fournit un modèle d'import téléchargeable au format Excel, qui prédéfinit la structure de colonnes requise, les formats de données acceptables pour chaque champ et les règles de validation. Les institutions qui utilisent des exports CSV personnalisés de leur système bancaire central s'appuient sur la configuration de correspondance des colonnes pour définir quelle colonne de leur export correspond à quel champ du modèle. Cette correspondance est configurée une fois pour toutes et enregistrée : les imports suivants ne nécessitent plus que l'étape de téléversement du fichier.
Validation des données à l'import
Le pipeline d'import applique les mêmes validations de qualité des données que les pipelines d'ingestion automatisés :
- Validation et normalisation du format des dates
- Validation du format des montants (numérique, deux décimales)
- Détection des transactions en double (les transactions déjà présentes dans le système sont signalées et ignorées)
- Contrôles de présence des champs obligatoires
- Validation du format des numéros de compte
- Contrôles des champs d'identité des clients
Les erreurs de validation s'affichent dans un rapport de synthèse que l'opérateur examine avant de confirmer l'import. Les enregistrements comportant des erreurs non critiques peuvent être importés avec des signalements pour examen manuel ; les enregistrements comportant des erreurs critiques sont exclus et doivent être corrigés dans les données sources, puis téléversés à nouveau.
Limites
L'import manuel CSV/Excel présente deux limites importantes par rapport à l'intégration automatisée :
Premièrement, il est déclenché manuellement. Un responsable de la conformité doit penser à effectuer l'import selon le bon calendrier. Des imports oubliés créent des lacunes dans les données de transactions qui alimentent la surveillance des seuils et la notation des risques, ce qui peut entraîner des CTR manquées.
Deuxièmement, la piste d'audit relative à l'origine des données est moins complète. Les intégrations automatisées enregistrent, pour chaque enregistrement ingéré, le système source précis, l'horodatage de l'export et la méthode de transfert. Les imports manuels n'enregistrent que le nom du fichier, l'horodatage du téléversement et l'utilisateur qui l'a effectué — des informations qui peuvent se révéler insuffisantes pour retracer la provenance des données lors d'une enquête.
Pour ces raisons, l'import CSV/Excel doit être considéré comme une méthode transitoire pendant la mise en œuvre de l'intégration automatisée, et non comme une architecture d'intégration permanente pour les institutions soumises à des obligations de déclaration importantes.
Intégration des données de mobile money
API M-PESA Daraja
L'API Daraja de M-PESA (la plateforme d'API pour développeurs de Safaricom) donne aux entreprises enregistrées accès aux données de transactions M-PESA. Pour les banques disposant d'intégrations M-PESA Pay Bill ou Buy Goods, l'API Daraja C2B (Customer to Business) transmet des notifications de transactions en temps réel, sous forme de rappels HTTP (callbacks), lorsqu'un client effectue un paiement.
Pour la surveillance des seuils à des fins de LBC/FT, les points de terminaison Daraja pertinents sont :
- API C2B : reçoit en temps réel les notifications des paiements M-PESA effectués vers le numéro Pay Bill de la banque
- API Account Balance : interroge le solde actuel d'un short code Pay Bill donné
- API Transaction Status : interroge le statut d'une transaction M-PESA donnée à partir de son identifiant de transaction unique
L'API Daraja utilise une authentification OAuth 2.0 par clé et secret consommateur (consumer key/secret). La plateforme LBC/FT s'enregistre comme URL de rappel C2B pour recevoir les notifications de paiement en temps réel, normalise les données de transactions M-PESA (MSISDN, montant, identifiant de transaction, horodatage, référence de compte) selon le modèle de transaction interne et les intègre au même pipeline de surveillance des seuils que les transactions en agence et aux distributeurs automatiques (ATM).
API Airtel Money
L'API d'Airtel Money offre des fonctionnalités similaires à celles de M-PESA Daraja pour les banques disposant d'intégrations marchandes Airtel Money. Le modèle d'authentification et le mécanisme de rappel sont comparables, avec des conventions de nommage des champs propres à Airtel, qu'il faut faire correspondre au modèle de données normalisé de la plateforme LBC/FT.
T-Kash (Telkom Kenya)
T-Kash offre un accès API pour développeurs destiné aux intégrations professionnelles, même si sa part de marché est nettement inférieure à celle de M-PESA. Les banques disposant de comptes marchands T-Kash peuvent intégrer les données de transactions T-Kash au moyen de sa couche d'API professionnelle.
Surveillance multicanal pour la détection des CTR et des STR
L'exigence essentielle de l'intégration du mobile money est que les transactions M-PESA soient évaluées dans le même pipeline de détection que les transactions en espèces en agence, les retraits aux distributeurs automatiques et tout autre canal par lequel transitent les fonds des clients. Les transactions en espèces en agence et aux distributeurs automatiques sont testées individuellement au regard du seuil des CTR, équivalant à 15 000 USD ; pour le mobile money, appliquez le traitement que vous avez confirmé avec le FRC (Financial Reporting Centre, la CRF du Kenya), car ni le POCAMLA, ni les Regulations de 2023, ni la circulaire n° 4 de 2023 du FRC ne traitent de cette question. En parallèle, l'activité inférieure au seuil sur l'ensemble des canaux alimente la surveillance des schémas de fractionnement, qui donne lieu aux dossiers de STR. Ces deux voies nécessitent une couche d'identité client unifiée, qui relie le MSISDN M-PESA du client à son identifiant client et à son numéro de compte dans le système bancaire central.
Le rapprochement des identités est l'élément techniquement délicat : le compte M-PESA d'un client est identifié par son numéro de téléphone mobile, tandis que son compte dans le système bancaire central est identifié par un numéro de compte et un identifiant client. La plateforme LBC/FT tient une table de correspondance des clients qui associe les MSISDN aux identifiants clients, alimentée à partir des dossiers KYC de la banque. Cette table de correspondance permet une résolution cohérente de l'identité des clients sur l'ensemble des canaux de transaction.
Correspondance des données — des champs du système bancaire central au schéma goAML
Le tableau suivant présente la correspondance entre les champs de l'extraction de transactions standard de Temenos T24 et les éléments XML goAML, avec la transformation requise pour chaque champ.
| Champ du système bancaire central (T24) | Élément XML goAML | Transformation requise |
|---|---|---|
| TRANS.DATE (format : YYYY-MM-DD) | transaction.date_transaction | Aucune — déjà au format ISO 8601 |
| TRANS.AMT (chaîne, pouvant contenir des virgules) | currency_amount.amount | Supprimer les virgules, convertir en décimal, formater à 2 décimales |
| TRANS.CCY (code ISO à 3 caractères) | currency_amount.currency_code | Aucune |
| DEBIT.ACCT.NO | from_account.account.account_number | Supprimer les zéros initiaux le cas échéant |
| CREDIT.ACCT.NO | to_account.account.account_number | Supprimer les zéros initiaux le cas échéant |
| TRANS.CODE (numérique, par ex. 01) | transaction.transaction_type | Faire correspondre à l'énumération goAML via une table de codes |
| CUSTOMER.1 (nom complet du client) | from_person.first_name + last_name | Décomposer en prénom et nom selon une logique de séparation des noms |
| ID.DOCUMENT (numéro d'identité nationale) | id_number | Valider le format (8 chiffres pour le National ID kényan) |
| CHANNEL.CODE | transaction_type | Faire correspondre à MOBILE_WALLET_MPESA, CASH, etc. |
| BRANCH.CODE | transaction_location | Faire correspondre au nom de l'agence à partir du registre des agences |
Aucune modification requise de votre système bancaire central
Une préoccupation revient fréquemment dans les discussions sur l'intégration LBC/FT : celle de la modification du système bancaire central. Les banques se montrent à juste titre prudentes à l'égard de toute modification de leur système bancaire central — c'est le système le plus critique de l'institution, les modifications exigent des tests approfondis et l'approbation de l'éditeur peut être requise.
L'intégration de la plateforme LBC/FT est conçue pour fonctionner entièrement en lecture seule. La plateforme LBC/FT interroge les données de transactions, mais n'écrit jamais dans le système bancaire central. Aucune procédure stockée, aucun déclencheur ni aucune modification de schéma n'est requis dans la base de données du système bancaire central. Aucun agent ni processus d'arrière-plan n'est installé sur les serveurs du système bancaire central. L'intégration est un flux de données à sens unique : du système bancaire central vers la plateforme LBC/FT.
Pour l'intégration par API, l'API Server du système bancaire central est un composant distinct de l'application bancaire centrale elle-même — appeler l'API ne modifie pas l'application bancaire centrale et ne lui fait courir aucun risque. Pour l'intégration par SFTP, le système bancaire central produit un fichier de rapport dans le cadre de son traitement par lots existant — une capacité de reporting standard qui n'ajoute qu'une charge négligeable.
Une approche indépendante des éditeurs
La couche d'ingestion de la plateforme LBC/FT est conçue pour s'adapter au format et à la structure de données propres à n'importe quel système bancaire central, sans nécessiter l'intervention de l'éditeur du système bancaire central. L'intégration est configurée par l'équipe informatique de la banque au moyen de définitions de correspondance des champs et de règles de transformation gérées dans la configuration de la plateforme LBC/FT — et non dans le système bancaire central.
Grâce à cette approche indépendante des éditeurs, si la banque change de système bancaire central, la configuration d'intégration est mise à jour dans la plateforme LBC/FT, et non reconstruite de zéro. La fonction conformité reste opérationnelle pendant les migrations du système bancaire central.
Calendrier de mise en œuvre
L'intégration du système bancaire central est généralement réalisée en 1 à 2 semaines, dans le cadre d'une mise en œuvre standard de la plateforme LBC/FT de 6 à 8 semaines. La phase de configuration de l'intégration requiert la participation de l'équipe informatique de la banque chargée du système bancaire central (pour confirmer les noms de champs, les formats et les modalités d'accès SFTP ou API) et s'achève généralement dans les quelques jours qui suivent le lancement. Le reste de la période de mise en œuvre est consacré aux tests, à la validation de la qualité des données, à la formation de l'équipe de conformité et à la configuration du portail de la CRF.
Passer à l'étape suivante
La plateforme de déclaration LBC/FT goAML de Creodata comprend une couche d'ingestion de données flexible, qui prend en charge l'API REST, le SFTP et l'import CSV/Excel pour tous les principaux systèmes bancaires centraux d'Afrique de l'Est. Notre équipe d'intégration a réalisé des intégrations avec Temenos T24, Infosys Finacle, Oracle FlexCube, Mambu et de multiples configurations M-PESA et Airtel Money — avec des bibliothèques de correspondance des champs documentées pour chacun.
Échangez avec notre équipe sur vos besoins d'intégration avec votre système bancaire central : Demander une démo sur creodata.com/demo
