Uganda Has No Open Finance Standard. So I'm Writing One.

I have written two posts in the last few weeks about Uganda’s payment infrastructure. One argued that the Bank of Uganda’s Digital Drive Project will make the next mobile money outage worse unless it defines an offline authorisation profile before the switch goes live. The other argued that the AI factory being built at Karuma only becomes a real Ugandan asset if the missing middle of the digital stack (the settlement layer that lets ordinary people actually use it) gets built. Both posts ended pointing at the same gap. This post is about what I have decided to do about it.

Uganda has no open finance standard. Not “a weak one.” Not “one in draft with a public consultation.” None. As of 2026, there is no published Ugandan API specification that defines how a fintech, a SACCO, or a lender can, with a user’s explicit consent, read that user’s account information from any regulated institution through a common interface. There is no shared consent protocol. There is no participant directory. There is no conformance test suite. Every fintech that has ever built a product across MTN, Airtel, and a bank has done it by negotiating three separate bilateral integrations, three separate commercial agreements, three separate compliance reviews, and three separate maintenance burdens, for what is functionally the same operation.

I have started drafting a specification, in the open, and calling it the Uganda Open Finance Standard.

What it is

UOFS is a technical specification, published under a permissive open license, that defines three things.

First, an Account Information API: how a third-party application can, with the user’s consent, read balance and transaction history from any participating institution, whether that institution is a commercial bank, a mobile money operator, a SACCO, or a microfinance institution. Second, a Payment Initiation API: how the same application can, with the same kind of consent, move money from any of those sources to any other. Third, a consent model that defines what “consent” actually means in this context, how it is granted, how it is scoped, how it is expressed as a signed and revocable artefact, and how it is enforced end to end.

None of this is architecturally novel. The UK Open Banking specification, Brazil’s Open Finance framework, India’s Account Aggregator model, and the EU’s PSD2 technical standards have proven each of these primitives in production, in markets much larger than Uganda’s. UOFS draws directly on their designs: FAPI 2.0 for the security profile, the Indian Account Aggregator consent artefact for the shape of the signed consent object, Brazil’s 365-day consent duration for the lifecycle. There is no reason to reinvent what has already been built.

There is one place where it has to.

Where the copy-paste stops

The OAuth 2.0 consent flow (the mechanism through which a user in London or São Paulo authorises a third party to access their financial data) assumes the user is holding a smartphone, running a browser, and connected to the internet. The user is redirected from the third-party app to their bank’s login page, they approve the consent, and they are redirected back. The flow is elegant, secure, and well understood.

It is also inaccessible to a user interacting with their finances through USSD on a feature phone. Around 62% of Uganda’s mobile subscribers are on feature phones. Roughly 95% of mobile money traffic runs over USSD. Any open finance standard that fails for those users is not an open finance standard for Uganda. It is an open finance standard for the urban minority who already have alternatives.

So the novel technical contribution of UOFS is a USSD-compatible consent protocol: the specification calls it the USSD Security Bridge. A feature phone user receives a consent request as a USSD push, sees who is asking, what data or payment is being requested, for what purpose, and for how long, and approves or denies with a numeric input. Under the hood, the same cryptographic consent artefact is produced as on the smartphone flow. The security guarantees are the same. The interface adapts to the device the user actually has.

That protocol has real constraints to solve for. USSD messages cap at about 182 characters per screen. Sessions time out in 60 to 90 seconds. PINs are entered in plain text on the screen and the underlying SS7 channel is not end-to-end encrypted. Multi-screen consent flows risk drop-off, session hijack, and shoulder surfing. Solving these is not a matter of accepting a degraded security model. It is a matter of designing the flow so that the parts a user can meaningfully consent to are the parts the specification asks them to consent to, and everything else (attestation, cryptographic binding, delegated authorisation) happens between the participants in the background, secured by mTLS and signed artefacts, not by the USSD channel itself.

This is the part of UOFS that is genuinely mine to design. The rest is standing on shoulders.

Why one person, and why now

I am not Bank of Uganda. I am not a big-four bank. I am not a mobile money operator. I am one engineer who has spent enough time integrating into Ugandan payment systems, and enough time reading Brazilian, British, and Indian specifications, to have formed a strong opinion about what a Ugandan version should look like.

That is not enough. A specification written by one person and reviewed by one person will have one person’s blind spots baked into it permanently. That is why every research document, every draft, every design decision lives in a public repository from day one. That’s also why the entire point of this post is to invite the people who actually run these integrations, use them, or regulate them, to challenge what is there.

The reason to start now, rather than wait for a mandate, is that the alternative is starting later, when incumbents have already defined the standard in their own interest. Kenya is drafting its open banking API standard right now. Nigeria launched its Open Banking framework in 2021. Rwanda published a multi-year open finance roadmap in 2024 modelled on PSD2. Ghana and South Africa are active. Uganda is one of the largest mobile money economies on the continent (UGX 326 trillion moved through electronic money channels in the year to June 2025, on more than 34 million active accounts) and it is the only one of those neighbours without a published standard or a formal drafting process. Fewer than a quarter of African countries have any open banking framework at all. If nothing changes, the most likely outcome is that Kenya’s standard becomes East Africa’s de facto rail, and Ugandan institutions retrofit against a design that was optimised for a different country’s population profile.

I would rather Uganda’s version exist, be reviewed by Ugandans, and be shaped by the constraints Uganda actually has, including the constraint that a substantial share of the population will never touch a browser.

What is drafted, and what is not

The specification suite is drafted. That includes the security profile (FAPI 2.0 with Uganda-specific extensions), the consent model (with Data Protection and Privacy Act 2019 alignment), the participant directory, the Account Information API, the Payment Initiation API, the mobile money extensions, the USSD consent protocol, and OpenAPI 3.1 machine-readable definitions of both APIs. A governance document is drafted alongside them, modelled on the OBIE, Brazilian, and OpenID Foundation structures, with mandatory multi-stakeholder representation and no single institution type able to hold a majority of seats.

What is not drafted, yet, is the reference implementation, the conformance test suite, and the pilot institution relationships. Those are the next three pieces, and they are the ones that turn a specification from a document into infrastructure.

What I am asking for

If you work at a Ugandan financial institution (bank, mobile money operator, SACCO, MFI, or licensed PSP) and you have opinions about what this specification gets wrong, I want to hear them. If you have built or maintained an integration into MTN, Airtel, or a bank API and you know where the pain lives, that pain should be in the design; if it is not, the design has failed. If you are at Bank of Uganda, UMRA, NITA-U, or the Ministry of Finance and you see a regulatory conflict I have not accounted for, that is exactly the kind of feedback that has to land now, not after the standard is being implemented. If you are a consumer advocate and the consent model reads to you as designed for engineers rather than users, say so and I will fix it.

The full repository (research notes, specification drafts, OpenAPI definitions, and the governance document) is public. The governance model specifies how decisions get made and who has a veto, so nobody has to trust me personally. They have to trust the process, and the process is published.

The two posts before this one both ended by naming a specific missing piece of Uganda’s digital infrastructure. This one is about what I am trying to build in the space those pieces leave open. The Karuma AI factory, the Digital Drive Project, the National Payment Switch, the NIRA identity layer: those pieces are being built by people with billions of dollars and national mandates. The API layer that lets an ordinary Ugandan actually get value from them is where independent builders still have a seat at the table. That seat closes eventually. I would rather fill it while it is open.

If you want to help, the project lives at github.com/AropetJ/uganda-open-finance-standard. Open an issue, break the design, tell me what I got wrong.