Central Bank of Sudan: National Banking Portal

There are projects where the stakes are abstract — a metric goes up, a conversion rate improves, the quarter closes green. And then there are projects where the thing you’re building is the information layer for a country’s banking system.

The Central Bank of Sudan (cbos.gov.sd) is a central bank. Not a fintech startup wearing the word “banking” loosely. A national financial authority — the institution responsible for monetary policy, financial regulation, currency management, and the oversight of every commercial bank operating in Sudan. I contributed to the technical delivery of their public-facing portal during my time at Talentera, where I was on the lead side of technical execution.

What a national banking portal actually contains

This is worth being specific about, because “government website” undersells it considerably.

The portal carries:

Regulatory framework. Banking laws, BIS compliance guidelines, the published rules under which commercial banks operate. These are not blog posts. They are authoritative documents that banks and regulators reference to understand what is legally required of them. Getting the structure wrong — hierarchy, versioning, accessibility — has consequences that do not exist in consumer publishing.

Economic data and indicators. Exchange rates, inflation indicators, monetary supply statistics, trade balance figures. Published on official schedules. Required to be accurate, consistent, and available. A central bank’s published exchange rate is not a number you get wrong and quietly update. It is a reference figure that financial institutions, businesses, and individuals use to make decisions.

Publications and research. Annual reports. Trade statistics. Economic research. Documents that need to be findable, searchable, and consistently structured years after they’re published. The archive is not a nice-to-have; it is the institutional memory in digital form.

Payment systems information. SWIFT connectivity, interbank payment system documentation, currency denominations, the commercial bank locator. Infrastructure information that other institutions depend on to connect to the national payment network correctly.

Bilingual delivery, Arabic and English. Not a translation plugin. Full right-to-left Arabic layout, proper typography, and content parity between the two language versions. In a context where Arabic is the primary language of the country and English is the language of international financial communication, both versions have to be authoritative. “Auto-translated” is not a category that exists at this level.

The technical envelope

The stack was PHP on an enterprise CMS, which is the right call at government scale for reasons that often get dismissed by people who haven’t shipped at government scale: it’s maintainable by the institution’s own team after the delivery team leaves, it has a vendor support path that matters when the project lead changes, and it integrates with the content governance workflows that institutions of this kind already have. A bespoke modern stack that requires specialized knowledge to operate is not a gift to the client.

The secure portal layer was the technically interesting part. Not every document is public. Banking supervisory materials, certain regulatory communications, licensing documentation — access-controlled by institution and role, with an audit trail that satisfies the bank’s own internal compliance requirements. This is not a login page on a marketing site. It is an access control layer on documents that have legal and regulatory significance.

Performance and availability requirements are not optional when you are the Central Bank. Downtime is not a customer-satisfaction issue. It is an institutional reliability issue with real-world consequences for the entities that depend on the published information being there.

What I contributed

I was on the technical delivery side, leading on the implementation of content architecture, system integration, and the bilingual content model. The challenge with Arabic/English parity at this scale is not just switching dir="rtl" on a stylesheet. It is a content model question: how do you structure content such that an Arabic article and its English counterpart are explicitly linked, versioned together, and can be published and updated in parity without one version drifting from the other?

The answer involves a content model that treats the two language versions as siblings of the same entity rather than as separate documents, with explicit publication status tracking per language version. It sounds simple. Building it inside an enterprise CMS that wasn’t designed with that model in mind, for content that has institutional publication deadlines, is where the work actually lives.

Critical infrastructure is a different category

The thing I carry from this project is the weight of the dependency.

When you ship a feature on a consumer app and something breaks, users are annoyed and you push a fix. When the Central Bank’s exchange rate feed is inaccessible, financial institutions are making decisions — or not making decisions — because the authoritative source is down. The dependency is real and the institutions on the other end of it are not forgiving of “we had a deploy issue.”

This is what “critical infrastructure” means in practice. Not a marketing claim. A fact about the failure mode. You build accordingly: stability over cleverness, maintainability over novelty, explicit change control over continuous deployment.

I’ve shipped across healthcare (national EHR scale), fintech (regulated credit infrastructure), and government systems. The common thread is that the failure mode matters more than the technology choice. What breaks when this fails, who is affected, and how fast can you recover — those questions should drive every architectural decision. At the Central Bank, those questions have answers that are very concrete and very serious.

That’s the work.