Transmission goAML rejetée ? Comment diagnostiquer et corriger les erreurs courantes

Les rejets à la première transmission font partie du quotidien des institutions qui préparent leurs déclarations goAML à la main. Si votre déclaration des transactions en espèces (CTR) ou votre déclaration de soupçon (STR) vient d'être renvoyée par le portail du FRC, la cellule de renseignement financier (CRF) du Kenya, vous êtes en bonne compagnie — mais la reprise du travail n'en est pas moins frustrante, surtout lorsqu'une échéance de déclaration approche.

Le cycle des rejets est l'un des schémas les plus corrosifs des opérations de conformité en matière de lutte contre le blanchiment de capitaux et le financement du terrorisme (LBC/FT). Un analyste passe deux heures à préparer une transmission, elle est rejetée, il consacre encore 90 minutes à diagnostiquer et à corriger le problème, elle est de nouveau rejetée pour une autre erreur, et deux jours se sont écoulés sans que rien ne soit déclaré, alors que l'échéance se rapproche. Pendant ce temps, le responsable de la conformité doit répondre aux questions sur la dégradation des indicateurs de ponctualité des déclarations de l'institution.

Ce guide brise ce cycle. Il explique précisément comment lire un avis de rejet du FRC, propose une référence de dépannage numérotée pour les dix causes de rejet les plus fréquentes, détaille la procédure de nouvelle soumission et vous montre comment empêcher les rejets de se produire en amont.

Comprendre les avis de rejet goAML

Ce que le FRC vous envoie lorsqu'une transmission échoue

Lorsque le portail goAML du FRC rejette une transmission, il génère une réponse de rejet, qui vous parvient de l'une des deux manières suivantes selon la nature de l'échec :

Message d'erreur au niveau du portail : si le fichier est mal formé au point que le portail ne peut pas du tout l'analyser — fichier tronqué, encodage XML non valide, téléversement corrompu —, le portail renvoie immédiatement un message d'erreur sur l'écran de téléversement. Ce message est bref et souvent générique (par ex. « Le fichier n'a pas pu être traité. Veuillez vérifier le format du fichier. »). Il ne contient pas de codes d'erreur détaillés. Ce type d'erreur signifie que votre XML n'est pas bien formé et qu'il doit être vérifié au niveau structurel avant que vous puissiez passer au diagnostic du schéma ou des règles métier.

Avis de rejet structuré (fichier d'erreurs XML) : pour les fichiers qui peuvent être analysés mais qui échouent à la validation, le portail du FRC génère un fichier de réponse d'erreur XML structuré. Ce fichier contient une ou plusieurs entrées d'erreur, chacune comportant :

Un code d'erreur (par ex. ERR_001, ERR_012, ERR_045)
Un niveau de gravité (FATAL, ERROR, WARNING)
Un message d'erreur rédigé en anglais simple, qui décrit le problème précis
Le cas échéant, le nom de l'élément XML et la valeur à l'origine de l'échec
Pour les erreurs de schéma : l'emplacement XPath de l'élément en échec dans l'arborescence XML

Téléchargez ce fichier d'erreurs depuis l'historique des transmissions du portail — c'est votre feuille de route pour le diagnostic. N'essayez pas de corriger les erreurs sur la seule base de l'écran récapitulatif du portail ; le détail du fichier d'erreurs est indispensable à un diagnostic exact.

Lire les codes d'erreur : erreurs de validation du schéma et violations de règles métier

Les erreurs de rejet goAML se répartissent en deux catégories fondamentales, et les distinguer est la première étape du diagnostic :

Erreurs de validation du schéma (plage ERR_001 à ERR_009) : elles signifient que votre fichier XML n'est pas conforme aux règles structurelles du schéma XSD goAML v5.0.2. Un champ de date contient une valeur qui n'est pas une date, un champ décimal contient une chaîne de caractères, un élément obligatoire est absent, une valeur énumérée ne figure pas dans la liste autorisée. Les erreurs de schéma proviennent du processus de génération du XML — soit de l'étape de préparation des données, soit de l'étape de construction du XML. Elles sont généralement faciles à diagnostiquer, car le fichier d'erreurs identifie l'élément et la valeur exacts en cause.

Violations de règles métier (plage ERR_010 à ERR_099) : elles signifient que votre XML est structurellement valide et passe la validation du schéma, mais qu'il enfreint une règle métier propre au FRC du Kenya. Un numéro d'identité nationale (National ID) n'a pas le bon format, l'identifiant de l'entité déclarante ne correspond pas aux registres du FRC, un code d'agence ne figure pas dans le registre de la CBK (Central Bank of Kenya), une STR comportant un indicateur de financement du terrorisme (FT) présente un exposé insuffisant. Les erreurs de règles métier imposent de vérifier vos données par rapport à des sources de référence externes (registres du FRC, registre des agences de la CBK, liste des codes indicateurs du FRC) — la correction ne porte pas sur la structure du XML, mais sur les données sous-jacentes.

Priorité : corriger d'abord les erreurs de schéma, puis les erreurs de règles métier

Si votre avis de rejet contient à la fois des erreurs de schéma et des violations de règles métier, corrigez d'abord les erreurs de schéma. En effet, les erreurs de schéma peuvent masquer des erreurs de règles métier — le portail peut cesser d'évaluer les règles métier après avoir rencontré un échec de schéma. Une fois que votre fichier passe la validation du schéma, vous voyez l'ensemble complet des violations de règles métier, et non une liste partielle.

Une erreur courante consiste à corriger une erreur de règle métier visible et à soumettre à nouveau, pour découvrir une autre erreur de règle métier à la tentative suivante — parce que l'erreur de schéma la masquait. Traitez méthodiquement la liste complète des erreurs avant de soumettre à nouveau.

Les 10 motifs de rejet les plus fréquents (et leurs corrections)

1. National ID manquant

Code d'erreur : ERR_045 (violation de règle métier) Message d'erreur : « Le numéro de National ID est obligatoire pour les parties dont l'id_type est NATIONAL_ID. » Cause profonde : le numéro de National ID du client n'était pas disponible dans le dossier KYC (connaissance du client) au moment de la génération du XML, ou il a été associé au mauvais champ XML. Il se peut aussi que le champ du numéro d'identité ait été renseigné, mais laissé sous forme de chaîne vide : il passe alors la validation du schéma, mais échoue au contrôle de la règle métier qui exige un contenu obligatoire non vide. Correction : récupérez le numéro de National ID du client dans votre système KYC. Vérifiez qu'il comporte exactement 7 à 8 chiffres, sans aucun caractère non numérique. Renseignez l'élément id_number dans le XML et validez de nouveau. Si le National ID est réellement absent de vos dossiers KYC, lancez une remédiation KYC et documentez la lacune avant de soumettre à nouveau. N'inscrivez pas à la place un PIN fiscal KRA, un numéro de passeport ou un numéro de téléphone dans le champ National ID.

2. Format de date non valide

Code d'erreur : ERR_001 (échec de la validation du schéma) Message d'erreur : « L'élément <transaction_date> a pour valeur '25/03/2026', qui n'est pas une valeur xs:date valide. » Cause profonde : dans le XML goAML, les champs de date doivent être au format ISO 8601 : YYYY-MM-DD. Une date exportée d'un système bancaire central (core banking) au format de date kényan (DD/MM/YYYY) ou au format par défaut d'Excel (25-Mar-2026) échoue à la validation du schéma. L'erreur concerne tous les champs de date : transaction_date, report_date, date_of_birth, id_expiry_date. Correction : reformatez toutes les valeurs de date en YYYY-MM-DD avant de les insérer dans le XML. Si votre XML est généré par un script ou une macro, ajoutez une normalisation du format de date dès l'étape d'extraction des données — ne comptez pas sur le système source pour exporter au bon format. Une expression régulière pour les dates valides est ^\d{4}-\d{2}-\d{2}$. Les mois et les jours à un seul chiffre doivent être complétés par un zéro initial (par ex. 2026-03-05, et non 2026-3-5).

3. Texte de l'exposé vide

Code d'erreur : ERR_001 (schéma) ou ERR_045 (règle métier) Message d'erreur : « L'élément <reason> ne doit pas être vide » ou « Le champ d'exposé de la STR ne respecte pas les exigences minimales de contenu. » Cause profonde : le champ reason d'une STR transmise est vide, ne contient que des caractères d'espacement, ou contient un texte provisoire tel que « exposé à venir » ou « N/A ». C'est le plus évitable de tous les motifs de rejet — il indique qu'une déclaration incomplète a été transmise. Correction : rédigez un exposé substantiel avant la transmission. Pour savoir ce que l'exposé doit contenir et comment le structurer, consultez Comment rédiger l'exposé d'une STR pour goAML : bonnes pratiques. Ne transmettez en aucun cas une STR sans exposé complet. Si la pression des délais vous préoccupe, transmettez-la avec un exposé bref mais complet couvrant les cinq éléments obligatoires, puis complétez-la au besoin par des informations supplémentaires.

4. Exposé trop court (cas de FT)

Code d'erreur : ERR_045 (violation de règle métier) Message d'erreur : « Une STR comportant des codes indicateurs FT exige un exposé renforcé. L'exposé actuel ne respecte pas la norme de contenu minimale. » Cause profonde : la STR comporte un ou plusieurs codes indicateurs de FT (financement du terrorisme), mais l'exposé figurant dans le champ reason n'atteint pas la norme de contenu minimale que le FRC du Kenya applique aux déclarations comportant des indicateurs de FT. Le minimum pratique est d'environ 500 mots, couvrant l'analyse typologique complète, y compris le risque lié aux juridictions, l'identification des contreparties et la réponse de l'institution. Correction : étoffez l'exposé pour qu'il réponde aux normes de déclaration du FT. Un exposé de FT doit comprendre : l'identification complète de la personne visée, la description de chaque transaction suspecte, l'explication des raisons pour lesquelles un financement du terrorisme est soupçonné (et pas seulement un blanchiment de capitaux), la mention précise des juridictions à haut risque ou des parties sanctionnées impliquées, la description des flux de fonds transfrontaliers le cas échéant, et la réponse de l'institution, y compris toute mesure prise sur le compte et la notification au FRC. Si votre STR porte sur un véritable indicateur de FT, l'exposé devrait naturellement atteindre au moins 500 mots une fois tous les éléments requis couverts.

5. Code devise erroné

Code d'erreur : ERR_003 (échec de la validation du schéma) Message d'erreur : « La valeur 'Ksh' de l'élément <transaction_currency> ne fait pas partie de l'énumération autorisée. » Cause profonde : le champ transaction_currency exige un code devise ISO 4217 exact à trois lettres. Parmi les variantes kényanes courantes qui échouent figurent : Ksh, KSH, K.Sh, KE, KShs, Kshs. Un lecteur humain les reconnaît toutes comme des shillings kényans, mais elles ne sont pas valides dans l'énumération du schéma. Correction : remplacez toutes les valeurs de devise par les codes ISO 4217 exacts. Le code du shilling kényan est KES. Autres devises courantes dans les transactions des banques kényanes : USD (dollar américain), EUR (euro), GBP (livre sterling), UGX (shilling ougandais), TZS (shilling tanzanien). Ajoutez une table de correspondance des codes devises à votre processus de préparation des données pour imposer les bons codes dès la source.

6. Type de transaction non valide

Code d'erreur : ERR_003 (échec de la validation du schéma) Message d'erreur : « La valeur 'CASH' de l'élément <transaction_type> ne fait pas partie de l'énumération autorisée. » Cause profonde : le champ transaction_type n'accepte que certaines valeurs énumérées définies dans le XSD goAML. Parmi les valeurs non valides couramment observées dans les CTR kényanes figurent : CASH, DEPOSIT, WITHDRAWAL, CASH DEP, CASH WITH, TRANSFER. Même des valeurs dont l'intention est manifestement correcte échouent si elles ne correspondent pas exactement. Correction : n'utilisez que les valeurs d'énumération exactes autorisées par le schéma. Pour les CTR transmises au FRC du Kenya, les valeurs valides de transaction_type sont : CASH_DEPOSIT, CASH_WITHDRAWAL, CURRENCY_EXCHANGE. N'utilisez ni abréviations, ni espaces à l'intérieur des valeurs, ni variantes de casse. Si votre système bancaire central exporte les codes de type de transaction dans un autre format, ajoutez une table de transcodage à votre processus de génération du XML.

7. Identifiant de l'entité déclarante manquant

Code d'erreur : ERR_045 (violation de règle métier) Message d'erreur : « L'identifiant de l'entité déclarante ne correspond pas au registre du FRC. Champ : reporting_entity_id. » Cause profonde : le numéro d'enregistrement de l'entité auprès du FRC (FRC Entity Registration Number) figurant dans le XML ne correspond pas au numéro enregistré auprès du FRC, ou bien le champ est absent ou vide. Causes courantes : erreurs de transcription du numéro d'enregistrement, variantes de format du nom (le schéma exige le nom exact tel qu'enregistré) et transmissions effectuées sous le numéro FRC d'une filiale alors que celui de la société mère était visé (ou inversement). Correction : relevez le numéro d'enregistrement de votre institution auprès du FRC directement sur votre certificat d'enregistrement du FRC — le document original, et non un numéro retenu de mémoire. Recopiez-le caractère par caractère dans votre XML. Le format est FRC/INST/YYYY/NNNN. Vérifiez que reporting_entity_name dans le XML correspond lui aussi exactement au nom enregistré de l'entité. Enregistrez le bon numéro dans le fichier de configuration de votre génération XML pour éliminer les erreurs de ressaisie.

8. Référence de déclaration en double

Code d'erreur : ERR_008 (violation de règle métier) Message d'erreur : « Le numéro de référence de déclaration [valeur] a déjà été transmis. Chaque transmission doit avoir une référence unique. » Cause profonde : votre institution a déjà transmis une déclaration portant la même valeur report_reference. Cela peut se produire lorsqu'une déclaration rejetée est soumise à nouveau au moyen de la fonction Resubmit mais qu'une nouvelle référence est générée par erreur, lorsque la même déclaration est transmise deux fois à la suite d'une confusion dans la navigation du portail, ou lorsque votre logique de génération des références ne garantit pas l'unicité (par ex. une référence fondée uniquement sur la date, sans numéro de séquence). Correction en cas de nouvelle soumission : lorsque vous soumettez à nouveau une déclaration précédemment rejetée, utilisez la fonction Resubmit du portail et indiquez l'identifiant de la transmission d'origine — ne modifiez pas le numéro de référence de la déclaration. Le FRC suit les corrections sous la référence d'origine. Correction en cas de véritable doublon : générez un nouveau numéro de référence unique. Modifiez votre mécanisme de génération des références pour y inclure un numéro de séquence incrémental (par ex. NSBK-CTR-20260325-004) plutôt qu'une référence fondée uniquement sur la date ou sur un hachage, qui risque d'entrer en collision.

9. Code indicateur non valide

Code d'erreur : ERR_045 (violation de règle métier) Message d'erreur : « Le code indicateur [valeur] n'est pas reconnu dans la liste de référence des indicateurs du FRC du Kenya. » Cause profonde : le champ indicator_codes contient un ou plusieurs codes qui n'existent pas dans la référence actuelle des codes indicateurs du FRC. Cela se produit lorsqu'un analyste saisit manuellement les codes indicateurs et commet une erreur de transcription, lorsque des codes issus de la mise en œuvre d'une autre CRF sont utilisés (codes génériques du GAFI au lieu des codes du FRC du Kenya), ou lorsque le FRC a mis à jour sa liste de codes indicateurs sans que la liste de référence de votre institution ait été actualisée. Correction : procurez-vous la liste de référence actuelle des codes indicateurs du FRC du Kenya directement auprès du FRC ou dans la section des données de référence du portail goAML. Remplacez tous les codes non valides par les bons codes de la liste en vigueur. Si vous tenez une table de correspondance des codes indicateurs dans votre système de conformité, mettez-la à jour d'après la liste actuelle du FRC. Envisagez d'ajouter la validation des codes indicateurs à votre liste de contrôle avant transmission.

10. Format de numéro de compte non concordant

Code d'erreur : ERR_045 (violation de règle métier) Message d'erreur : « Le format du numéro de compte ne correspond pas au modèle attendu pour l'institution déclarante. » Cause profonde : le champ account_number contient une valeur non conforme au format de numéro de compte que votre institution a enregistré auprès du FRC ou de la CBK. Cela peut se produire lorsque des numéros de compte issus de systèmes différents sont combinés (format de numéro de compte du core banking, format de compte de la CBK, format IBAN international), lorsque les zéros initiaux sont supprimés lors de l'export des données, ou lorsque les numéros de compte incluent des codes d'agence ou de produit qui ne font pas partie du numéro de compte proprement dit. Correction : confirmez le format exact de numéro de compte que votre institution a enregistré auprès du FRC — généralement le même que celui utilisé dans les déclarations réglementaires à la CBK. Appliquez un formatage cohérent dans votre processus de génération du XML : si vos numéros de compte comptent 13 chiffres avec des zéros initiaux, veillez à ce que l'export conserve ces zéros (problème fréquent avec Excel). Si votre système stocke les numéros de compte avec des codes d'agence ou de produit intégrés, supprimez ces composantes avant d'inclure le numéro de compte dans le XML de la CTR ou de la STR.

Comment soumettre à nouveau après correction des erreurs

Procédure de nouvelle soumission sur le portail du FRC

La procédure de nouvelle soumission appropriée varie selon que vous corrigez une transmission rejetée ou que vous transmettez une modification d'une transmission acceptée :

Pour les transmissions rejetées : accédez à l'historique de vos transmissions sur le portail du FRC et repérez la transmission rejetée grâce à son numéro de référence. Utilisez l'option Resubmit (et non New Report) et téléversez votre fichier XML corrigé. Le portail rattache le fichier corrigé à l'enregistrement de la transmission d'origine, ce qui préserve la chronologie de la déclaration aux fins du respect des délais. Ne modifiez pas la valeur report_reference dans le XML corrigé — le FRC doit pouvoir rapprocher la déclaration corrigée de l'originale.

Pour les modifications de transmissions acceptées : si une transmission acceptée contenait une erreur que vous découvrez après son acceptation, contactez directement le FRC (voir la section sur l'escalade ci-dessous) avant de tenter de déposer une modification. Le FRC vous indiquera si une modification sur le portail, une STR complémentaire ou une correction écrite formelle est appropriée, selon la nature de l'erreur.

Nouvelle soumission dans le délai de déclaration — est-elle toujours dans les temps ?

En vertu du POCAMLA et de sa réglementation, les CTR (transactions en espèces de 15 000 USD ou plus) doivent être déposées au plus tard le vendredi de la semaine au cours de laquelle la transaction déclenchante a eu lieu (article 44(6) et règlement 40). Les STR doivent être déposées dans un délai de deux jours à compter de la date à laquelle le soupçon est apparu (article 44(2)). Le FRC mesure la ponctualité entre la date de l'événement déclencheur et la date de la première transmission, et non la date d'une nouvelle soumission réussie.

Cela signifie que si votre première tentative de transmission a eu lieu dans le délai prescrit mais a été rejetée, votre institution a tout de même tenté de déclarer dans les délais. Le rejet et la nouvelle soumission sont documentés dans l'historique des transmissions du portail. En revanche, si votre première tentative intervient en dehors du délai prescrit en raison de retards internes — et non d'un rejet suivi d'une nouvelle soumission —, aucune protection ne s'applique. Déclarez à temps, corrigez les erreurs à temps, soumettez à nouveau le plus rapidement possible.

Conservez une trace de l'horodatage de votre première tentative de transmission. Lors d'un contrôle réglementaire ou d'un audit LBC/FT, cet horodatage démontre l'intention de déclarer dans les délais, même lorsque la transmission initiale a été rejetée.

Documenter le rejet et la correction dans votre piste d'audit de conformité

Chaque transmission rejetée et chaque nouvelle soumission qui s'ensuit doivent être documentées dans les dossiers de conformité de votre institution. La documentation doit comprendre :

Le numéro de référence et la date de transmission de la déclaration rejetée
Les codes d'erreur reçus et les messages d'erreur
Les corrections de données précises apportées et la source des données corrigées
La date et le numéro de référence de la nouvelle soumission réussie
Le nom du responsable de la conformité qui a effectué les corrections et celui du responsable qui a approuvé la nouvelle soumission

Cette documentation a deux fonctions : elle démontre aux régulateurs que votre institution prend au sérieux la qualité de ses transmissions et traite les rejets de façon systématique, et elle fournit une piste de preuves indispensable si le FRC soulève des questions sur une déclaration précise des mois, voire des années plus tard.

Prévenir les rejets avant qu'ils ne se produisent

Liste de contrôle de validation avant transmission (10 contrôles)

Passez en revue cette liste pour chaque CTR ou STR avant de la téléverser sur le portail du FRC :

Contrôle du format de date : tous les champs de date sont au format YYYY-MM-DD, sans exception.
Contrôle du National ID : tous les enregistrements de parties de nationalité kényane contiennent un National ID numérique de 7 à 8 chiffres dans le champ id_number.
Contrôle du code devise : toutes les valeurs de transaction_currency sont des codes ISO 4217 exacts à trois lettres (KES, USD, EUR, etc.).
Contrôle du type de transaction : toutes les valeurs de transaction_type appartiennent à l'énumération autorisée.
Unicité de la référence de déclaration : la valeur report_reference n'a été utilisée dans aucune transmission précédente.
Contrôle de l'identifiant de l'entité déclarante : la valeur reporting_entity_id correspond exactement à votre certificat d'enregistrement du FRC.
Contrôle des codes d'agence : toutes les valeurs de branch_code correspondent à des agences de votre institution enregistrées auprès de la CBK.
Exhaustivité de l'exposé (STR) : le champ reason contient un exposé substantiel couvrant les cinq éléments obligatoires.
Contrôle des codes indicateurs (STR) : toutes les valeurs de indicator_codes figurent dans la liste de référence actuelle des indicateurs du FRC.
Validation par rapport au schéma XSD : passez le XML dans un validateur XSD local, par rapport au schéma XSD goAML v5.0.2, avant de le téléverser.

Pourquoi un moteur de validation détecte les erreurs avant que le FRC ne les voie

Un moteur de validation goAML conçu à cet effet applique les deux niveaux de validation — conformité au schéma XSD et conformité aux règles métier du FRC du Kenya — à votre fichier XML avant même qu'il ne quitte votre institution. Le moteur de validation connaît :

Chaque champ obligatoire et son format requis
Chaque valeur d'énumération du schéma
La règle de format du National ID du FRC du Kenya
Le registre des codes d'agence de la CBK
Le numéro d'enregistrement de votre institution auprès du FRC
La liste de référence actuelle des codes indicateurs du FRC
La norme de contenu minimale des exposés de FT

Lorsque le moteur détecte une erreur, il interrompt le circuit de transmission et présente l'erreur avec une description en anglais simple et la correction de données précise à apporter. L'analyste conformité corrige les données, régénère le XML, et le moteur de validation s'exécute de nouveau. Seul un fichier qui passe toutes les validations est proposé pour transmission.

Cette approche fait passer la validation du statut d'activité de diagnostic postérieure au rejet à celui de point de contrôle qualité préalable à la transmission. Résultat net : les erreurs sont détectées et corrigées au sein de votre propre processus, avant même que le portail ne voie le fichier.

Des rejets routiniers aux rejets quasi nuls grâce à la validation automatisée

Passer d'une génération manuelle du XML à une validation automatisée change l'endroit où les erreurs sont détectées. Les contrôles que le portail du FRC effectuerait à la réception s'exécutent d'abord au sein de votre institution : un fichier comportant une erreur de schéma ou de règle métier n'atteint donc jamais le portail. Le cycle de reprise se réduit à la correction des données à la source, la pression des délais qui accompagne les nouvelles soumissions répétées s'atténue, et les analystes conformité réorientent leur temps du débogage XML vers le véritable travail de conformité — examen des dossiers, analyse des tendances, préparation d'exposés de qualité.

Un taux de rejet élevé n'est pas une fatalité de la déclaration goAML. C'est la conséquence prévisible de l'application d'un processus manuel à une norme hautement technique. La validation automatisée fait de la réussite dès la première transmission la règle.

Quand saisir directement le FRC

Si le portail ne fournit aucun message d'erreur clair

Si le portail du FRC répond à votre transmission par un message d'erreur générique (« la transmission n'a pas pu être traitée ») sans générer de fichier d'erreurs structuré, votre XML est peut-être si mal formé que le portail ne peut pas l'analyser. Dans ce cas :

Validez votre XML par rapport au schéma XSD goAML v5.0.2 à l'aide d'un validateur local (xmllint, XML Notepad ou le validateur en ligne de freeformatter.com)
Vérifiez que votre fichier XML est encodé en UTF-8, sans caractères d'indicateur d'ordre des octets (BOM)
Vérifiez que l'extension du fichier est .xml (et non .txt, .csv ou tout autre format)
Assurez-vous que le fichier a été généré sans caractères binaires ou nuls insérés par le processus d'export

Si le fichier passe la validation locale mais que le portail renvoie toujours une erreur générique, faites remonter le problème au service d'assistance du FRC.

Si votre XML valide est rejeté (problème possible du portail du FRC)

Il arrive que le portail du FRC rencontre des problèmes techniques qui entraînent le rejet à tort de transmissions valides. Parmi les signes qui peuvent l'indiquer :

Plusieurs institutions signalent simultanément le même type de rejet
Le code d'erreur de rejet est inhabituel et ne figure pas dans les orientations disponibles du FRC
Une transmission qui a passé toutes les validations préalables et qui avait déjà été transmise avec succès auparavant (même format, même institution) est rejetée pour la première fois

Si vous soupçonnez un problème côté portail, documentez soigneusement les preuves de votre validation préalable avant de contacter le FRC. Pouvoir démontrer que votre fichier passe la validation XSD renforce considérablement votre signalement.

Contacter le service d'assistance du FRC

Pour les problèmes techniques de transmission qui ne peuvent pas être résolus au moyen des outils en libre-service du portail, contactez directement le Kenya Financial Reporting Centre :

Site web : frc.go.ke (utilisez les coordonnées qui y sont publiées)
Portail goAML : goaml.frc.go.ke

Lorsque vous contactez le FRC au sujet d'un problème de transmission précis, indiquez : le numéro d'enregistrement de votre institution auprès du FRC, le numéro de référence de la transmission, les codes d'erreur reçus et une description des mesures que vous avez déjà prises pour diagnostiquer et résoudre le problème. Ce contexte permet au service d'assistance du FRC de vous aider plus rapidement.

Mettre fin au cycle des rejets pour de bon

Chaque transmission goAML rejetée peut être évitée. Les erreurs qui provoquent les rejets — formats de date erronés, National ID manquants, valeurs d'énumération non valides, exposés vides, numéros de référence en double — ne résultent pas d'une ambiguïté réglementaire complexe. Elles résultent d'un processus manuel de traitement des données et de génération du XML, mal adapté à la précision qu'exige le schéma goAML.

La plateforme goAML de Creodata brise le cycle des rejets en automatisant les deux niveaux de validation — conformité au schéma XSD et conformité aux règles métier du FRC du Kenya — avant que le moindre fichier ne soit transmis au portail du FRC. Le moteur de validation préalable de la plateforme exécute automatiquement chaque contrôle décrit sur cette page, à chaque fois, pour chaque déclaration.

Lorsque vous passez d'un processus de déclaration manuel à une plateforme automatisée, les rejets liés au schéma et aux règles métier cessent d'être un événement courant — car la machine vérifie le schéma à chaque fois, sans fatigue, sans étape oubliée et sans que la pression des délais n'incite à prendre des raccourcis.

Découvrez comment la plateforme goAML de Creodata ramène à un niveau quasi nul les rejets à la première transmission.

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

Articles connexes :