goAML XML Schema v5.0.2: CTR and STR Mandatory Fields Reference

When a compliance officer submits a CTR or STR to the Kenya Financial Reporting Centre, the FRC's goAML portal does not receive a form or a spreadsheet. It receives an XML file that must conform precisely to the goAML XSD v5.0.2 schema — a machine-enforceable specification of every element, data type, length constraint, and structural rule that a valid report must satisfy.

Most submission rejections trace back to one of two root causes: the reporting institution's IT team generated an XML file that does not comply with the schema, or the compliance team prepared data that does not meet Kenya-specific mandatory field requirements that sit on top of the base schema. Both problems are preventable with the right reference material.

This article is that reference. It provides a complete, field-by-field breakdown of the mandatory XML elements for Kenya FRC CTR and STR submissions, the data types and format constraints each field enforces, and the Kenya-specific localization rules that apply beyond the base XSD. IT developers building XML generation pipelines and compliance officers reviewing data quality before submission will find everything they need here.

---

Understanding the goAML XSD v5.0.2 Schema

What XSD Schema Validation Means and Why It Matters

An XSD (XML Schema Definition) is a formal specification written in XML that defines the legal structure, element names, data types, value constraints, and cardinality (required vs. optional, minimum/maximum occurrences) for every element in a corresponding XML document.

When the FRC's goAML portal receives your XML submission, it runs the file through an XSD schema validator before any human analyst sees it. The validator checks every element in the file against the rules defined in the goAML XSD v5.0.2 schema. If any element violates any rule — a missing mandatory field, a date in the wrong format, a string that exceeds its maximum length, an enumerated value not in the permitted list — the validator returns a schema validation error and the entire submission is rejected.

Schema validation is binary: the file either passes completely or fails. A file with 99 correct elements and one malformed date fails just as definitively as a file with fundamental structural errors. This is why pre-submission XSD validation is not optional — it is the minimum standard for any CTR or STR generation process.

The Six Nesting Levels of the Schema

The goAML XSD v5.0.2 schema organizes report data into a six-level hierarchical structure. Understanding this hierarchy is essential for developers building XML generation code and for compliance teams reviewing XML output.

Level 1: Report — The root element of the XML document. Contains the report header fields that identify the report type, the reporting institution, the filing date, and the responsible compliance officer. Every CTR and STR begins with this element.

Level 2: Transaction — One or more transaction elements nested within the Report. Each Transaction element describes a single financial transaction, including its date, amount, currency, and type. A CTR report is generated per qualifying transaction at or above the USD 15,000 equivalent threshold. An STR typically contains one or more Transaction elements linked to the suspicious activity being reported.

Level 3: Party — Each Transaction contains Party elements that identify the individuals or entities on each side of the transaction. Parties are typed by their role: from_person or from_entity for the debit side, to_person or to_entity for the credit side. For a cash deposit, the customer is the from_person and the bank is the to_entity.

Level 4: Account — Account elements are nested within Party elements. They contain the account number, branch code, account type, and currency denomination of the account through which the transaction flowed. An Account element is required wherever an account number is known.

Level 5: ID — Identity document elements are nested within Person-type Party elements. They record the type of identity document (National ID, passport, alien ID), the document number, the issuing country, and the expiry date where applicable. For Kenyan nationals, the National ID element is mandatory.

Level 6: Address — Address elements are nested within Party elements (persons and entities). They record the country, county/state, city/town, and street address of the party. At minimum, country and town are required for Kenya FRC submissions.

Differences Between STR and CTR Schema Structures

Both STR and CTR reports use the same underlying goAML XSD v5.0.2 schema. They are differentiated by the value of the report_type element (CTR or STR) and by the specific mandatory fields that apply to each type.

For CTR, the mandatory focus is on precise transaction data: amounts, currencies, transaction types, and verified customer identity with a National ID. The narrative field is not applicable.

For STR, the mandatory focus shifts to the suspicion rationale: the reason field (the narrative) is mandatory and must be substantive; the is_suspicious flag must be set to TRUE; indicator codes must be populated; and the narrative must link transactions to a recognized AML typology. Transaction data is still required but the analytical content of the report carries greater schema weight.

Country-Specific Extensions in Kenya's FRC Configuration

The base goAML XSD v5.0.2 schema, as distributed by UNODC for use by all participating FIUs, contains a standard set of elements applicable globally. The Kenya FRC has configured the portal to enforce additional mandatory fields and business rules that are specific to Kenya's regulatory and financial environment. These include:

• Mandatory National ID for Kenyan nationals (the base schema treats ID as recommended, not required)
• Mandatory mobile money channel classification for M-PESA, Airtel Money, and T-Kash transactions
• Branch code must correspond to a Central Bank of Kenya registered branch
• FRC Entity Registration Number must be present and must match FRC records exactly
• Enhanced narrative minimum for TF indicator cases (500+ words in practice)

These Kenya-specific rules are enforced at the business rule validation layer after schema validation. A file can pass XSD validation and still fail FRC business rule checks.

---

CTR Mandatory Fields — Complete Reference

Table 1: Report Header Fields

Kenya-specific note on reporting_entity_id: The FRC Entity Registration Number format is FRC/INST/YYYY/NNNN. Even minor variations — trailing spaces, lowercase letters, omitting the slashes — cause ERR_045 business rule rejection. Copy the number directly from your FRC registration certificate and validate it character by character.

Kenya-specific note on report_reference: The unique report reference must not be reused across submissions. Most institutions use a format combining institution code, report type, date, and sequence number (e.g., NSBK-CTR-20260325-001). Duplicate references trigger rejection with error ERR_008.

Table 2: Transaction Fields

Kenya channel codes for mobile money transactions:

Note on transaction_type for mobile money: If a customer deposits cash at an M-PESA agent that is credited to a bank account, the transaction_type is CASH_DEPOSIT and the channel is MOBILE_WALLET_MPESA. The transaction type describes the nature of the cash movement; the channel describes the mechanism.

Table 3: Customer Identity Fields (Kenya-Specific)

Critical Kenya rule — National ID format: Kenyan National Identity Card numbers are exactly 8 numeric digits. No letters, no hyphens, no spaces. The format is NNNNNNNN. Common errors include:

• Submitting a 7-digit number (older cards issued before 1990 — these are still valid 7-digit IDs and should be submitted as 7 digits, not zero-padded)
• Including the cardholder serial number instead of the ID number
• Submitting a KRA PIN number (which begins with a letter) as a National ID
• Submitting a passport number for a Kenyan national when a National ID exists

For foreign nationals, the id_type must be PASSPORT and the passport number must be submitted. The FRC does not accept other foreign ID types as a substitute for a passport when reporting on non-Kenyan parties.

---

STR Mandatory Fields — Complete Reference

The STR uses the same schema structure as the CTR for transaction and identity fields. The additional STR-specific mandatory fields are concentrated in the report header (the suspicion reasoning section) and in the case analysis elements.

Note on reason field length: While the schema maximum for the reason field is 4,000 characters, the FRC business rule validation enforces practical minimums based on the indicator type. Standard ML cases: minimum approximately 200 characters (roughly 30–40 words). TF indicator cases: minimum approximately 3,000 characters (roughly 500 words). A narrative that meets the technical minimum but is inadequate in substance will pass schema validation but generate FRC follow-up requests.

Note on indicator_codes: Indicator codes must be from the Kenya FRC's published indicator code list. Submitting custom codes or codes from another country's FIU implementation causes ERR_045 business rule rejection. See the related article STR Indicator Library: AML Typologies for Kenya Banks (2026) for the current Kenya FRC indicator code reference.

Transaction fields for STR: All the same transaction fields from the CTR table above apply to STR submissions. The key difference is that an STR may link to transactions that individually fall below the USD 15,000 equivalent CTR threshold — the criterion for STR filing is suspicion, not amount.

---

Kenya-Specific Validation Rules

National ID Format Validation

As described above, Kenya FRC enforces strict format validation on National ID numbers. The validation rule checks:

1. ID type is NATIONAL_ID — field must contain exactly 7 or 8 numeric digits (7 for older IDs, 8 for IDs issued from approximately 1991 onwards)
2. No alphabetic characters, spaces, hyphens, or other separators
3. ID number must not be all zeros or a repeated single digit (e.g., 00000000 and 11111111 fail plausibility checks)

The most reliable way to pass this validation is to pull the ID number directly from a verified KYC source and run a format check before submission. Many banks maintain ID numbers in their KYC systems with leading spaces or concatenated with serial numbers — strip all non-numeric characters before including in the XML.

Mobile Money Channel Classification Rules

Kenya FRC requires mobile money transactions to be classified using the channel codes defined in Table 2 above. The classification rules are:

• Any transaction initiated via M-PESA, regardless of whether the ultimate source or destination is a bank account, must use MOBILE_WALLET_MPESA
• A bank-to-M-PESA transfer from the customer's bank account to their linked M-PESA number is classified as MOBILE_WALLET_MPESA
• An M-PESA agent cash deposit credited to a bank account is CASH_DEPOSIT with channel MOBILE_WALLET_MPESA
• ATM cash withdrawals must use ATM_CASH, not BRANCH_CASH
• Agency banking cash deposits (e.g., Equity Agents, Co-op Kwa Jirani) must use AGENT_CASH

Using the wrong channel code — or omitting the channel field for mobile money transactions — causes business rule rejection ERR_045.

TF Indicator Enhanced Narrative Length Requirement

For STRs that include any TF (Terrorist Financing) indicator code, Kenya FRC practice requires the reason field narrative to meet enhanced length and detail standards. While the XSD schema does not enforce a word count, FRC business rule validation flags TF-indicator STRs with narratives shorter than approximately 3,000 characters (roughly 500 words) for manual review and likely follow-up information request.

TF narratives must include, in addition to the standard five elements: the specific high-risk jurisdiction(s) involved, the names of any sanctioned entities or persons referenced in screening alerts, the channel and mechanism of fund transfer, and the institutional response including any account freeze or regulatory notification.

Mandatory Fields That Kenya FRC Enforces Beyond the Base XSD

The following fields are optional in the base goAML XSD v5.0.2 but are treated as mandatory by Kenya FRC's business rule layer:

---

Common XML Validation Errors and How to Fix Them

---

Automating XML Generation to Avoid Schema Errors

Why Manual XML Generation Leads to a 40–60% Rejection Rate

Every manually assembled XML file is a handcrafted artifact — and handcrafted artifacts introduce human error. The types of errors that cause rejection are exactly the kinds of errors that humans make: a date formatted as DD/MM/YYYY instead of YYYY-MM-DD, an amount that includes a comma as a thousands separator, a transaction type value that is almost right but slightly off, a National ID with a leading space from the KYC export.

At institutions where XML generation is performed manually — whether in a text editor, Excel macro, or bespoke script — rejection rates of 40–60% on first submission are consistently observed. Each rejection adds 2–4 hours of rework to the filing cycle.

What an Automated XML Engine Does Differently

An automated XML generation engine, purpose-built for goAML schema compliance, eliminates these failure modes systematically:

• Schema-aware field mapping: Every input field is mapped to its exact goAML XSD element name. There is no manual transcription of element names.
• Data type enforcement at input: Date fields accept only valid dates and output them in YYYY-MM-DD format. Decimal fields strip formatting characters and enforce two decimal places.
• Enum validation: Transaction type, channel, and ID type fields are selected from the exact permitted enum values — no free-text entry.
• Kenya business rule enforcement: National ID format, branch code registration, mobile money channel classification, and FRC entity registration number matching are all validated before the XML is generated.
• XSD validation on output: The generated XML is validated against the goAML XSD v5.0.2 before it is made available for submission. Files that fail validation are not surfaced to the compliance officer until the underlying data issue is resolved.
• Per-transaction threshold detection with FX conversion: Each cash transaction is evaluated against the USD 15,000 equivalent threshold in real time, with the applied exchange rate recorded in the CTR.

The result is a submission pipeline that produces schema-valid, Kenya FRC-compliant XML files every time — with a rejection rate that approaches zero.

---

Build Your Submission Pipeline on a Reliable Schema Foundation

Understanding the goAML XML schema is the foundation of a reliable CTR and STR filing process. Whether your institution is building its own XML generation pipeline or evaluating a purpose-built platform, the field reference and validation rules in this article give you what you need to achieve first-submission success consistently.

Creodata's goAML platform handles the full schema compliance lifecycle automatically — from field mapping and data type enforcement through Kenya-specific business rule validation to XSD-validated XML output. Your compliance team focuses on the analysis; the platform handles the technical filing requirements.

See the platform in action with a live demo.

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

---

Related articles:

• How to File a CTR with Kenya FRC: A Step-by-Step Guide
• goAML Submission Rejected? How to Diagnose and Fix Common Errors
• How to Write an STR Narrative for goAML: Best Practices