On the Bank's own website, the 2025 Bank of Tanzania cloud guidelines are still a draft. The text the Bank lists among its banking guidelines is the one issued in December 2023, and on the question that decides an architecture the two agree: the live copy of a mission-critical system runs in Tanzania.
CloudSpinx designs and runs disaster recovery for regulated institutions in Kenya and across East Africa, and we read the instruments before we draw a second site. Four Bank of Tanzania texts settle where a Tanzanian bank's core system, its recovery copy and its email may each live: the 2023 cloud guidelines, the 2025 draft with the Bank's answers to the industry's objections, and the 2021 guidelines on business continuity and on outsourcing. They leave exactly one placement unnamed.
Which Bank of Tanzania cloud guidelines are in force?
The 2023 ones. The Bank's banking supervision page lists the Cloud Computing Guidelines for Financial Service Providers, 2023 next to the 2021 outsourcing and business continuity guidelines, and lists no 2025 version. The 2025 text sits in the Bank's consultation folder with its date line still blank beside the Governor's name, and the table of changes published with it is headed "Draft Revised Cloud Computing Guidelines". We found no signed copy and no commencement date.
For an architect the gap matters less than it looks, because the draft keeps the hosting bar almost word for word. Most of the rest is procedure. An institution already on cloud would get twelve months from commencement to apply for approval or stop. Each institution would also owe a standalone annual review of each provider's financial and operational condition, on top of the yearly due diligence its cloud policy already requires. And a sanctions clause would arrive, running from a civil money penalty on the institution or on the directors responsible up to revocation of the license, much the same ladder guideline 42 of the 2021 outsourcing guidelines already applies to outsourcing.
The change to read is in the definitions.
What counts as mission-critical, and who decides
The 2023 guidelines define a mission-critical system as one "essential to the survival of a financial service provider", reaching "any IT component (software, hardware, database, process, application, etc.)" that performs an essential function, and name the functions: "customer deposit management, granting of credit accommodations, trade finance, payments and settlements, and human resource management." Human resource management is on that list, so an HR system a bank might happily rent as SaaS sits on the same side of the line as the core. The non-critical examples are short: marketing and sales, budgeting, and collaboration.
The bar also catches "any other system whose data are considered critical for the operations of the financial service provider as determined by the Bank". Your architecture review does not get the last word. The Bank does.
The industry pushed back. The stakeholders' comment in the table of changes calls the definition "very wide and covering majority of the banking systems" and asks for a risk-based route to cloud. The Bank kept the definition, said it "aligns with similar definitions adopted by other SADC member states as well as India and Mauritius", and deleted the examples from both lists. The draft's mission-critical definition stops at "core functions", and its non-critical one becomes a test: a system whose failure "does not significantly impact business continuity". The stakeholders asked for a list they could argue from and lost the one they had.
The same table carries a line from the Bank's team that is blunter than either text: the guidelines "were designed for non-mission critical systems, and hosting mission-critical systems in the cloud is prohibited." The guideline only bars a provider whose infrastructure is outside Tanzania. The comment does not say outside, so we would not put a core system with a Tanzanian cloud provider on the text alone. A private cloud you build and own in your own data center is a different case on our reading, since the guidelines define cloud as servers "hosted on the internet by a third party", but guideline 6 applies "regardless of the type of Cloud hosting option adopted", private cloud included, so confirm yours with the Bank.
The cloud guidelines are issued under the National Payment Systems Act as well as the banking act and bind every institution "licensed, regulated, and supervised by the Bank", so a payment business the Bank licenses is inside them. The 2021 guidelines below bind banks and financial institutions only, but the Bank's table cites regulation 42 of the Payment Systems (Licensing and Approval) Regulations 2015 as putting a payment system provider's primary data center for payment system services in Tanzania too.
Where can a Tanzanian bank put its disaster recovery site?
In Tanzania, far enough from the primary that one event cannot take both, unless the Bank tells you otherwise in writing. That is our reading of three texts, and each stops somewhere specific.
The Business Continuity Management Guidelines 2021 make every bank and financial institution run a recovery site, not in the same building as normal operations or "unreasonably close" to them, "sufficiently remote from the primary site", with its own generator, UPS and fuel, and designed from the business impact assessment. Guideline 20 then says it flatly: "Every bank or financial institution shall establish its primary data center in Tanzania." It allows data center operations to be outsourced "within the country".
The 2021 outsourcing guidelines put a primary data center outside the country on the short list of things a bank may not outsource at all, next to credit decisions and the treasury function. Both rules say primary. Guideline 20's outsourcing sentence does not, but it permits outsourcing within the country rather than barring it abroad. None puts the recovery site in Tanzania in so many words.
The nearest is a line on offshore processing arrangements in the business continuity guidelines, which asks for a "reliable alternative recovery site preferably locally". Preferably is not shall.
The amber row rests on a comment in the Bank's own table of changes, not on guideline text, and a comment can be revised before the draft is signed.
A recovery copy with a cloud provider abroad is out all the same. The Bank's team calls mission-critical systems in the cloud prohibited, and on our reading the cloud limb of guideline 7 carries no "primary", so it bars any copy with a provider whose infrastructure is outside Tanzania. You can read "primary" across both limbs, but the Bank's comment leaves no room either way. So the third copy in a South African cloud region, a standard option in the DR designs we draw for Kenya, is the wrong design here.
A recovery site in a data center abroad, a rack in Nairobi say, is the one placement no text names. It is still data center operations outsourced outside the country, which BCM guideline 20 does not permit by name and BCM guideline 15 would rather you avoided, and an outsourcing that important needs the Bank's prior written approval anyway. If that is the design you want, put the question to the Bank in writing before anyone draws it.
CBK runs the other way on residency. Its outsourcing guideline sets no localization rule, and its approval process tests whether CBK can reach the records, not where they sit, so a group with banks either side of the border ends up with two recovery designs, not one.
If your recovery copy already sits outside Tanzania, or nobody can say which of your systems the Bank would call critical, that is the review we do. Send the system list through the DR scoping form and get each one placed against the four texts.
What the banks asked for, and what the Bank kept
The table of changes is worth reading in full, because it shows how the Bank answers an argument before you make yours.
The stakeholders asked to notify the Bank about non-critical systems instead of seeking approval. Refused: approval lets the Bank reassess the risk before you sign. Groups wanted cloud contracts kept at group level. Refused: each Tanzanian institution needs its own agreement. Others noted that Office 365 only runs on Azure and asked for a risk assessment in place of the vendor lock-in criterion, and that only a few providers are reputable, Microsoft and Amazon for example. Both criteria stayed, the concentration one "to avoid Single point of failure". The Bank gave ground twice: the twelve-month window, added because institutions already had systems on cloud, and a narrower clause on which provider changes you must be told about.
Under the 2023 text none of this stops email or collaboration going to the cloud, since collaboration is a named non-critical example. The draft drops the example, so each system's case rests on the business continuity test. Either way the approval request for a hosted suite such as Microsoft 365 arrives carrying what guideline 9 of the 2023 text asks for: a five-year cost plan with an on-premises comparison over the same period, the datasets and where their source and destination systems are hosted, the provider due diligence, and a way out that works. The contract is approved by the Bank before implementation, and the cloud policy goes to the Bank for clearance first.
Personal data leaving the country needs the data protection commission's transfer permit on top of all of it.
If every system you run already sits in your own Tanzanian data center and the recovery site is a second Tanzanian building, you do not need us. You need counsel to confirm the classification, because we are engineers reading the texts, not lawyers signing an opinion. We earn a fee on the estate that drifted: a recovery copy in a South African region, a core database moved to a provider's cloud, a group contract signed in another country. Send your license type and a list of systems with where the live and the recovery copy of each one runs, through the disaster recovery form or on WhatsApp at +254 713 403 044. In a free first session we go through each system against guideline 7, each placement against the four texts, and what an approval request would have to carry, and it commits you to nothing. The written gap review your board and the Bank can read is the scoped work after it. If a system has to come home to Tanzania, we plan that migration and run it alongside your team.