How to File a CTR with Kenya FRC: A Step-by-Step Guide

Filing a Cash Transaction Report (CTR) with Kenya's Financial Reporting Centre (FRC) is one of the most time-consuming compliance obligations facing bank analysts today. If you have ever spent hours extracting transaction data from your core banking system, cross-referencing customer KYC records, manually building an XML file, and then watched your submission bounce back with a schema validation error, you know exactly how painful the process can be.

This guide is written for compliance analysts and officers at Kenyan financial institutions. It walks through every step of the CTR filing process — from identifying qualifying transactions to receiving FRC acknowledgment — in plain, actionable language. Whether you are filing CTRs manually today or evaluating automation options, this guide will help you do it correctly.

---

Before You Start — What You Need

A CTR submission to Kenya FRC is not a form you fill in on the portal. It is a structured XML file built to the goAML XSD v5.0.2 schema, uploaded through the FRC's goAML portal. Before you open your core banking system, ensure you have the following in place.

FRC Registration and goAML Portal Access Credentials

Your institution must be registered with the FRC as a reporting entity under the Proceeds of Crime and Anti-Money Laundering Act (POCAMLA). This registration produces your FRC Entity Registration Number, which is a mandatory field in every CTR and STR you file. Without it, no submission will be accepted.

To access the goAML submission portal, your institution's designated Head of Compliance or Reporting Officer must hold active portal credentials issued by the FRC. Individual analyst accounts can be created under the institutional account. If your portal credentials have lapsed or you have never activated them, contact the FRC directly at info@frc.or.ke before attempting any submission.

Keep the following credentials and reference numbers accessible before starting:

• FRC Entity Registration Number (format: FRC/INST/YYYY/NNNN)
• goAML portal URL (provided by FRC on registration)
• Your portal username and password
• The FRC compliance officer contact name for your institution

Transaction Data from Your Core Banking System

The raw material for a CTR comes from your core banking system's transaction reports. Most Kenyan banks run Temenos T24, Flexcube, Finacle, or a local equivalent. You will need to pull a report that includes at minimum:

• Transaction date and time
• Transaction type (cash deposit, cash withdrawal, currency exchange)
• Transaction amount and currency
• Account number and account holder name
• Branch code and branch name
• Transaction reference number
• Teller ID or channel identifier (branch, ATM, mobile)

Ensure the report covers a full calendar day. Under Regulation 40(3)(c) of POCAMLR 2023 and FRC Circular No. 4 of 2023, CTRs must be submitted by the Friday of the week in which the qualifying transaction was conducted. A transaction on Monday leaves four business days to file; a transaction on Thursday leaves effectively one.

Customer KYC Data — National ID is Mandatory for Kenyan Nationals

This is the requirement that catches most institutions off guard during initial submissions. The goAML schema requires identity documentation for every party to a qualifying transaction. For Kenyan nationals, the National Identity Card number is mandatory — it cannot be substituted with a passport number, tax PIN, or any other identifier.

Pull the following KYC fields from your customer master records:

• Full legal name (as it appears on the ID document)
• Date of birth (YYYY-MM-DD format)
• ID type: NATIONAL_ID for Kenyan citizens, PASSPORT for foreign nationals, ALIEN_ID for registered aliens
• ID number: 8-digit numeric for Kenyan National IDs
• Nationality (ISO 3166-1 alpha-3 code: KEN for Kenya)
• Physical address (at least county and town)
• Phone number (optional but recommended)

If a customer's National ID is missing from your KYC records, do not file the CTR without it. Filing with a blank ID field will result in immediate schema rejection. Instead, trigger your KYC remediation process to obtain the ID before the three-business-day deadline, and document the delay reason in your compliance register.

---

Step 1 — Identify Transactions At or Above USD 15,000 (or Equivalent)

Kenya's CTR threshold is USD 15,000 or its equivalent in any other currency for cash transactions. The threshold is set by POCAMLA Section 44(6) and Regulation 40(1) of POCAMLR 2023, and was raised from USD 10,000 by the Anti-Money Laundering and Combating of Terrorism Financing Laws (Amendment) Act 2023 (effective 15 September 2023). Every cash deposit, cash withdrawal, or currency-exchange cash transaction equivalent to or exceeding the threshold must be reported — regardless of whether it appears suspicious.

Manual Identification from Transaction Reports

Without automated threshold detection, your daily CTR identification process typically looks like this:

1. Export the previous day's transaction journal from your core banking system to Excel or CSV
2. Filter for cash-handling transaction types: CASH_DEPOSIT, CASH_WITHDRAWAL, CURRENCY_EXCHANGE
3. Convert each transaction to USD using the institution's prevailing buying rate for that date
4. Filter for USD-equivalent amounts at or above 15,000
5. List each qualifying transaction separately — one CTR per qualifying transaction

This process works for low-volume institutions but becomes error-prone as transaction volumes grow, particularly where rates fluctuate intraday. A compliance officer managing a multi-branch network may be processing hundreds of cash transactions daily.

Same-Day Sub-Threshold Transactions: File an STR, Not an Aggregated CTR

A common misunderstanding of Kenyan CTR practice is the belief that same-day cash activity below the threshold should be summed and reported as a single CTR when the total crosses USD 15,000. The FRC's current position, set out in paragraph 4.3 of Financial Reporting Centre Circular No. 4 of 2023, is the opposite: sub-threshold transactions must not be aggregated for CTR purposes.

Where the pattern of sub-threshold activity looks unusual or suspicious — for instance, the same customer making several cash deposits on the same day in amounts just below USD 15,000 — the correct response under Circular §4.4 is to file a Suspicious Transaction or Activity Report (STR/SAR), not a consolidated CTR.

In practice this means your detection pipeline should have two separate triggers:

• A per-transaction rule: if any single cash transaction (converted to USD) reaches USD 15,000, create a CTR case.
• A structuring-pattern rule: if the same customer executes multiple sub-threshold cash transactions in a day, surface the case for STR review.

Foreign Currency Cash Transactions — Document the Rate Used

For transactions denominated in a currency other than USD, convert to USD using your institution's prevailing buying rate on the transaction date and document the rate in the CTR.

For example: a KES 2,000,000 cash deposit, converted at a KES/USD buying rate of 130 on the transaction date, produces a USD equivalent of approximately USD 15,385 — above the threshold. The CTR must report the original currency amount (KES 2,000,000), the applied exchange rate (130), and the USD-equivalent value.

Always record the rate date and source. If the rate used cannot be verified, the FRC may reject the submission or request supporting documentation.

---

Step 2 — Prepare the CTR Data Package

Before touching any XML, compile your complete data package. This preparation step prevents mid-build errors and ensures your XML generation process is smooth.

Complete Mandatory Fields Checklist

The following fields are mandatory for every Kenya FRC CTR. A missing value in any of these fields will cause your submission to be rejected at schema validation.

Optional but Recommended Fields

While not strictly mandatory at the schema level, the following fields significantly improve report quality and reduce the likelihood of FIU follow-up requests:

• Occupation: Customer's stated occupation from KYC records. Helps FIU analysts assess cash transaction plausibility.
• Physical address: County, town, and street. Important for geographic risk assessment.
• Phone number: Useful for FIU investigation follow-up.
• Email address: Increasingly included in newer FRC guidance for digital-channel customers.
• Employer name and address: Relevant for salaried account holders making large cash deposits.
• KES equivalent amount: For foreign currency transactions — include the converted amount and CBK rate used.

Including optional fields does not add filing complexity and materially improves the FRC's ability to process your reports without follow-up requests. Make it standard practice to include occupation and address for every CTR.

---

Step 3 — Generate the goAML XML File

The FRC's goAML portal does not accept spreadsheets, PDFs, or manually typed forms. It accepts only a valid XML file built to the goAML XSD v5.0.2 schema. Generating that file correctly is the most technically demanding part of the CTR process.

The goAML XSD v5.0.2 Schema Structure

The goAML schema is a hierarchical XML structure with over 200 possible elements organized across six nesting levels:

1. Report — the root container, holds report header fields (report type, date, reporting entity)
2. Transaction — one or more transaction records within the report
3. Party — individuals (persons) or entities associated with each transaction side
4. Account — the bank account linked to each transaction party
5. ID — identity documents for persons (National ID, passport, etc.)
6. Address — physical address records for persons and entities

Within the Transaction element, parties are assigned roles: from_person/from_entity for the debit side and to_person/to_entity for the credit side. For a cash deposit, the customer is typically the from_person and the bank is the to_entity. For a cash withdrawal, the roles reverse.

The schema enforces data types strictly. Date fields must be exactly YYYY-MM-DD. Currency codes must be exact ISO 4217 strings. Numeric amounts must have a decimal point. A single formatting deviation causes schema validation failure.

Manual XML Creation: Using a Text Editor or Excel-to-XML Macro

Some institutions attempt to generate CTR XML files manually — either by typing directly in a text editor or by using Excel macros that concatenate field values into an XML string. Both approaches carry significant risk:

• Text editors require the analyst to remember every element name, attribute, and nesting structure. A single misplaced closing tag invalidates the entire file.
• Excel macros can generate syntactically correct XML but typically cannot enforce schema data types, enumerated values, or mandatory field presence. The resulting XML may be well-formed but schema-invalid.
• Neither approach handles real-time currency conversion, FRC entity registration lookups, or Kenya-specific validation rules automatically.

Institutions using manual XML generation typically see rejection rates of 40–60% on first submission. Each rejection requires the analyst to locate the error, fix the XML, and re-upload — adding hours to the filing cycle.

Using an Automated Platform to Generate Validated XML from Your Data

An automated CTR reporting platform takes structured data (from your core banking export or direct API integration) and generates a schema-valid, FRC-compliant XML file automatically. The platform handles:

• Correct element naming and nesting
• Date format enforcement
• ISO 4217 and ISO 3166 code lookups
• Kenya-specific mandatory field enforcement (National ID, branch code)
• Per-transaction threshold detection against the USD 15,000 equivalent
• Structuring-pattern surveillance for STR review (separate from CTR generation)
• Unique report reference generation
• Exchange rate conversion for foreign currency transactions, with the rate and USD-equivalent recorded in the CTR

The result is a CTR-ready XML file that passes schema validation before it ever reaches the FRC portal.

---

Step 4 — Validate Before Submission

Submitting an unvalidated XML file to the FRC portal is the fastest way to accumulate a rejection backlog. Always validate your XML before uploading.

XSD Schema Validation — What It Checks

XSD (XML Schema Definition) validation confirms that your XML file conforms to the structural rules defined in the goAML XSD v5.0.2 schema file. Specifically, it checks:

• All mandatory elements are present and not empty
• Data types match (date fields contain valid dates, decimal fields contain numbers)
• Enumerated values are from the permitted list (e.g., transaction type is one of the allowed values)
• Nesting structure is correct (Party is inside Transaction, not at Report level)
• Element lengths do not exceed defined maximums

XSD validation can be performed locally using free tools such as xmllint (Linux/macOS), the XML Notepad validator (Windows), or online validators such as freeformatter.com. Most automated reporting platforms perform XSD validation as part of the file generation process.

Kenya-Specific Business Rule Checks

Beyond XSD schema validation, Kenya FRC enforces additional business rules that the XSD schema alone does not catch:

• National ID format: Kenyan National IDs must be exactly 8 numeric digits. Alphanumeric IDs, IDs shorter or longer than 8 digits, or IDs with spaces will fail.
• Channel classification: If the transaction was conducted via mobile money (M-PESA, Airtel Money, T-Kash), the channel must be classified using the FRC's mobile money channel codes, not generic CASH_DEPOSIT.
• Branch code registration: The branch code in the CTR must correspond to a branch registered with the Central Bank of Kenya. Unregistered branch codes cause business rule rejection.
• Reporting entity match: The reporting entity name and FRC registration number must exactly match the FRC's registered records for your institution. Slight name variations (e.g., "Ltd" vs "Limited") cause rejection.

Reading and Resolving FRC Error Codes

When the FRC portal rejects a submission, it returns an error notice containing specific error codes. The three most common categories are:

ERR_001 — Schema Validation Failure: The XML file does not conform to the XSD schema. This is always caused by a structural or data type issue in the file. Read the accompanying error detail to identify the specific element and line number. Fix the identified element and re-validate before resubmission.

ERR_012 — Mandatory Field Missing: A required field is present in the XML but contains an empty value, or is absent entirely. The most common trigger is a blank National ID number or a missing reporting entity registration number. Cross-check your data package against the mandatory fields checklist in Step 2.

ERR_045 — Business Rule Violation: The XML is structurally valid but violates a Kenya FRC business rule. This includes invalid National ID format, unrecognized branch code, mismatched reporting entity details, or a date outside acceptable range. Business rule errors require deeper investigation — check the FRC's published validation rules document for the specific rule cited in the error.

The Cost of Skipping Validation: 40–60% Rejection Rate at FRC

Institutions that skip pre-submission validation and submit directly to the FRC portal typically see 40–60% of their CTR submissions rejected on first attempt. Each rejection means:

• Re-opening the XML file and locating the error
• Fixing the data or structure issue
• Re-validating
• Re-uploading to the portal
• Waiting another 24–48 hours for FRC acknowledgment

For a compliance team filing 50+ CTRs per month, a 50% rejection rate translates to roughly 25 re-work cycles per month — easily 15–20 additional person-hours. Pre-submission validation eliminates virtually all of this rework.

---

Step 5 — Submit via the goAML Portal

With a validated XML file in hand, the FRC portal submission is straightforward.

Logging in to the Kenya FRC goAML Portal

Navigate to the FRC goAML portal URL provided to your institution during registration. Log in using your institutional credentials. If your individual analyst account is subordinate to the institutional account, you may need to switch to the reporting entity view before proceeding.

Confirm that the reporting entity displayed in the portal header matches your institution's registered name. Do not submit under the wrong entity context — this is a common error in institutions with multiple subsidiaries sharing a portal account.

Navigation: New Report → Upload XML → Confirm

Once logged in:

1. Select New Report from the main navigation menu
2. Select report type CTR from the dropdown
3. Select Upload XML File
4. Browse to your validated CTR XML file and select it
5. Review the pre-submission summary — the portal will display the report date, reporting entity, and number of transactions detected in the XML
6. Confirm that the summary matches your expected CTR data
7. Click Submit

Do not navigate away from the page during upload. On a slow connection, large CTR files (multiple transactions, aggregated daily reports) can take 30–60 seconds to upload and process.

Confirmation and Tracking Reference Number — Save It

After successful submission, the FRC portal displays a submission confirmation screen with a unique tracking reference number in the format FRC/CTR/YYYY/NNNNNNNN. This is your proof of timely submission.

Record this reference number immediately in your compliance register and internal case management system. You will need it if the FRC contacts you about the report, if the report is subsequently rejected, or if your institution is audited and required to produce filing records. Do not rely on browser history or email confirmations alone — maintain a dedicated CTR submission register.

---

What Happens After Submission?

FRC Acknowledgment Timeline

The FRC processes submitted CTRs and issues formal acknowledgment within 24–48 business hours of submission. During high-volume periods (month-end, quarter-end), processing may extend to 72 hours. The acknowledgment appears in your portal notification inbox and may also be sent to the registered email address on your institutional account.

Acknowledgment can mean one of two things: accepted (the report passed all validation and has been recorded in the FRC's system) or rejected (the report failed validation at the FRC processing stage). The portal will clearly indicate which outcome occurred.

Handling Rejection: Reading the Rejection Notice, Fixing Errors, Resubmission

If your CTR is rejected, the FRC issues a structured rejection notice that includes:

• The submission reference number of the rejected report
• One or more error codes (see ERR_001, ERR_012, ERR_045 above)
• A plain-English description of each error
• For schema errors: the XML element name and, where possible, the line number

Work through errors in order of priority: fix schema errors first (they may be masking business rule errors), then fix business rule errors. Once all errors are resolved, regenerate and re-validate the XML, then resubmit.

For resubmission of a previously rejected report, use the portal's Resubmit function (not New Report) and reference the original submission tracking number. This links the corrected report to the original filing record and preserves your timeline documentation.

FIU Feedback and Follow-Up Requests

For accepted CTRs that flag unusual patterns, FRC analysts may issue a follow-up information request through the portal. These requests typically ask for:

• Additional customer KYC documentation
• Source of funds declarations
• Transaction purpose documentation
• Enhanced due diligence records

Respond to FIU follow-up requests within the timeframe specified in the request notice (typically 5–10 business days). Delayed or incomplete responses can result in regulatory escalation. All responses should be logged in your compliance management system alongside the original CTR record.

---

Automating the Entire CTR Process

Manual CTR filing is time-consuming, error-prone, and difficult to scale. Compliance teams at growing financial institutions consistently report spending 20+ hours per month on CTR data preparation, XML generation, validation, and resubmission work — time that could be spent on investigation and case analysis.

An automated CTR reporting platform like Creodata's goAML platform changes the equation fundamentally:

• Automated threshold detection: The system monitors transactions in real time against the USD 15,000-equivalent threshold, applying currency conversion automatically, and separately surfaces sub-threshold structuring patterns for STR review.
• Automated XML generation: Validated, schema-compliant XML is generated automatically from transaction and KYC data — no manual assembly required.
• Pre-submission validation: Kenya-specific business rules (National ID format, branch code registration, channel classification, mandatory fields) are enforced before the file leaves your system.
• Complete audit trail: Every CTR — from detection through submission to FRC acknowledgment — is recorded in an immutable audit log.
• 0% rejection rate: Pre-submission validation catches every error that would cause FRC to reject the submission.

Institutions that move from manual to automated CTR reporting typically reduce CTR processing time by over 90% and eliminate first-submission rejections entirely.

---

Ready to Automate Your CTR Reporting?

Creodata's goAML platform is built specifically for East African financial institutions. It handles the full CTR lifecycle — threshold detection, XML generation, Kenya FRC business rule validation, portal submission, and FIU feedback management — in a single integrated system.

Book a demo to see how your institution can achieve 0% CTR rejection rate and save 20+ hours per month.

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

---

Related articles:

• goAML XML Schema v5.0.2: CTR and STR Mandatory Fields Reference
• goAML Submission Rejected? How to Diagnose and Fix Common Errors