Uganda Open Finance Standard
An open API specification for financial interoperability in Uganda, including a USSD consent protocol so feature phone users are not excluded from open finance.
- Author and maintainer
- 2026
Uganda moves over UGX 326 trillion a year through electronic money channels, across more than 34 million active mobile money accounts. None of that infrastructure talks to itself through open standards.
MTN Mobile Money runs a proprietary system. Airtel Money runs a separate proprietary system. Every commercial bank runs its own integration layer. A fintech that wants to build a product working across MTN, Airtel, and two banks needs four separate integrations, four commercial agreements, four compliance reviews, and four maintenance burdens, for what is functionally the same operation.
Kenya is drafting its open banking standard now. Nigeria launched one in 2021. Rwanda published a roadmap in 2024. Uganda has none. So I started writing one, in the open.
What the specification defines
Account Information API. How a third party, with the user’s consent, reads balance and transaction history from any participating institution through one integration, whether that institution is a commercial bank, a mobile money operator, a SACCO, or a microfinance institution.
Payment Initiation API. How the same application, with the same kind of consent, moves money from any of those sources to any other, regardless of whether the source is a bank account or a mobile wallet.
A consent model. What consent actually means here: how it is granted, scoped, expressed as a signed and revocable artefact, and enforced end to end.
Alongside those: a security profile, a participant directory, mobile money extensions, OpenAPI 3.1 machine-readable definitions, and a governance document 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.
The part that could not be copied
The UK Open Banking specification, Brazil’s Open Finance framework, India’s Account Aggregator model, and PSD2 have proven these primitives in production, in far larger markets. UOFS borrows from all of them deliberately: 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 proven work.
But all of those standards share one assumption that does not hold in Uganda: that the user has a smartphone, a browser, and a stable connection. The OAuth 2.0 consent flow requires a browser redirect. Around 62% of Uganda’s mobile subscribers are on feature phones, and roughly 95% of mobile money traffic runs over USSD.
So the novel contribution is a USSD-compatible consent protocol, called the USSD Security Bridge in the spec. A feature phone user receives a consent request as a USSD push, sees who is asking, what is being requested, for what purpose and for how long, and approves or denies with a numeric input. The same cryptographic consent artefact is produced as in the smartphone flow.
What makes that hard
USSD messages cap at roughly 182 characters per screen. Sessions time out in 60 to 90 seconds. PINs are entered in plain text on screen, and the underlying SS7 channel is not end-to-end encrypted. Multi-screen consent flows invite drop-off, session hijacking, and shoulder surfing.
The design position is that this is not a reason to accept a degraded security model for feature phone users. It is a reason to move the security guarantees off the channel: the user consents to what a user can meaningfully consent to, and attestation, cryptographic binding, and delegated authorisation happen between participants in the background, secured by mTLS and signed artefacts rather than by the USSD channel itself.
Status
The specification suite is drafted: security profile, consent model, participant directory, both APIs, mobile money extensions, the USSD consent protocol, OpenAPI 3.1 definitions, and governance.
Not yet built: the reference implementation, the conformance test suite, and pilot institution relationships. Those are the three pieces that turn a document into infrastructure.
Everything lives in a public repository from the first commit, deliberately. A standard written and reviewed by one person bakes in one person’s blind spots permanently. The governance model specifies how decisions get made and who holds a veto, so participation does not require trusting me personally.