On-Premises vs Cloud AML Platform: Which Is Right for African Banks?
For a European financial institution evaluating AML technology, the cloud vs. on-premises decision is largely a question of economics and IT strategy. Cloud providers offer robust data protection frameworks, GDPR-compliant contractual structures, and in-country data centres across most major EU jurisdictions. The regulatory environment is generally permissive of cloud deployment for non-sensitive workloads, with clear guidance on what constitutes acceptable cloud use for financial data.
For an East African bank, the same decision is considerably more complex. Regulatory data residency requirements are evolving and sometimes ambiguous. Cloud infrastructure in the immediate region is limited compared to Europe or North America. Internet connectivity reliability varies significantly between urban centres and rural branch networks. And the Central Bank's IT examiners have historically shown a preference for solutions they can physically inspect.
This guide helps senior compliance and IT leaders at East African financial institutions navigate the deployment decision with the full regulatory, technical, and economic context.
The Regulatory Context for Data Residency in East Africa
CBK Data Residency Requirements
The Central Bank of Kenya's Prudential Guidelines on Outsourcing and Cloud Computing require licensed institutions to ensure that customer data and transaction records remain subject to Kenyan legal jurisdiction. The specific requirements do not universally prohibit cloud storage of financial data — they require that cloud providers agree to contractual provisions enabling CBK examination access, that data is accessible from Kenya at all times, and that the bank maintains effective control over its data regardless of where it is stored.
In practice, CBK examiners have shown a range of comfort levels with cloud-based financial systems. Core banking systems are expected to run on dedicated infrastructure with proven resilience and recovery capabilities. Compliance and analytics workloads — including AML reporting platforms — are subject to less prescriptive guidance, but institutions are expected to have documented risk assessments supporting their deployment choice.
The Kenya Banking Act provisions addressing electronic records and the Proceeds of Crime and Anti-Money Laundering Act requirements for record retention both require that AML records be maintained in a retrievable format for prescribed periods. Cloud storage satisfies these requirements provided the contractual and technical arrangements ensure availability and integrity.
FRC Preference for On-Premise or In-Country Cloud
Kenya's Financial Reporting Centre has expressed a preference, in its supervisory communications, for AML compliance data to be stored on infrastructure subject to clear Kenyan jurisdictional control. This preference does not constitute a legal prohibition on cloud storage, but it is a factor that compliance-conscious institutions weigh seriously when preparing for FRC examinations.
The FRC's practical concern is access: in the event of an investigation or a data request, can the FRC obtain the institution's compliance records rapidly and without dependence on a foreign entity's cooperation? An on-premises deployment or a deployment in a Kenyan-domiciled cloud data centre satisfies this concern directly. A deployment in a European or US cloud region with data replication to Kenya also satisfies it, but requires more careful contractual documentation.
Tanzania FIST, Uganda FIA, Zambia FIC — Data Location Requirements
Across the region, the data residency picture is varied:
Uganda's Financial Intelligence Authority (FIA) and Bank of Uganda IT guidance require financial data to be stored in Uganda where feasible. The Ugandan cloud infrastructure ecosystem is less mature than Kenya's, making on-premises deployment the more commonly chosen path for Ugandan institutions.
Tanzania's Financial Intelligence Unit (FIST) and Bank of Tanzania guidance follow a similar pattern to Uganda, with a general expectation of data remaining within Tanzania's jurisdiction. Tanzania is an active ESAAMLG member with increasing scrutiny on the effectiveness of financial institutions' AML systems.
Zambia's FIC operates under the Financial Intelligence Centre Act and associated regulations that require AML records to be available for examination without unreasonable delay. The Zambia Information and Communications Technology Authority has issued guidance on cloud use that requires data classification and government notification for deployments involving personal data of Zambian citizens.
Rwanda's National Bank (BNR) and FIU have been more progressive in their approach to cloud and technology adoption, reflecting Rwanda's broader national technology strategy. The BNR's framework permits regulated cloud use for financial services with documented risk assessments.
How These Requirements Differ from GDPR in Europe
European institutions operating under GDPR have access to a mature, detailed regulatory framework for cloud data processing — including standard contractual clauses, adequacy decisions for specific jurisdictions, and detailed supervisor guidance from national data protection authorities. GDPR creates compliance complexity, but it also creates clarity.
East African regulatory frameworks for data and cloud are earlier in their development. Guidance is less detailed, supervisory practice is less consistent, and the regulatory environment is evolving rapidly. This ambiguity cuts both ways: it means that cloud deployments are not clearly prohibited, but it also means they are not clearly blessed. Institutions that choose cloud deployment must be prepared to defend their risk assessment to examiners who may have limited familiarity with cloud architecture.
On-Premises Deployment — The Case For
Complete Data Sovereignty
An on-premises deployment — servers, storage, and networking physically located in the institution's own data centre or co-location facility — provides the highest level of data sovereignty available. Transaction data, STR narratives, case files, and audit logs never leave the institution's physical infrastructure. There is no dependency on a foreign entity's contractual commitments, privacy policies, or response to legal process from foreign governments.
For senior compliance officers and audit committees concerned about the confidentiality of STR data specifically — which describes suspected money laundering by named individuals and entities — on-premises storage provides the strongest possible protection against inadvertent disclosure.
CBK/FRC Regulatory Preference and Audit Comfort
When CBK examiners or FRC supervisors visit an institution for an AML examination, an on-premises AML platform allows the compliance team to demonstrate the system directly, show the examiners the physical infrastructure, and provide immediate access to all records without any dependency on internet connectivity or third-party systems. This level of transparency builds examiner confidence and typically results in smoother examinations.
Institutions that have been cited in previous AML examinations for technology deficiencies often choose on-premises deployment for subsequent implementations specifically because it removes any cloud-related regulatory risk from the equation.
No Internet Dependency for Core Compliance Workflows
AML reporting platforms access the FIU portal over the internet for submission — but the daily compliance workflow (case creation, investigation, documentation, approval) does not require internet access. On an on-premises platform, compliance officers can work on cases even during internet outages, with submissions queued for transmission when connectivity is restored.
This resilience matters in East Africa, where internet connectivity — particularly for smaller cities and rural branch networks — can be less reliable than in major metropolitan centres. An AML platform whose entire operation depends on cloud connectivity creates a compliance vulnerability whenever connectivity is interrupted.
One-Time CapEx vs. Ongoing OpEx Comparison
The financial profile of on-premises deployment differs fundamentally from cloud subscription models. On-premises involves a significant upfront capital expenditure on servers, networking equipment, storage, and data centre infrastructure — typically $50,000 to $150,000 for a medium-sized institution, depending on existing data centre capacity. Ongoing costs are limited to maintenance, power, software licensing, and staff time.
For institutions with existing data centre infrastructure that can host additional workloads, the marginal cost of on-premises deployment can be substantially lower than a cloud subscription over a 5-year horizon. CFOs and board members from banking backgrounds often prefer the predictability of a capitalised asset over an indefinite subscription obligation.
On-Premises Deployment — The Challenges
Infrastructure Cost
Not every institution has an existing data centre capable of hosting a containerised AML platform. Institutions without dedicated server infrastructure face the full capital cost of procurement: physical servers with sufficient CPU and RAM for Kubernetes workloads, enterprise storage with backup, network infrastructure, UPS and generator backup, physical security, and environmental controls. In Kenya, a server procurement project for a mid-sized institution typically takes 8 to 16 weeks from purchase order to rack-and-stack completion.
IT Team Requirements
Running a containerised microservices platform on Kubernetes requires DevOps skills that not all East African bank IT teams possess. Container management, Kubernetes cluster administration, network policy configuration, secrets management, and rolling deployment procedures are specialist skills. An institution without existing DevOps capability must either hire or train staff before an on-premises deployment can be effectively maintained.
This is not an insurmountable obstacle, but it is a genuine capacity constraint that must be addressed in the implementation plan. Platforms designed specifically for on-premises banking deployment typically include implementation support, training, and optional ongoing managed services to bridge the capability gap.
Software Update Management
On-premises deployments require the institution to manage software updates — pulling updated container images, testing in staging, and deploying to production. This is a routine operational task in mature DevOps organisations, but it adds to the IT team's workload and requires a formal change management process. When a security vulnerability is patched or a regulatory schema update is released, the update must be applied promptly, which requires both technical capability and organisational responsiveness.
Disaster Recovery Complexity
Designing and testing a disaster recovery configuration for an on-premises AML platform requires thoughtful architecture. The institution must maintain a secondary infrastructure site (either an owned DR site or a co-location facility), replicate data from primary to secondary in near-real-time, and periodically test failover procedures. This DR infrastructure roughly doubles the infrastructure cost and requires ongoing DR testing discipline to ensure it actually works when needed.
Private Cloud Deployment: Azure Kenya Region
Azure Infrastructure for East Africa
Microsoft Azure operates the South Africa North region as the primary Azure data centre serving East Africa, located in Johannesburg. This is the closest Azure region to Nairobi with a full service catalogue and offers data residency within South Africa — which is within the African jurisdiction but not within specific East African countries' borders.
For institutions requiring in-country data residency for Kenya specifically, Microsoft has announced an Azure data centre in Kenya, which will provide full in-country data sovereignty when it becomes available. Until that point, the South Africa North region with appropriate contractual protections is the most practical Azure-based option for Kenyan institutions.
Azure data centres are ISO 27001 certified, SOC 2 Type II audited, and meet the physical and logical security requirements that CBK examiners apply to cloud deployments. Microsoft's Banking & Financial Services compliance documentation provides the evidence base for demonstrating regulatory compliance.
Managed Services Reducing IT Burden
The primary operational advantage of cloud deployment over on-premises is the elimination of infrastructure management. Azure Kubernetes Service (AKS) manages the Kubernetes control plane automatically — node provisioning, security patching, availability zone distribution, and scaling. Azure Database for PostgreSQL Flexible Server manages database availability, backups, and patching. Azure Service Bus provides managed message queuing with 99.9% uptime SLA.
For bank IT teams already stretched across multiple technology priorities, offloading infrastructure management to Azure managed services can be more than sufficient to justify the ongoing subscription cost.
Deployment Speed
Cloud deployment of an AML platform is substantially faster than on-premises deployment. Without the procurement and rack-and-stack lead time, the infrastructure can be provisioned through code in hours rather than weeks. A typical cloud deployment timeline from contract signature to production go-live is 4 weeks, compared to 8 to 12 weeks for on-premises (including infrastructure procurement).
For institutions facing regulatory pressure to implement AML automation quickly, cloud deployment's speed advantage is a material factor.
Hybrid Deployment — Getting the Best of Both
Use Case: Compliance Data On-Premises, Backups in Cloud
A hybrid deployment model stores primary compliance data — active cases, transaction records, STR/CTR case files, audit logs — on on-premises infrastructure, while using cloud storage for backup replication. This satisfies the CBK/FRC preference for primary data sovereignty while leveraging cloud economics and resilience for disaster recovery.
The primary AML platform services run on-premises. Nightly backups of the PostgreSQL database are encrypted and replicated to Azure Blob Storage (South Africa North or Kenya region). In a disaster recovery scenario, the platform can be recovered in the cloud with the most recent backup, accepting a recovery point objective of one day and a recovery time objective measured in hours.
Phased Migration Path for Banks Transitioning from Legacy
For banks migrating from legacy AML systems to modern platforms, a hybrid deployment allows a phased transition. The new platform is deployed in the cloud for new submissions and current period cases, while the legacy system continues to serve historical data queries. Over time, historical data is migrated to the new platform, and the legacy system is decommissioned. This avoids a big-bang migration cutover with its associated risk.
Decision Framework — Which Is Right for Your Institution?
| Factor | On-Premises | Private Cloud | Hybrid |
|---|---|---|---|
| Data sovereignty | Highest | High | High |
| CBK/FRC compliance comfort | Preferred | Acceptable | Acceptable |
| IT team required | DevOps team | Minimal | Moderate |
| Upfront cost | High CapEx | Low (OpEx) | Medium |
| Deployment timeline | 8–12 weeks | 4 weeks | 10–14 weeks |
| Scalability | Manual | Auto-scaling | Partial |
| Disaster recovery | Complex and costly | Built-in, managed | Medium complexity |
| Internet dependency | Low | High | Medium |
| Regulatory examination readiness | Easiest to demonstrate | Requires documentation | Moderate |
Implementation Considerations for Each Model
On-Premises Hardware Sizing
Hardware requirements depend primarily on transaction volume, the number of concurrent compliance users, and the frequency and scale of CTR batch processing. As a general guideline for East African banks:
Small institution (under 100,000 accounts, single country): 2x application servers (8 CPU cores, 32 GB RAM each), 1x database server (16 CPU cores, 64 GB RAM, 2 TB SSD), 1 TB SAN storage for backup.
Medium institution (100,000 to 500,000 accounts, 1–2 countries): 3x application servers (16 CPU cores, 64 GB RAM each), 2x database servers in high-availability configuration (32 CPU cores, 128 GB RAM, 5 TB SSD), 5 TB SAN storage with off-site replication.
Large institution (500,000+ accounts, multi-country): Professional sizing assessment recommended based on specific transaction volumes and batch processing requirements.
Cloud: Azure Subscription Requirements and FIU Connectivity
Azure deployments require an Azure subscription with appropriate resource quotas, a virtual network peering configuration for private connectivity, and network security group rules permitting outbound HTTPS traffic to the relevant FIU portal endpoints for each country. All inbound access to compliance services is authenticated through API keys and JWT — no compliance service is publicly accessible without authentication.
The FIU portals in Kenya, Uganda, Tanzania, Zambia, and Rwanda are all accessed over the public internet via HTTPS. Azure deployments connect to these portals through NAT gateway with a static outbound IP that can be whitelisted with the FIU if required.
Both Models: Kubernetes Setup, Backup Schedules, and Maintenance Windows
Regardless of deployment model, the AML platform requires:
- A Kubernetes cluster (on-premises: RKE2 or K3s on bare metal; cloud: AKS) with at least 3 nodes for high availability
- PostgreSQL 15 database with automated backup configured to run at least nightly, with backup retention of 90 days (minimum) to meet AML record retention requirements
- Container image registry (on-premises: Harbor or Docker Registry; cloud: Azure Container Registry) for storing and versioning service images
- Defined maintenance windows for platform updates, scheduled during off-peak hours and communicated to compliance team leads in advance
Take the Next Step
Creodata's goAML AML Reporting Platform is designed to deploy cleanly on-premises, in Azure, or in a hybrid configuration — with the same platform features and compliance capabilities regardless of deployment model. Our implementation team has delivered deployments across all three models in East African banking environments and can advise on the right fit for your institution's regulatory profile, IT capability, and timeline requirements.
Discuss your deployment requirements with our team: Request a Demo at creodata.com/demo