Schéma XML goAML v5.0.2 : référentiel des champs obligatoires des CTR et des STR

Lorsqu'un responsable de la conformité transmet une CTR ou une STR au Financial Reporting Centre (FRC) du Kenya, le portail goAML du FRC ne reçoit ni formulaire ni tableur. Il reçoit un fichier XML qui doit se conformer précisément au schéma XSD goAML v5.0.2 — une spécification, applicable automatiquement, de chaque élément, type de données, contrainte de longueur et règle structurelle auxquels une déclaration valide doit satisfaire.

La plupart des rejets de transmission remontent à l'une de deux causes premières : soit l'équipe informatique de l'institution déclarante a généré un fichier XML non conforme au schéma, soit l'équipe conformité a préparé des données qui ne satisfont pas aux exigences kényanes relatives aux champs obligatoires, qui viennent s'ajouter au schéma de base. Ces deux problèmes peuvent être évités avec une documentation de référence adéquate.

Cet article est cette référence. Il détaille, champ par champ, les éléments XML obligatoires des transmissions de CTR et de STR au FRC du Kenya, les types de données et les contraintes de format que chaque champ impose, ainsi que les règles de localisation propres au Kenya qui s'appliquent au-delà du XSD de base. Les développeurs informatiques qui construisent des chaînes de génération XML et les responsables de la conformité qui contrôlent la qualité des données avant la transmission y trouveront tout ce dont ils ont besoin.

---

Comprendre le schéma XSD goAML v5.0.2

Ce que signifie la validation par un schéma XSD, et pourquoi elle est importante

Un XSD (XML Schema Definition) est une spécification formelle, rédigée en XML, qui définit la structure autorisée, les noms d'éléments, les types de données, les contraintes de valeur et la cardinalité (obligatoire ou facultatif, nombre minimal/maximal d'occurrences) de chaque élément d'un document XML correspondant.

Lorsque le portail goAML du FRC reçoit votre transmission XML, il soumet le fichier à un validateur de schéma XSD avant qu'un analyste ne le voie. Le validateur contrôle chaque élément du fichier au regard des règles définies dans le schéma XSD goAML v5.0.2. Si un élément enfreint une règle, quelle qu'elle soit — champ obligatoire manquant, date au mauvais format, chaîne dépassant sa longueur maximale, valeur énumérée absente de la liste autorisée —, le validateur renvoie une erreur de validation du schéma et la transmission est rejetée dans son intégralité.

La validation du schéma est binaire : soit le fichier passe entièrement, soit il échoue. Un fichier comptant 99 éléments corrects et une seule date mal formée échoue tout aussi définitivement qu'un fichier comportant des erreurs de structure fondamentales. C'est pourquoi la validation XSD avant transmission n'est pas facultative : c'est le niveau minimal exigible de tout processus de génération de CTR ou de STR.

Les six niveaux d'imbrication du schéma

Le schéma XSD goAML v5.0.2 organise les données de la déclaration selon une structure hiérarchique à six niveaux. Comprendre cette hiérarchie est essentiel pour les développeurs qui écrivent le code de génération XML comme pour les équipes conformité qui contrôlent le XML produit.

Niveau 1 : Report (déclaration) — L'élément racine du document XML. Il contient les champs d'en-tête qui identifient le type de déclaration, l'institution déclarante, la date de dépôt et le responsable de la conformité en charge. Toute CTR et toute STR commence par cet élément.

Niveau 2 : Transaction — Un ou plusieurs éléments transaction imbriqués dans l'élément Report. Chaque élément Transaction décrit une seule opération financière, avec sa date, son montant, sa devise et son type. Une CTR est générée pour chaque transaction éligible d'un montant égal ou supérieur au seuil équivalant à 15 000 USD. Une STR contient généralement un ou plusieurs éléments Transaction liés à l'activité suspecte déclarée.

Niveau 3 : Party (partie) — Chaque élément Transaction contient des éléments Party qui identifient les personnes physiques ou morales de part et d'autre de l'opération. Les parties sont typées selon leur rôle : from_person ou from_entity côté débit, to_person ou to_entity côté crédit. Pour un dépôt d'espèces, le client est le from_person et la banque est le to_entity.

Niveau 4 : Account (compte) — Les éléments Account sont imbriqués dans les éléments Party. Ils contiennent le numéro de compte, le code d'agence, le type de compte et la devise de libellé du compte par lequel la transaction est passée. Un élément Account est requis dès lors qu'un numéro de compte est connu.

Niveau 5 : ID (pièce d'identité) — Les éléments de pièce d'identité sont imbriqués dans les éléments Party de type personne. Ils enregistrent le type de pièce d'identité (carte nationale d'identité, passeport, carte d'étranger — alien ID), le numéro du document, le pays de délivrance et, le cas échéant, la date d'expiration. Pour les ressortissants kényans, l'élément relatif à la carte nationale d'identité (National ID) est obligatoire.

Niveau 6 : Address (adresse) — Les éléments Address sont imbriqués dans les éléments Party (personnes physiques et morales). Ils enregistrent le pays, le comté ou l'État, la ville ou la localité, et l'adresse (rue) de la partie. Au minimum, le pays et la ville sont exigés pour les transmissions au FRC du Kenya.

Différences de structure entre STR et CTR dans le schéma

Les STR et les CTR reposent sur le même schéma XSD goAML v5.0.2. Elles se distinguent par la valeur de l'élément report_type (CTR ou STR) et par les champs obligatoires propres à chaque type.

Pour les CTR, les exigences portent avant tout sur des données de transaction précises : montants, devises, types de transaction et identité du client vérifiée au moyen d'une carte nationale d'identité. Le champ de l'exposé des faits ne s'applique pas.

Pour les STR, les exigences se déplacent vers la justification du soupçon : le champ reason (l'exposé des faits) est obligatoire et doit être étayé ; le champ booléen is_suspicious doit valoir TRUE ; les codes indicateurs doivent être renseignés ; et l'exposé doit rattacher les transactions à une typologie reconnue en matière de lutte contre le blanchiment de capitaux et le financement du terrorisme (LBC/FT). Les données de transaction restent exigées, mais le contenu analytique de la déclaration pèse davantage dans le schéma.

Extensions propres au Kenya dans la configuration du FRC

Le schéma XSD goAML v5.0.2 de base, tel que l'UNODC (Office des Nations unies contre la drogue et le crime) le distribue à l'ensemble des cellules de renseignement financier (CRF) participantes, contient un ensemble standard d'éléments applicables partout. Le FRC du Kenya a configuré le portail pour imposer des champs obligatoires et des règles métier supplémentaires, propres à l'environnement réglementaire et financier kényan. Il s'agit notamment des suivants :

• Carte nationale d'identité obligatoire pour les ressortissants kényans (le schéma de base considère la pièce d'identité comme recommandée, et non exigée)
• Classification obligatoire du canal de mobile money pour les transactions M-PESA, Airtel Money et T-Kash
• Le code d'agence doit correspondre à une agence enregistrée auprès de la Central Bank of Kenya (CBK)
• Le numéro d'enregistrement de l'entité auprès du FRC (FRC Entity Registration Number) doit être présent et correspondre exactement aux registres du FRC
• Longueur minimale renforcée de l'exposé pour les cas comportant un indicateur de financement du terrorisme (TF) (500 mots et plus en pratique)

Ces règles propres au Kenya sont appliquées par la couche de validation des règles métier, après la validation du schéma. Un fichier peut réussir la validation XSD et échouer malgré tout aux contrôles des règles métier du FRC.

---

Champs obligatoires des CTR — référentiel complet

Tableau 1 : champs d'en-tête de la déclaration

Remarque propre au Kenya sur reporting_entity_id : le format du numéro d'enregistrement de l'entité auprès du FRC est FRC/INST/YYYY/NNNN. La moindre variation — espaces en fin de chaîne, lettres minuscules, barres obliques omises — entraîne un rejet pour violation de règle métier ERR_045. Copiez le numéro directement depuis votre certificat d'enregistrement auprès du FRC et vérifiez-le caractère par caractère.

Remarque propre au Kenya sur report_reference : la référence unique de la déclaration ne doit jamais être réutilisée d'une transmission à l'autre. La plupart des institutions utilisent un format combinant le code de l'institution, le type de déclaration, la date et un numéro d'ordre (par ex. NSBK-CTR-20260325-001). Une référence en double entraîne un rejet avec l'erreur ERR_008.

Tableau 2 : champs de transaction

Codes de canal kényans pour les transactions de mobile money :

Remarque sur transaction_type pour le mobile money : si un client dépose des espèces auprès d'un agent M-PESA et que ce dépôt est crédité sur un compte bancaire, le transaction_type est CASH_DEPOSIT et le channel est MOBILE_WALLET_MPESA. Le type de transaction décrit la nature du mouvement d'espèces ; le canal en décrit le mécanisme.

Tableau 3 : champs d'identité du client (propres au Kenya)

Règle kényane essentielle — format de la carte nationale d'identité : les numéros de la carte nationale d'identité kényane (National Identity Card) comportent exactement 8 chiffres. Pas de lettres, pas de traits d'union, pas d'espaces. Le format est NNNNNNNN. Erreurs fréquentes :

• Transmettre un numéro à 7 chiffres (anciennes cartes délivrées avant 1990 — ces numéros à 7 chiffres restent valides et doivent être transmis sur 7 chiffres, sans être complétés par des zéros)
• Indiquer le numéro de série de la carte au lieu du numéro d'identité
• Transmettre un numéro PIN de la KRA (Kenya Revenue Authority, l'administration fiscale kényane), qui commence par une lettre, en guise de numéro de carte nationale d'identité
• Transmettre un numéro de passeport pour un ressortissant kényan alors qu'il possède une carte nationale d'identité

Pour les ressortissants étrangers, l'id_type doit être PASSPORT et le numéro de passeport doit être transmis. Le FRC n'accepte pas d'autres types de pièces d'identité étrangères en remplacement du passeport lorsque la déclaration porte sur des parties non kényanes.

---

Champs obligatoires des STR — référentiel complet

La STR utilise la même structure de schéma que la CTR pour les champs de transaction et d'identité. Les champs obligatoires supplémentaires propres aux STR se concentrent dans l'en-tête de la déclaration (la partie consacrée à la motivation du soupçon) et dans les éléments d'analyse du dossier.

Remarque sur la longueur du champ reason : si le maximum fixé par le schéma pour le champ reason est de 4 000 caractères, la validation des règles métier du FRC impose en pratique des minimums qui dépendent du type d'indicateur. Cas de blanchiment (ML) standard : environ 200 caractères au minimum (soit 30 à 40 mots environ). Cas comportant un indicateur de financement du terrorisme (TF) : environ 3 000 caractères au minimum (soit 500 mots environ). Un exposé qui atteint le minimum technique mais dont le fond est insuffisant passera la validation du schéma, mais suscitera des demandes de complément de la part du FRC.

Remarque sur indicator_codes : les codes indicateurs doivent provenir de la liste publiée par le FRC du Kenya. Transmettre des codes personnalisés ou des codes issus de la mise en œuvre de goAML par la CRF d'un autre pays entraîne un rejet pour violation de règle métier ERR_045. Consultez l'article connexe Bibliothèque d'indicateurs STR : typologies de blanchiment pour les banques kényanes (2026)EN pour la référence actuelle des codes indicateurs du FRC du Kenya.

Champs de transaction des STR : tous les champs de transaction du tableau des CTR ci-dessus s'appliquent aux transmissions de STR. La différence essentielle est qu'une STR peut porter sur des transactions qui, prises isolément, sont inférieures au seuil CTR équivalant à 15 000 USD — le critère de dépôt d'une STR est le soupçon, non le montant.

---

Règles de validation propres au Kenya

Validation du format de la carte nationale d'identité

Comme indiqué plus haut, le FRC du Kenya applique une validation stricte du format des numéros de carte nationale d'identité. La règle de validation vérifie les points suivants :

1. Type de pièce NATIONAL_ID — le champ doit contenir exactement 7 ou 8 chiffres (7 pour les anciennes cartes, 8 pour celles délivrées à partir de 1991 environ)
2. Aucun caractère alphabétique, espace, trait d'union ou autre séparateur
3. Le numéro ne doit pas être composé uniquement de zéros ni de la répétition d'un même chiffre (par ex. 00000000 et 11111111 échouent aux contrôles de vraisemblance)

Le moyen le plus sûr de réussir cette validation est d'extraire le numéro d'identité directement d'une source KYC vérifiée et d'en contrôler le format avant la transmission. De nombreuses banques conservent les numéros d'identité dans leurs systèmes KYC avec des espaces en tête, ou accolés à des numéros de série : supprimez tous les caractères non numériques avant de les intégrer au XML.

Règles de classification des canaux de mobile money

Le FRC du Kenya exige que les transactions de mobile money soient classées au moyen des codes de canal définis dans le tableau 2 ci-dessus. Les règles de classification sont les suivantes :

• Toute transaction initiée via M-PESA, que la source ou la destination finale soit ou non un compte bancaire, doit utiliser MOBILE_WALLET_MPESA
• Un virement de la banque vers M-PESA, du compte bancaire du client vers le numéro M-PESA qui lui est associé, est classé MOBILE_WALLET_MPESA
• Un dépôt d'espèces auprès d'un agent M-PESA crédité sur un compte bancaire est un CASH_DEPOSIT avec le canal MOBILE_WALLET_MPESA
• Les retraits d'espèces au DAB doivent utiliser ATM_CASH, et non BRANCH_CASH
• Les dépôts d'espèces effectués auprès d'agents bancaires (par ex. Equity Agents, Co-op Kwa Jirani) doivent utiliser AGENT_CASH

Utiliser un code de canal erroné — ou omettre le champ de canal pour les transactions de mobile money — entraîne un rejet pour violation de règle métier ERR_045.

Exigence de longueur renforcée de l'exposé en présence d'un indicateur TF

Pour les STR comportant un code indicateur TF (Terrorist Financing, financement du terrorisme), la pratique du FRC du Kenya exige que l'exposé saisi dans le champ reason satisfasse à des normes renforcées de longueur et de précision. Si le schéma XSD n'impose aucun nombre de mots, la validation des règles métier du FRC signale, pour examen manuel et probable demande d'informations complémentaires, les STR à indicateur TF dont l'exposé compte moins de 3 000 caractères environ (soit 500 mots environ).

Outre les cinq éléments habituels, les exposés TF doivent indiquer : la ou les juridictions à haut risque concernées, les noms des entités ou personnes sanctionnées mentionnées dans les alertes de filtrage, le canal et le mécanisme du transfert de fonds, ainsi que la réponse de l'institution, y compris tout gel de compte ou toute notification aux autorités de contrôle.

Champs que le FRC du Kenya rend obligatoires au-delà du XSD de base

Les champs suivants sont facultatifs dans le XSD goAML v5.0.2 de base, mais la couche de règles métier du FRC du Kenya les traite comme obligatoires :

---

Erreurs de validation XML courantes et comment les corriger

---

Automatiser la génération XML pour éviter les erreurs de schéma

Pourquoi la génération manuelle du XML conduit aux rejets

Chaque fichier XML assemblé à la main est un objet artisanal — et l'artisanat introduit l'erreur humaine. Les erreurs qui provoquent des rejets sont précisément celles que commettent les humains : une date au format DD/MM/YYYY au lieu de YYYY-MM-DD, un montant qui utilise une virgule comme séparateur de milliers, une valeur de type de transaction presque juste mais légèrement erronée, un numéro de carte nationale d'identité précédé d'un espace hérité de l'export KYC.

Lorsque la génération du XML se fait manuellement — dans un éditeur de texte, une macro Excel ou un script développé sur mesure —, les rejets à la première transmission sont monnaie courante, et chacun ajoute un cycle de reprise au calendrier de dépôt : trouver l'erreur, corriger les données, régénérer le fichier et soumettre à nouveau.

Ce que fait différemment un moteur XML automatisé

Un moteur de génération XML automatisé, conçu spécifiquement pour la conformité au schéma goAML, élimine systématiquement ces causes d'échec :

• Mappage des champs tenant compte du schéma : chaque champ en entrée est mis en correspondance avec le nom exact de son élément dans le XSD goAML. Aucun nom d'élément n'est retranscrit à la main.
• Contrôle des types de données dès la saisie : les champs de date n'acceptent que des dates valides et les restituent au format YYYY-MM-DD. Les champs décimaux suppriment les caractères de mise en forme et imposent deux décimales.
• Validation des énumérations : les champs de type de transaction, de canal et de type de pièce d'identité sont sélectionnés parmi les valeurs d'énumération exactes autorisées — aucune saisie libre.
• Application des règles métier kényanes : le format de la carte nationale d'identité, l'enregistrement du code d'agence, la classification du canal de mobile money et la concordance du numéro d'enregistrement de l'entité auprès du FRC sont tous validés avant la génération du XML.
• Validation XSD en sortie : le XML généré est validé par rapport au XSD goAML v5.0.2 avant d'être mis à disposition pour la transmission. Les fichiers qui échouent à la validation ne sont présentés au responsable de la conformité qu'une fois le problème de données sous-jacent résolu.
• Détection du seuil transaction par transaction, avec conversion des devises : chaque transaction en espèces est évaluée en temps réel au regard du seuil équivalant à 15 000 USD, le taux de change appliqué étant consigné dans la CTR.

Le résultat : une chaîne de transmission qui produit à chaque fois des fichiers XML conformes au schéma et aux exigences du FRC du Kenya — avec un taux de rejet proche de zéro.

---

Questions fréquentes

Quels sont les six niveaux du schéma XSD goAML v5.0.2 ?

Report (la racine, avec l'en-tête qui identifie le type de déclaration, l'institution, la date de dépôt et le responsable de la conformité) ; Transaction (date, montant, devise et type) ; Party (from_person ou from_entity côté débit, to_person ou to_entity côté crédit) ; Account (numéro, code d'agence, type et devise) ; ID (type de pièce d'identité, numéro, pays de délivrance et date d'expiration) ; et Address (pays, comté, ville et rue). Un fichier échoue à la validation dès qu'un niveau enfreint une règle, aussi minime soit-elle.

Quels champs le FRC du Kenya exige-t-il au-delà du schéma goAML de base ?

Le numéro de carte nationale d'identité pour les ressortissants kényans, le code d'agence (contrôlé par rapport au registre des agences de la CBK), le canal de mobile money pour les transactions M-PESA, Airtel Money et T-Kash et, pour les STR, les champs action_taken, date_of_suspicion et tipping_off_acknowledged. Ces exigences sont appliquées par la couche de règles métier du FRC après la validation XSD : un fichier peut donc passer le schéma et être malgré tout rejeté.

Quel format doit avoir un numéro de carte nationale d'identité kényane dans un fichier goAML ?

Sept ou huit chiffres, sans espaces, traits d'union ni lettres, et pas de valeur invraisemblable comme une suite de zéros. Supprimez tout caractère non numérique de l'enregistrement KYC avant la génération ; un format erroné déclenche l'erreur de règle métier ERR_045.

En quoi les fichiers CTR et STR diffèrent-ils dans le schéma ?

Ils partagent le même XSD et se distinguent par l'élément report_type. Une CTR se concentre sur des données de transaction précises et une identité vérifiée, sans exposé. Une STR doit comporter un exposé étayé dans reason, is_suspicious défini à true, des codes indicateurs et un rattachement à une typologie reconnue — et l'exposé doit être plus long et plus détaillé en présence d'un indicateur de financement du terrorisme.

Quelles sont les erreurs de validation goAML les plus courantes ?

Des dates qui ne sont pas au format YYYY-MM-DD (ERR_001), des montants comportant des symboles ou des séparateurs de milliers (ERR_002), des types de transaction absents de l'énumération (ERR_003), un id_number manquant (ERR_004), des codes de devise non ISO comme Ksh (ERR_005), un champ reason de STR vide (ERR_006), un report_reference en double (ERR_008) et un reporting_entity_id qui ne correspond pas au registre du FRC (ERR_012). Le tableau ci-dessus indique la correction à apporter pour chacune.

Bâtir votre chaîne de transmission sur un socle de schéma fiable

Comprendre le schéma XML goAML est le fondement d'un processus fiable de dépôt des CTR et des STR. Que votre institution construise sa propre chaîne de génération XML ou évalue une plateforme dédiée, le référentiel des champs et les règles de validation présentés dans cet article vous donnent ce qu'il faut pour réussir vos transmissions du premier coup, de façon constante.

La plateforme goAML de Creodata prend en charge automatiquement l'ensemble du cycle de conformité au schéma — du mappage des champs et du contrôle des types de données jusqu'à la production d'un XML validé par le XSD, en passant par la validation des règles métier propres au Kenya. Votre équipe conformité se concentre sur l'analyse ; la plateforme gère les exigences techniques du dépôt.

Découvrez la plateforme en action lors d'une démonstration en direct.

Demander une démo → https://www.creodata.com/demo

---

Articles connexes :

• Comment déposer une CTR auprès du FRC du Kenya : guide étape par étapeEN
• Transmission goAML rejetée ? Diagnostiquer et corriger les erreurs courantes
• Rédiger l'exposé des faits d'une STR pour goAML : bonnes pratiques