Génération XML selon le XSD goAML v5 : le guide technique complet

Si vous avez déjà tenté de construire de toutes pièces une déclaration XML goAML, vous savez que l'exercice est nettement plus compliqué qu'il n'y paraît. La version 5.0.2 du schéma goAML de l'UNODC (Office des Nations unies contre la drogue et le crime) définit plus de 200 éléments, dont beaucoup sont soumis à des contraintes d'énumération strictes, le tout organisé selon une hiérarchie profondément imbriquée dont les ensembles d'éléments obligatoires diffèrent selon que vous générez une déclaration des transactions en espèces (CTR) ou une déclaration de soupçon (STR). Les cellules de renseignement financier (CRF) nationales ajoutent ensuite leurs propres exigences de validation au schéma de base — et ces exigences évoluent.

La plupart des premières tentatives de génération XML goAML échouent à la transmission. La déclaration paraît correcte dans un éditeur de texte. Le XML est bien formé. Mais le portail de la CRF renvoie une erreur de validation sur un champ situé trois niveaux plus bas dans la hiérarchie des parties, formaté correctement pour tous les autres pays sauf celui-ci. Le développeur corrige, régénère, soumet à nouveau — et se heurte à une autre erreur. Ce cycle d'itérations peut durer des jours.

Ce guide s'adresse aux responsables informatiques, aux développeurs et aux architectes techniques chargés de construire ou d'évaluer des capacités de génération XML goAML. Il couvre la structure du schéma, les points de défaillance courants, les extensions propres à chaque pays et l'architecture d'une chaîne de génération XML robuste.

---

Vue d'ensemble du schéma XML goAML v5.0.2

Historique du schéma goAML

Le logiciel goAML de l'UNODC a connu plusieurs révisions majeures de son schéma depuis son premier déploiement, au milieu des années 2000. La version 3 du schéma a été la version dominante chez les premiers utilisateurs et se rencontre encore dans d'anciens déploiements de CRF. La version 4 a apporté d'importantes modifications structurelles aux éléments de transaction et de partie, en améliorant la prise en charge des structures de propriété complexes et des transactions transfrontalières.

La version 5.0.2 — la version actuelle, déployée dans les CRF des cinq pays membres de l'ESAAMLG (Groupe anti-blanchiment de l'Afrique orientale et australe) — a apporté de nouveaux affinements structurels, élargi les ensembles d'énumération des types de transaction et des types de pièces d'identité, et formalisé le mécanisme d'extension que les CRF nationales utilisent pour imposer des exigences de validation supplémentaires au-delà du schéma de base de l'UNODC.

Point essentiel : lorsque l'UNODC publie une mise à jour du XSD, celle-ci n'est pas toujours rétrocompatible. Un code qui générait un XML v4 valide peut produire un XML v5 non valide pour certaines combinaisons d'éléments. Toute implémentation de génération XML doit être figée sur la version exacte du schéma déployée par la CRF cible, et mise à jour lorsque cette CRF migre.

Structure du schéma : Report → Transaction → Party → Account → ID Document → Address

La hiérarchie du document XML goAML suit une structure logique qui reflète la déclaration de renseignement financier telle qu'elle se présente dans la réalité :

Report est l'élément racine. Il contient l'identification de l'entité déclarante, les métadonnées de transmission, les coordonnées du déclarant et un ou plusieurs enregistrements de transaction.

Les éléments Transaction se placent immédiatement sous Report. Chaque transaction a un type, un montant, une devise, une date et une description. Une même déclaration peut contenir plusieurs transactions — cas fréquent des CTR, lorsqu'un client a effectué plusieurs transactions en espèces au cours de la période de déclaration.

Les éléments Party décrivent les personnes physiques ou morales impliquées dans une transaction. Les parties sont rattachées aux transactions par les éléments from_person, to_person, from_entity et to_entity, chacun contenant l'enregistrement imbriqué de la partie. Une partie qui figure dans plusieurs transactions peut être référencée par son identifiant au lieu d'être entièrement répétée dans chaque transaction.

Les éléments Account décrivent les comptes financiers concernés — numéros de compte bancaire, codes de type et institution financière qui tient le compte. Les comptes sont rattachés au côté correspondant de la transaction (from_account, to_account).

Les éléments ID Document se trouvent à l'intérieur des enregistrements de personnes et décrivent la carte nationale d'identité, le passeport, le permis de conduire et les autres documents de vérification de l'identité. La carte nationale d'identité (National ID) est obligatoire pour les personnes kényanes en vertu des règles de validation du Financial Reporting Centre (FRC).

Les éléments Address décrivent les adresses physiques ou postales des personnes physiques et morales. Les règles de validation des adresses varient selon les pays : certaines CRF exigent un niveau de détail allant jusqu'à la rue ; d'autres acceptent la seule mention du pays pour les parties non résidentes.

Différences de schéma entre STR et CTR

Si la structure racine du schéma est commune aux déclarations de soupçon et aux déclarations des transactions en espèces, les éléments obligatoires, facultatifs ou interdits diffèrent sensiblement :

Les CTR exigent un transaction_amount d'une précision décimale exacte, CASH comme type de transaction et le détail complet des comptes des deux côtés de la transaction. Le montant du seuil CTR et le code de devise doivent concorder exactement avec le seuil déclaré dans le profil pays. Plusieurs transactions en espèces d'une même période de déclaration peuvent être regroupées dans une seule CTR.

Les STR exigent le champ booléen is_suspicious défini à true, un élément reason non vide expliquant pourquoi la transaction est suspecte, un exposé d'une longueur et d'une substance significatives, au moins un code indicateur renvoyant à une typologie de blanchiment connue figurant dans la liste d'indicateurs de la CRF, ainsi que le détail du reporting_person. Les éléments de transaction d'une STR peuvent inclure des opérations autres qu'en espèces et des opérations fractionnées qui, prises isolément, restent sous les seuils CTR.

Télécharger le XSD officiel auprès de l'UNODC

L'UNODC met les fichiers du schéma XSD goAML à disposition sur son portail officiel de documentation goAML. La source de référence pour les fichiers XSD, les notes de version et les recommandations de validation est la page produit goAML de l'UNODC. Il convient également de consulter la documentation du portail de chaque CRF nationale, car les CRF publient des extensions de schéma propres à leur pays et des documents sur les règles de validation en complément du schéma de base de l'UNODC.

Il est vivement recommandé de télécharger le XSD directement depuis le portail de la CRF du pays cible plutôt que d'utiliser une source tierce, car les extensions nationales modifient le schéma de base d'une manière que la documentation générale ne reflète pas toujours.

---

La structure du document XML goAML

Voici un exemple annoté d'une CTR goAML v5.0.2 bien formée, pour une entité déclarante kényane fictive. Toutes les données relatives aux entités et aux personnes sont entièrement fictives.

<?xml version="1.0" encoding="UTF-8"?>
<Report xmlns="http://goaml.unodc.org/goaml/en">
  <!-- Reporting entity identification — must match FIU registration exactly -->
  <rentity_id>KE-FRC-12345</rentity_id>
  <rentity_branch>NAIROBI-HQ</rentity_branch>

  <!-- Submission metadata -->
  <submission_code>E</submission_code>          <!-- E = Electronic -->
  <report_code>CTR</report_code>                <!-- CTR or STR -->
  <entity_reference>CTR-2026-0001</entity_reference>  <!-- Internal reference -->
  <fiu_ref_number></fiu_ref_number>             <!-- Blank on first submission; FIU populates on acceptance -->
  <submission_date>2026-03-25</submission_date>  <!-- YYYY-MM-DD strictly required -->
  <currency_code_local>KES</currency_code_local> <!-- ISO 4217 currency code -->

  <!-- Reporting person — the compliance officer or designated MLRO -->
  <reporting_person>
    <gender>M</gender>               <!-- M or F — not Male/Female -->
    <title>Mr</title>
    <first_name>James</first_name>
    <last_name>Mwangi</last_name>
    <birthdate>1980-05-15</birthdate>  <!-- YYYY-MM-DD — not optional for Kenya FRC -->
    <id_number>12345678</id_number>    <!-- National ID of reporting person -->
    <!-- Address and phone elements follow here -->
  </reporting_person>

  <!-- One or more transaction elements -->
  <transaction>
    <transactionnumber>TXN-2026-00123</transactionnumber>
    <transaction_location>NAIROBI-CBD-BRANCH</transaction_location>
    <date_transaction>2026-03-24</date_transaction>  <!-- Date of transaction -->
    <teller>T001</teller>                             <!-- Teller/officer ID -->
    <currency_amount>
      <amount>1250000.00</amount>    <!-- Exactly 2 decimal places required -->
      <currency_code>KES</currency_code>
    </currency_amount>

    <!-- Transaction type — must be valid enumeration value from XSD -->
    <transaction_type>CASH_DEPOSIT</transaction_type>

    <!-- The depositing party (from side) -->
    <from_person>
      <gender>F</gender>
      <title>Ms</title>
      <first_name>Wanjiru</first_name>
      <last_name>Kamau</last_name>
      <birthdate>1985-11-20</birthdate>
      <id_number>87654321</id_number>
      <id_type>NATIONAL_ID</id_type>   <!-- Enumeration — must match XSD allowed values -->
      <address>
        <address_type>HOME</address_type>
        <city>Nairobi</city>
        <country>KE</country>  <!-- ISO 3166-1 alpha-2 -->
      </address>
    </from_person>

    <!-- The receiving account (to side) -->
    <to_account>
      <institution_name>First National Bank Kenya</institution_name>
      <institution_code>KE-FRC-12345</institution_code>
      <account>
        <account_number>1234567890</account_number>
        <account_name>Wanjiru Kamau</account_name>
        <account_type>SAVINGS</account_type>  <!-- Enumeration -->
        <currency_code>KES</currency_code>
        <opened>2022-06-15</opened>
      </account>
    </to_account>
  </transaction>

</Report>

Cet exemple illustre plusieurs exigences de format essentielles, examinées en détail dans les sections ci-dessous. La structure est correcte pour une CTR simple, mais les déclarations de production exigent des éléments supplémentaires pour les configurations de transactions complexes, les parties multiples et les déclarations portant sur plusieurs transactions.

---

Éléments obligatoires et facultatifs par type de déclaration

Le tableau suivant récapitule les principaux éléments et leurs exigences pour les CTR et les STR. Les extensions propres aux CRF sont signalées sans être listées de manière exhaustive : consultez toujours la documentation de validation en vigueur propre à chaque pays.

---

Difficultés courantes de la génération XML

Problèmes d'encodage : UTF-8, sans BOM

Les implémentations du portail goAML sont notoirement strictes en matière d'encodage des caractères. La déclaration XML doit spécifier l'encodage UTF-8, et le fichier doit être enregistré en UTF-8 sans indicateur d'ordre des octets (BOM, Byte Order Mark). Les bibliothèques XML orientées Windows écrivent souvent un BOM UTF-8 par défaut, ce qui conduit le portail goAML à rejeter la transmission avec une erreur d'encodage, souvent diagnostiquée à tort comme une erreur de schéma.

Si votre XML est généré sur un système Windows avec le XmlWriter de .NET, veillez à construire le writer avec new UTF8Encoding(false) — le paramètre false supprime explicitement l'écriture du BOM. En Python, utilisez encoding='utf-8' et non la variante utf-8-sig. C'est l'une des défaillances silencieuses les plus courantes des premières implémentations de génération XML.

Rigueur du format de date : toujours YYYY-MM-DD

Chaque champ de date du schéma goAML exige le format ISO 8601 : YYYY-MM-DD. Les systèmes bancaires centraux (core banking) d'Afrique de l'Est stockent et exportent fréquemment les dates au format DD/MM/YYYY, le format lisible le plus répandu dans la région. Une couche de transformation doit normaliser toutes les dates entrantes avant qu'elles n'entrent dans la chaîne de génération XML.

Les dates stockées sous forme de numéros de série Excel (fréquentes dans les exports CSV de certains systèmes bancaires centraux) exigent une autre transformation. Dans le système de dates d'Excel, le 1er janvier 1900 correspond au numéro de série 1 ; le 25 mars 2026, au numéro de série 46106. Tout système de génération XML qui consomme des données de transactions exportées depuis Excel doit gérer explicitement cette conversion.

Précision décimale : exactement deux décimales

Les éléments de montant doivent comporter exactement deux décimales. Un montant de 1 250 000 KES doit apparaître sous la forme 1250000.00, et non 1250000, ni 1,250,000.00 (pas de séparateur de milliers), ni 1250000.0. Le XSD définit les éléments de montant comme xs:decimal avec une contrainte fractionDigits de 2. Les montants issus de divisions dans le code doivent être explicitement arrondis et formatés avant d'être insérés dans le XML.

Champs booléens : true/false en minuscules

L'élément is_suspicious et les autres champs booléens du schéma goAML utilisent le type boolean de XML Schema, qui accepte true et false (en minuscules) ou 1 et 0. De nombreux développeurs, en particulier ceux qui travaillent avec des langages dont la représentation des booléens ne tient pas compte de la casse, génèrent par inadvertance True, False, TRUE ou FALSE — des valeurs qui échouent toutes à la validation du schéma. Certaines implémentations du portail goAML acceptent 1/0, mais cela varie : utilisez toujours true/false pour une compatibilité maximale.

Contraintes d'énumération : types de transaction et de pièce d'identité

Le schéma goAML définit des ensembles d'énumération stricts pour des éléments tels que transaction_type, id_type, account_type, gender, address_type et submission_code. Chaque valeur insérée dans ces éléments doit correspondre exactement à l'une des valeurs autorisées définies dans le XSD. Si votre système bancaire central utilise d'autres tables de codes — par exemple en stockant les types de transaction sous forme de codes numériques comme 01, 02, 03 —, une couche de mappage des codes est nécessaire pour les convertir en valeurs d'énumération goAML avant la génération du XML.

Ce mappage dépend aussi du pays. Le schéma étendu du FRC du Kenya ajoute, pour les canaux de mobile money, des valeurs de type de transaction (MOBILE_WALLET_MPESA, MOBILE_WALLET_AIRTEL, MOBILE_WALLET_TKASH) qui ne figurent pas dans le schéma de base de l'UNODC. Une déclaration générée avec un type de transaction du schéma de base pour une transaction de mobile money transmise au FRC du Kenya passera la validation du XSD de base, mais échouera à la validation nationale.

Espaces et éléments vides

Le schéma goAML applique des règles précises à la distinction entre éléments vides et éléments absents. Pour les éléments facultatifs sans valeur, la bonne pratique consiste à omettre entièrement l'élément du XML généré — et non à inclure une balise vide. <fiu_ref_number></fiu_ref_number> est techniquement un XML bien formé, mais certaines implémentations du portail goAML le rejettent comme non conforme au schéma lorsque l'élément est défini avec une contrainte minLength de 1. Le bon comportement consiste à omettre entièrement fiu_ref_number lorsqu'il n'y a aucune valeur à renseigner.

À l'inverse, les éléments obligatoires qui ont une valeur ne doivent comporter aucun espace en début ou en fin de chaîne. <institution_code> KE-FRC-12345 </institution_code> échouera à la validation dans les implémentations strictes. Toutes les valeurs de chaîne doivent être débarrassées de leurs espaces superflus (trim) avant insertion.

---

Extensions XML propres à chaque pays

Comment le FRC du Kenya étend le XSD de base

Le Financial Reporting Centre du Kenya publie un profil de validation qui étend le XSD de base de l'UNODC avec des exigences obligatoires supplémentaires. Les extensions kényanes les plus importantes sont les suivantes :

Obligation de carte nationale d'identité : pour tout ressortissant kényan figurant comme from_person ou to_person dans une déclaration, les éléments id_number et id_type sont obligatoires — et non facultatifs comme dans le schéma de base. L'id_type doit être NATIONAL_ID pour les citoyens kényans. Les ressortissants étrangers doivent fournir PASSPORT.

Classification des canaux de mobile money : les transactions impliquant M-PESA, Airtel Money ou T-Kash doivent utiliser les valeurs d'énumération étendues de transaction_type définies par le FRC (MOBILE_WALLET_MPESA, MOBILE_WALLET_AIRTEL, MOBILE_WALLET_TKASH) et comporter l'élément mobile_money_agent_code lorsque la transaction a été effectuée par l'intermédiaire d'un agent.

Date de naissance exigée pour le déclarant : alors que le schéma de base de l'UNODC considère la date de naissance comme facultative pour l'élément reporting_person, les règles de validation du FRC du Kenya la rendent obligatoire. Les déclarations sans date de naissance du déclarant sont rejetées.

Seuil CTR : le seuil CTR du Kenya est de 15 000 USD ou sa contre-valeur dans toute autre devise, en vertu de l'article 44(6) du POCAMLA et de l'article 40(1) du POCAMLR 2023 (circulaire n° 4 de 2023 du FRC). Chaque transaction en espèces dont le montant atteint ou dépasse ce seuil doit être déclarée individuellement, le montant dans la devise d'origine, le taux de change appliqué et la contre-valeur en USD étant consignés dans le XML de la CTR. Les opérations d'une même journée inférieures au seuil ne sont pas agrégées dans une CTR ; lorsqu'elles semblent relever du fractionnement, l'institution dépose une STR.

Extensions du FIC de Zambie

Le Financial Intelligence Centre (FIC) de Zambie applique son propre profil de validation par-dessus le schéma de base de l'UNODC. Les principales différences avec le Kenya portent sur le code de devise (ZMW), des seuils CTR différents et des énumérations de types de transaction propres à la Zambie. Le FIC exige également le numéro d'immatriculation de l'entreprise (Business Registration Number) pour les parties de type entité, qui correspond à un champ différent de celui que privilégie le FRC du Kenya.

Les institutions qui se développent du Kenya vers la Zambie ne peuvent pas réutiliser un moteur de génération XML configuré pour le Kenya sans modifier la configuration du profil de validation.

Pourquoi un modèle XML unique ne fonctionne pas dans tous les pays

C'est la raison fondamentale pour laquelle les générateurs XML goAML prêts à l'emploi conçus pour un seul pays échouent lorsqu'ils sont déployés dans des environnements multipays. Le XSD de base de l'UNODC fournit l'enveloppe structurelle. Les CRF nationales appliquent ensuite des règles de validation qui modifient la liste des éléments obligatoires, étendent les ensembles d'énumération et ajoutent des éléments entièrement propres au pays. Un modèle codé en dur pour le FRC du Kenya générera un XML non valide pour la Financial Intelligence Authority (FIA) d'Ouganda, et inversement.

Un moteur de génération XML multipays de production doit être piloté par des profils de configuration propres à chaque pays, qui déclarent, pour chaque pays cible, les règles de validation applicables, les champs obligatoires, les extensions d'énumération et les informations relatives aux points de terminaison (endpoints) de la CRF.

---

Validation XSD dans le code

Validation de schéma XML en .NET avec XmlSchemaSet

En .NET, la validation XSD goAML s'effectue avec la classe System.Xml.Schema.XmlSchemaSet, associée à un XmlReader configuré avec des paramètres de validation. Le processus charge le fichier XSD (ou les fichiers, si l'extension nationale est un XSD de surcouche distinct), l'ajoute à l'ensemble de schémas et valide le document XML généré par rapport à celui-ci avant toute tentative de transmission.

Les erreurs de validation sont remontées par un callback ValidationEventHandler, qui doit capturer le message d'erreur complet, le numéro de ligne dans le XML source et le chemin de l'élément dans le schéma. Ces trois informations sont indispensables pour déterminer quelle partie de la structure de la déclaration a échoué à la validation, et pourquoi. Les implémentations de production doivent journaliser toutes les erreurs de validation avec le contexte complet de la déclaration, afin de permettre un diagnostic et une correction rapides.

L'étape de validation doit intervenir une fois la génération XML terminée, mais avant la sérialisation du document dans la charge utile de transmission. Valider en cours de génération (alors que le document est encore en construction) produit des erreurs trompeuses, car des éléments obligatoires qui seront ajoutés plus tard sont signalés comme manquants.

Validation avec lxml en Python

Les développeurs Python qui utilisent la bibliothèque lxml disposent de la classe lxml.etree.XMLSchema pour la validation fondée sur un XSD. Le principe consiste à analyser le fichier XSD pour en faire un objet XMLSchema, puis à appeler .validate() sur l'arborescence du document généré. L'attribut XMLSchema.error_log fournit la liste complète des erreurs de validation, avec les informations de chemin.

Une subtilité de lxml : la bibliothèque est stricte sur la gestion des espaces de noms. La déclaration xmlns du schéma goAML doit figurer sur l'élément racine et correspondre exactement à l'espace de noms déclaré dans le XSD. Une erreur courante consiste à générer un fichier XML dont l'URI d'espace de noms diffère légèrement (par exemple par une barre oblique finale, ou par une différence de casse entre en et EN), ce qui fait échouer le schéma avec une erreur « no matching global element declaration » plutôt qu'avec une erreur précise au niveau d'un champ.

L'approche par liaison JAXB en Java

Les développeurs Java qui travaillent avec goAML utilisent généralement JAXB (Java Architecture for XML Binding) pour générer des liaisons de classes Java directement à partir du XSD. Le compilateur xjc lit le XSD et produit des classes Java annotées pour chaque type du schéma, ainsi que le code de marshalling et d'unmarshalling. La génération d'une déclaration consiste alors à construire des graphes d'objets Java et à les sérialiser en XML — le marshaller JAXB applique automatiquement les contraintes du schéma lors de la sérialisation.

L'approche JAXB a l'avantage d'offrir une sûreté de typage à la compilation : les champs de type incorrect ou les valeurs obligatoires manquantes deviennent des erreurs de compilation plutôt que des échecs de validation à l'exécution. L'inconvénient est que la régénération des liaisons JAXB lors d'une modification du XSD impose de recompiler et de redéployer le code qui en dépend.

Outils de validation XSD en ligne pour les tests

Pendant le développement et les tests de mise à jour du schéma, les outils de validation XSD en ligne offrent une boucle de retour rapide sans exiger d'environnement de développement local. Des outils tels que FreeFormatter.com et XMLValidation.com acceptent le téléversement de fichiers XSD et XML et renvoient des messages d'erreur de validation détaillés. Ils sont utiles pour des vérifications rapides, mais ne doivent pas remplacer la validation automatisée dans la chaîne de déploiement : les outils en ligne ne prennent pas forcément en charge toutes les fonctionnalités des schémas XSD, et des données clients sensibles ne doivent jamais être téléversées sur des validateurs publics.

---

Construire une chaîne de génération XML robuste

Une chaîne de génération XML goAML de niveau production comporte cinq couches distinctes, chacune ayant une responsabilité précise.

1. Couche de normalisation des données

Les données de transactions issues des systèmes bancaires centraux arrivent dans des formats qui ne sont pas directement utilisables dans le XML goAML. La couche de normalisation gère la conversion du format des dates (DD/MM/YYYY → YYYY-MM-DD), la normalisation de la précision des montants, l'uniformisation de l'encodage des caractères et la suppression des caractères spéciaux interdits en XML (octets nuls, certains caractères de contrôle). Elle tronque également les champs lorsque les données entrantes dépassent la longueur maximale définie dans le schéma.

2. Couche de validation des règles métier

Avant que la génération XML ne commence, la couche de validation des règles métier vérifie que les données du dossier assemblé satisfont à toutes les exigences sémantiques du type de déclaration. Pour une CTR : le montant de la transaction atteint-il ou dépasse-t-il le seuil ? Le numéro de compte est-il présent ? Le type de transaction est-il un type de transaction en espèces ? Pour une STR : y a-t-il au moins un code indicateur ? L'exposé est-il non vide et d'une longueur suffisante ? is_suspicious est-il correctement renseigné ?

Détecter les erreurs sémantiques à ce niveau, avant la génération XML, produit des messages d'erreur bien plus utiles que de les détecter sous forme d'échecs de validation XSD après la génération.

3. Couche de génération XML

La couche de génération XML prend les données normalisées et validées au regard des règles métier, et construit le document XML goAML. Le modèle d'architecture recommandé repose sur des builders tenant compte du schéma — des classes ou des fonctions qui construisent des éléments précis du schéma à partir des objets du modèle de données. Chaque builder est responsable d'un type d'élément (PersonBuilder, AccountBuilder, TransactionBuilder) et applique la mise en forme, le mappage des énumérations et la logique d'inclusion ou d'exclusion d'éléments qui conviennent au profil du pays cible.

Le XML généré doit être sérialisé en mémoire, sous forme de chaîne ou de tableau d'octets, avant d'être écrit sur disque ou transmis, afin que la couche de validation puisse l'inspecter avant qu'il ne quitte le système.

4. Couche de validation après génération

La couche de validation après génération applique au document XML généré le XSD chargé propre au pays. Toutes les erreurs de validation sont journalisées avec leur contexte complet. En présence d'erreurs de validation, la déclaration est signalée pour examen au lieu d'être transmise. L'équipe conformité voit le champ précis qui a échoué à la validation et la règle du schéma qu'il enfreint, ce qui permet un diagnostic rapide sans faire appel aux développeurs.

5. Couche de transmission et de suivi

Une fois que le document XML a réussi la validation après génération, la couche de transmission l'envoie au portail de la CRF. Les réponses — confirmations d'acceptation, messages de rejet assortis de codes motifs et numéros de référence attribués par la CRF — sont capturées et rattachées à l'enregistrement d'origine de la déclaration. Les réponses en attente sont interrogées périodiquement jusqu'à l'obtention d'un statut définitif. Le détail des rejets est présenté à l'équipe conformité, avec des indications pour la correction et la nouvelle soumission.

---

Quand recourir à un moteur de génération XML prêt à l'emploi

Charge de maintenance lorsque l'UNODC met à jour le XSD

L'UNODC a publié plusieurs versions du XSD du schéma goAML, et cela va continuer. Lorsqu'une CRF nationale déploie une nouvelle version du XSD, le code de génération XML développé en interne doit être mis à jour, testé et déployé — souvent dans l'urgence, car les CRF fixent des échéances de migration. Si votre moteur de génération XML est maintenu en interne, chaque mise à jour du schéma atterrit sur le bureau de votre équipe de développement, en concurrence avec ses autres priorités.

Mises à jour des règles propres à chaque pays

Le FRC du Kenya publie périodiquement des recommandations de validation actualisées. Lorsqu'une nouvelle valeur d'énumération de type de transaction est ajoutée (par exemple à l'arrivée d'un nouvel opérateur de mobile money sur le marché), chaque mappage d'énumération codé en dur dans votre code interne doit être mis à jour. Lorsqu'un nouveau champ obligatoire est introduit pour les STR, votre modèle de données de gestion des dossiers doit être étendu, votre workflow mis à jour pour recueillir les nouvelles données, et votre code de génération XML adapté pour renseigner le nouvel élément.

Une plateforme prête à l'emploi intègre ces mises à jour dans son modèle de licence : les évolutions du schéma sont l'affaire de l'éditeur, pas la vôtre.

Cadre de décision : développer ou acheter

Pour les institutions disposant d'importantes équipes de développement internes, d'une expertise approfondie des technologies de conformité et d'un besoin stratégique de logique de génération XML hautement personnalisée, le développement interne peut se justifier. Pour la majorité des institutions financières d'Afrique de l'Est, le profil économique et le profil de risque plaident nettement en faveur d'une plateforme dédiée, maintenue par des spécialistes de la conformité au schéma goAML.

---

Passez à l'étape suivante

La plateforme goAML de Creodata pour les déclarations de lutte contre le blanchiment de capitaux et le financement du terrorisme (LBC/FT) comprend un moteur de génération XML prêt pour la production, maintenu à jour par rapport au XSD goAML v5.0.2 en vigueur, avec des profils de validation propres à chaque pays pour le FRC du Kenya, la FIA d'Ouganda, la FIU de Tanzanie, le FIC de Zambie et le Centre de renseignement financier (FIC) du Rwanda. Le moteur gère automatiquement l'encodage, le formatage des décimales, la normalisation des dates, le mappage des énumérations et la validation XSD : les équipes conformité travaillent avec des formulaires structurés, pas avec du XML.

Découvrez le moteur de génération XML en action lors d'une démonstration en direct : Demander une démo sur creodata.com/demo

Questions fréquentes

Pour quelle version du schéma goAML dois-je générer le XML ?

La version 5.0.2 est le schéma déployé par les CRF d'Afrique de l'Est couvertes par ce guide. Figez votre générateur sur la version exacte publiée par votre CRF et testez-le à nouveau lorsqu'elle migre : les versions de l'UNODC ne sont pas toujours rétrocompatibles, si bien qu'un XML validé par rapport à la v4 peut échouer sur certaines combinaisons d'éléments de la v5.

Pourquoi le portail goAML rejette-t-il un fichier validé en local ?

Le plus souvent, pour l'une de ces quatre raisons : un indicateur d'ordre des octets (BOM) UTF-8 écrit par une bibliothèque XML Windows ; une extension nationale que votre XSD local n'inclut pas, comme les types de transaction de mobile money du FRC du Kenya ; un élément facultatif vide qui aurait dû être omis ; ou un contrôle de règle métier exécuté après la validation du schéma — un numéro d'entité déclarante qui ne correspond pas au registre de la CRF, ou une référence de déclaration en double.

Quels formats de date, de montant et de booléen le XSD goAML exige-t-il ?

Les dates sont exclusivement au format ISO 8601 YYYY-MM-DD. Les montants sont de type xs:decimal, avec exactement deux décimales et sans séparateur de milliers (1250000.00). Les booléens s'écrivent true ou false, en minuscules. Les exports des systèmes bancaires centraux au format DD/MM/YYYY, les dates en numéro de série Excel et les valeurs comme True ou FALSE doivent être normalisés avant la génération.

Quelle est la structure d'une déclaration XML goAML ?

Report → Transaction → Party → Account → ID document → Address. Une déclaration comporte une ou plusieurs transactions ; chaque transaction désigne les parties des deux côtés (from_person ou from_entity, to_person ou to_entity), leurs comptes, leurs pièces d'identité et leurs adresses. Une CTR exige des types de transaction en espèces et le détail complet des comptes ; une STR exige is_suspicious défini à true, un exposé étayé dans reason et au moins un code indicateur.

Où télécharger le XSD goAML officiel ?

Dans la documentation goAML de l'UNODC — et, surtout, sur le portail de votre propre CRF, car les extensions nationales modifient le schéma de base. Validez par rapport à la copie publiée par la CRF plutôt qu'à partir d'un téléchargement tiers.