goAML Submission Rejected? How to Diagnose and Fix Common Errors

April 18, 2026

A 40–60% first-submission rejection rate on manually prepared goAML submissions is not an unusual statistic for Kenyan financial institutions. If your CTR or STR has just bounced back from the FRC portal, you are in good company — but that does not make the rework any less frustrating, especially when a filing deadline is approaching.

The rejection cycle is one of the most corrosive patterns in AML compliance operations. An analyst spends two hours preparing a submission, it is rejected, they spend another 90 minutes diagnosing and fixing it, it is rejected again for a different error, and two days have passed with nothing filed and the deadline looming. Meanwhile, the compliance manager is fielding questions about why the institution's filing timeliness metrics are deteriorating.

This guide breaks the cycle. It explains exactly how to read an FRC rejection notice, provides a numbered troubleshooting reference for the ten most common rejection causes, walks through the resubmission process, and shows you how to prevent rejections from occurring in the first place.

Understanding goAML Rejection Notices

What FRC Sends You When a Submission Fails

When the FRC's goAML portal rejects a submission, it generates a rejection response that is delivered in one of two ways depending on the nature of the failure:

Portal-level error message: If the file is malformed to the point that the portal cannot parse it at all — truncated file, invalid XML encoding, corrupted upload — the portal returns an immediate error message on the upload screen. This message is brief and often generic (e.g., "File could not be processed. Please check file format."). It does not contain detailed error codes. This type of error means your XML is not well-formed and needs to be checked at the structural level before you can proceed to schema or business rule diagnosis.

Structured rejection notice (XML error file): For files that are parseable but fail validation, the FRC portal generates a structured XML error response file. This file contains one or more error entries, each with:

An error code (e.g., ERR_001, ERR_012, ERR_045)
An error severity (FATAL, ERROR, WARNING)
An error message in plain English describing the specific problem
Where applicable, the XML element name and the value that caused the failure
For schema errors: the XPath location of the failing element within the XML tree

Download this error file from the portal's submission history — it is your diagnostic roadmap. Do not attempt to fix errors based on the portal's summary screen alone; the detail in the error file is essential for accurate diagnosis.

Reading the Error Codes: Schema Validation Errors vs. Business Rule Violations

goAML rejection errors fall into two fundamental categories, and distinguishing between them is the first step in diagnosis:

Schema validation errors (ERR_001 through ERR_009 range): These mean your XML file does not conform to the structural rules of the goAML XSD v5.0.2 schema. A date field contains a non-date value, a decimal field contains a string, a mandatory element is absent, an enumerated value is not in the permitted list. Schema errors are caused by the XML generation process — either the data preparation or the XML construction step. They are typically easy to diagnose because the error file identifies the exact element and value that failed.

Business rule violations (ERR_010 through ERR_099 range): These mean your XML is structurally valid and passes schema validation, but it violates a Kenya FRC-specific business rule. A National ID number is the wrong format, the reporting entity ID does not match FRC records, a branch code is not in the CBK registry, a TF-indicator STR has an inadequate narrative. Business rule errors require checking your data against external reference sources (FRC records, CBK branch registry, FRC indicator code list) — the fix is not in the XML structure but in the underlying data.

Priority: Fix Schema Errors First, Then Business Rule Errors

If your rejection notice contains both schema errors and business rule violations, fix the schema errors first. This is because schema errors can mask business rule errors — the portal may stop evaluating business rules after encountering a schema failure. Once your file passes schema validation, you will see the complete set of business rule violations rather than a partial list.

A common mistake is fixing one visible business rule error and resubmitting, only to find a different business rule error on the next attempt — because the schema error was hiding it. Work through the full error list methodically before resubmitting.

The 10 Most Common Rejection Reasons (and Fixes)

1. Missing National ID

Error code: ERR_045 (Business Rule Violation) Error message: "National ID number is required for parties with id_type NATIONAL_ID." Root cause: The customer's National ID number was not available in the KYC record at the time the XML was generated, or it was mapped to the wrong XML field. Alternatively, the ID number field was populated but left as a blank string, which passes schema validation but fails the business rule check for non-empty mandatory content. Fix: Retrieve the customer's National ID number from your KYC system. Verify it is exactly 7–8 numeric digits with no non-numeric characters. Populate the id_number element in the XML and re-validate. If the National ID is genuinely missing from your KYC records, initiate KYC remediation and document the gap before resubmitting. Do not substitute a KRA PIN, passport number, or phone number in the National ID field.

2. Invalid Date Format

Error code: ERR_001 (Schema Validation Failure) Error message: "Element <transaction_date> has value '25/03/2026' which is not a valid xs:date." Root cause: Date fields in goAML XML must be in ISO 8601 format: YYYY-MM-DD. A date exported from a core banking system in Kenyan date format (DD/MM/YYYY) or Excel's default format (25-Mar-2026) will fail schema validation. The error applies to any date field: transaction_date, report_date, date_of_birth, id_expiry_date. Fix: Reformat all date values to YYYY-MM-DD before inserting into the XML. If your XML is generated by a script or macro, add date format normalization at the data extraction stage — do not rely on the source system to export in the correct format. A regex pattern for valid dates is ^\d{4}-\d{2}-\d{2}$. Single-digit months and days must be zero-padded (e.g., 2026-03-05, not 2026-3-5).

3. Empty Narrative Text

Error code: ERR_001 (Schema) or ERR_045 (Business Rule) Error message: "Element <reason> must not be empty" or "STR narrative field does not meet minimum content requirements." Root cause: The reason field in an STR submission is empty, contains only whitespace characters, or contains a placeholder such as "narrative pending" or "N/A." This is the most preventable of all rejection reasons — it indicates an incomplete report was submitted. Fix: Write a substantive narrative before submitting. For guidance on what the narrative must contain and how to structure it, see How to Write an STR Narrative for goAML: Best Practices. Do not submit an STR without a completed narrative under any circumstances. If time pressure is a concern, submit with a brief but complete narrative covering the five mandatory elements, and follow up with supplementary information if needed.

4. Narrative Too Short (TF Cases)

Error code: ERR_045 (Business Rule Violation) Error message: "STR with TF indicator codes requires enhanced narrative. Current narrative does not meet minimum content standard." Root cause: The STR includes one or more TF (Terrorist Financing) indicator codes, but the narrative in the reason field is below the minimum content standard applied by Kenya FRC to TF-indicator reports. The practical minimum is approximately 500 words covering the full typology analysis including jurisdiction risk, counterparty identification, and institutional response. Fix: Expand the narrative to meet TF reporting standards. TF narratives must include: full subject identification, description of each suspicious transaction, explanation of why TF is suspected (not just ML), specific mention of high-risk jurisdictions or sanctioned parties involved, description of cross-border fund flows if applicable, and the institution's response including any account action and FRC notification. If your STR involves a genuine TF indicator, the narrative should naturally reach 500+ words when all required elements are covered.

5. Wrong Currency Code

Error code: ERR_003 (Schema Validation Failure) Error message: "Value 'Ksh' in element <transaction_currency> is not in the permitted enumeration." Root cause: The transaction_currency field requires an exact ISO 4217 three-letter currency code. Common Kenyan alternatives that fail include: Ksh, KSH, K.Sh, KE, KShs, Kshs. All are recognizable as Kenyan shillings to a human reader but are invalid in the schema enumeration. Fix: Replace all currency values with exact ISO 4217 codes. The code for Kenyan shillings is KES. Other currencies commonly seen in Kenyan bank transactions: USD (US Dollar), EUR (Euro), GBP (British Pound), UGX (Ugandan Shilling), TZS (Tanzanian Shilling). Add a currency code lookup table to your data preparation process to enforce correct codes at source.

6. Invalid Transaction Type

Error code: ERR_003 (Schema Validation Failure) Error message: "Value 'CASH' in element <transaction_type> is not in the permitted enumeration." Root cause: The transaction_type field accepts only specific enumerated values defined in the goAML XSD. Common invalid values seen in Kenyan CTR submissions include: CASH, DEPOSIT, WITHDRAWAL, CASH DEP, CASH WITH, TRANSFER. Even values that are clearly correct in intent fail if they do not match exactly. Fix: Use only the exact enum values permitted by the schema. For Kenya FRC CTR submissions, the valid transaction_type values are: CASH_DEPOSIT, CASH_WITHDRAWAL, CURRENCY_EXCHANGE. Do not use abbreviations, spaces within values, or variations in capitalization. If your core banking system exports transaction type codes in a different format, add a translation mapping in your XML generation process.

7. Missing Reporting Entity ID

Error code: ERR_045 (Business Rule Violation) Error message: "Reporting entity identifier does not match FRC registry. Field: reporting_entity_id." Root cause: The FRC Entity Registration Number in the XML either does not match the number registered with the FRC, or the field is absent or empty. Common causes include: transcription errors in the registration number, name format variations (the schema requires the exact name as registered), and submissions made under a subsidiary entity's FRC number when the parent entity's number was intended (or vice versa). Fix: Obtain your institution's FRC Entity Registration Number directly from your FRC registration certificate — the original document, not a remembered number. Copy it character for character into your XML. The format is FRC/INST/YYYY/NNNN. Confirm that reporting_entity_name in the XML also exactly matches the registered entity name. Store the correct number in your XML generation configuration file to eliminate re-entry errors.

8. Duplicate Report Reference

Error code: ERR_008 (Business Rule Violation) Error message: "Report reference number [value] has been previously submitted. Each submission must have a unique reference." Root cause: Your institution submitted a previous report with the same report_reference value. This can happen when: a rejected report is resubmitted using the Resubmit function but a new reference is erroneously generated, the same report is submitted twice due to portal navigation confusion, or your reference generation logic does not guarantee uniqueness (e.g., using a date-only reference without a sequence number). Fix for resubmission: When resubmitting a previously rejected report, use the portal's Resubmit function and reference the original submission ID — do not change the report reference number. The FRC tracks corrections under the original reference. Fix for genuine duplicate submission: Generate a new unique reference number. Update your reference generation scheme to include an incremental sequence number (e.g., NSBK-CTR-20260325-004) rather than a date-only or hash-based reference that may collide.

9. Invalid Indicator Code

Error code: ERR_045 (Business Rule Violation) Error message: "Indicator code [value] is not recognized in the Kenya FRC indicator reference list." Root cause: The indicator_codes field contains one or more codes that do not exist in the FRC's current indicator code reference. This occurs when: an analyst manually types indicator codes and makes a transcription error, codes from a different FIU's implementation are used (FATF generic codes vs. Kenya FRC codes), or the FRC has updated its indicator code list and your institution's reference list has not been updated. Fix: Obtain the current Kenya FRC indicator code reference list from the FRC directly or from the goAML portal's reference data section. Replace all invalid codes with the correct codes from the current list. If you maintain an indicator code lookup table in your compliance system, update it against the current FRC list. Consider adding indicator code validation to your pre-submission checklist.

10. Account Number Format Mismatch

Error code: ERR_045 (Business Rule Violation) Error message: "Account number format does not match expected pattern for reporting institution." Root cause: The account_number field contains a value that does not conform to the account number format registered by your institution with the FRC or CBK. This can occur when account numbers from different systems are combined (core banking account number format vs. CBK account format vs. international IBAN format), when leading zeros are stripped during data export, or when account numbers include branch codes or product codes that are not part of the pure account number. Fix: Confirm the exact account number format that your institution has registered with the FRC — this is typically the same format used in CBK regulatory reporting. Apply consistent formatting in your XML generation process: if your account numbers are 13 digits with leading zeros, ensure the export preserves leading zeros (common Excel issue). If your system stores account numbers with embedded branch or product codes, strip those components before including the account number in the CTR/STR XML.

How to Resubmit After Fixing Errors

FRC Portal Resubmission Process

The correct resubmission process depends on whether you are correcting a rejected submission or submitting an amendment to an accepted submission:

For rejected submissions: Navigate to your submission history in the FRC portal and locate the rejected submission by its reference number. Use the Resubmit option (not New Report) and upload your corrected XML file. The portal links the corrected file to the original submission record, preserving the filing timeline for deadline compliance purposes. Do not change the report_reference value in the corrected XML — the FRC needs to match the corrected report to the original.

For amendments to accepted submissions: If an accepted submission contained an error that you discover after acceptance, contact the FRC directly (see the escalation section below) before attempting to file an amendment. The FRC will advise whether a portal amendment, a supplementary STR, or a formal written correction is appropriate depending on the nature of the error.

Resubmission Within the Filing Deadline — Is It Still On Time?

Under Kenya's POCAMLA regulations, CTRs must be filed within three business days of the triggering transaction. STRs must be filed within three business days of the date on which suspicion arose. The FRC measures timeliness from the date of the triggering event to the date of first submission, not to the date of a successful resubmission.

This means that if your first submission attempt was within the three-day window but was rejected, your institution has still attempted timely filing. The rejection and resubmission are documented in the portal's submission history. However, if your first submission attempt falls outside the three-day window because of internal delays — not because of rejection and resubmission — there is no protection. File on time, fix errors on time, resubmit as quickly as possible.

Keep a record of your first submission attempt timestamp. In a regulatory examination or AML audit, this timestamp demonstrates timely filing intention even where the initial submission was rejected.

Documenting the Rejection and Fix in Your Compliance Audit Trail

Every rejected submission and subsequent resubmission must be documented in your institution's compliance records. The documentation should include:

The submission reference number and submission date of the rejected report
The error codes received and the error messages
The specific data corrections made and the source of the corrected data
The date and reference number of the successful resubmission
The name of the compliance officer who made the corrections and the name of the officer who approved the resubmission

This documentation serves two purposes: it demonstrates to regulators that your institution takes submission quality seriously and responds to rejections systematically, and it provides an evidence trail that is essential if the FRC raises questions about a specific report months or years later.

Preventing Rejections Before They Happen

Pre-Submission Validation Checklist (10 Checks)

Run through this checklist for every CTR or STR before uploading to the FRC portal:

Date format check: All date fields are in YYYY-MM-DD format with no exceptions.
National ID check: All Kenyan national party records contain a 7–8 digit numeric National ID in the id_number field.
Currency code check: All transaction_currency values are exact ISO 4217 three-letter codes (KES, USD, EUR, etc.).
Transaction type check: All transaction_type values are from the permitted enumeration.
Report reference uniqueness: The report_reference has not been used in any previous submission.
Reporting entity ID check: The reporting_entity_id exactly matches your FRC registration certificate.
Branch code check: All branch_code values correspond to CBK-registered branches for your institution.
Narrative completeness (STR): The reason field contains a substantive narrative covering all five mandatory elements.
Indicator code check (STR): All indicator_codes values are in the current FRC indicator reference list.
XSD schema validation: Run the XML through a local XSD validator against the goAML XSD v5.0.2 schema before uploading.

Why a Validation Engine Catches 99%+ of Errors Before FRC Sees Them

A purpose-built goAML validation engine applies both layers of validation — XSD schema compliance and Kenya FRC business rule compliance — to your XML file before it ever leaves your institution. The validation engine knows:

Every mandatory field and its required format
Every enum value in the schema
The Kenya FRC National ID format rule
The CBK branch code registry
The FRC entity registration number for your institution
The current FRC indicator code reference list
The TF narrative minimum content standard

When the engine finds an error, it stops the submission workflow and surfaces the error with a plain-English description and the specific data correction required. The compliance analyst fixes the data, regenerates the XML, and the validation engine re-runs. Only a file that passes all validations is presented for submission.

This approach moves validation from a post-rejection diagnostic activity to a pre-submission quality gate. The net result: zero first-submission rejections.

From 40–60% Rejection Rate to 0% with Automated Validation

Institutions that move from manual XML generation to automated validation consistently report the same outcome: first-submission rejections drop to zero within weeks. The rework cycle disappears. The filing deadline stress disappears. Compliance analysts redirect their time from XML debugging to actual compliance work — reviewing cases, analyzing patterns, preparing quality narratives.

The 40–60% rejection rate is not an inevitable feature of goAML reporting. It is the predictable outcome of a manual process being applied to a highly technical standard. Automated validation makes first-time success the default.

When to Escalate to FRC Directly

If the Portal Gives No Clear Error Message

If the FRC portal responds to your submission with a generic error message ("submission could not be processed") without generating a structured error file, your XML may be so malformed that the portal cannot parse it. In this case:

Validate your XML against the goAML XSD v5.0.2 schema using a local validator (xmllint, XML Notepad, or online validator at freeformatter.com)
Check that your XML file is UTF-8 encoded with no byte-order mark (BOM) characters
Verify that the file extension is .xml (not .txt, .csv, or any other format)
Confirm the file was generated without binary or null characters embedded by the export process

If the file passes local validation but the portal still gives a generic error, escalate to the FRC helpdesk.

If Your Valid XML Is Being Rejected (Possible FRC Portal Issue)

Occasionally, the FRC portal experiences technical issues that cause valid submissions to be rejected incorrectly. Indicators that this may be occurring include:

Multiple institutions reporting the same rejection type simultaneously
The rejection error code is unfamiliar and not documented in available FRC guidance
A submission that passed all pre-submission validation and has been submitted successfully before (same format, same institution) is rejected for the first time

If you suspect a portal-side issue, document your pre-submission validation evidence thoroughly before contacting the FRC. Being able to demonstrate that your file passes XSD validation strengthens your escalation significantly.

FRC Helpdesk Contact

For technical submission issues that cannot be resolved through the portal's self-service tools, contact the Kenya Financial Reporting Centre directly:

Email: info@frc.or.ke
Phone: +254 20 281 4000
Physical address: P.O. Box 9068 - 00100, Nairobi

When contacting the FRC about a specific submission issue, include: your institution's FRC Entity Registration Number, the submission reference number, the error codes received, and a description of the steps you have already taken to diagnose and resolve the issue. This context enables the FRC helpdesk to assist you more quickly.

Stop the Rejection Cycle for Good

Every rejected goAML submission is preventable. The errors that cause rejections — wrong date formats, missing National IDs, invalid enum values, empty narratives, duplicate reference numbers — are not the result of complex regulatory ambiguity. They are the result of a manual data handling and XML generation process that is poorly suited to the precision the goAML schema demands.

Creodata's goAML platform eliminates the rejection cycle by automating both layers of validation — XSD schema compliance and Kenya FRC business rule compliance — before any file is submitted to the FRC portal. The platform's pre-submission validation engine runs every check on this page automatically, every time, for every report.

When you move from a manual filing process to an automated platform, you move from a 40–60% rejection rate to zero. Not occasionally zero. Consistently, reliably zero — because the machine checks the schema every time, without fatigue, without missed steps, and without deadline pressure causing shortcuts.

See how the Creodata goAML platform eliminates first-submission rejections.

Request a Demo → https://www.creodata.com/demo

Related articles: