Open banking in Namibia: what the standards say, and what they leave open

Where the document comes from

On 31 October 2022 the Bank of Namibia issued a position paper stating an intention to implement open banking through a legal framework, leading from open banking to open finance and open data. Konsentus, a consultancy, wrote the standards for the industry under the Bank’s control. Version 1.0 carries a final date of 25 April 2025. The document notes its content is not necessarily endorsed by the Bank, and says the timeline after the standards phase is undefined, with a live date expected in 2026.

The principles are short. The consumer must consent explicitly. Nobody shares credentials. The design should be simple and proportionate, and it should reuse what banks already do for online and mobile banking. An open banking interface is a new channel for existing services, not a source of new functions.

Roles and scope

Two roles do the work. A data provider holds the account, and in Namibia it will be a payment service provider licensed by the Bank. A third-party provider offers services based on the account holder’s data or payments. The third-party provider is the party which legally captures consent and answers to the account holder for the data, even when it uses a fourth party, such as an aggregator, to reach the interfaces. Providers must safeguard what they receive and use it only for the purpose the account holder asked for.

Phase 1 services are account information (list accounts, get balances, list transactions) and payment initiation (make a payment, list beneficiaries, check payment status). Eligible accounts are e-wallets, current accounts and savings accounts for consumers and small businesses, with credit cards and loans optional. Domestic payment types for phase 1 are on-us transfers, enhanced credit transfers and near real-time credits. Instant payments are marked as a future addition. RTGS, cards, debit orders and all cross-border types are not supported. A positive answer to a payment request means the institution accepted the instruction. It does not mean the payment arrived.

Consent and security in detail

Consent follows the authorisation code flow with proof key for code exchange. The third-party provider sends a pushed authorisation request, the account holder authenticates with the data provider and approves, and the provider issues a code, recommended to expire within ten minutes. Scopes are named: read basic account information, initiate a payment, read payment status. Consent ends on expiry, on revocation by the account holder through either party, or after at most 180 days. Screens must tell the account holder what is shared, with whom and for how long.

Security is mutual authentication. Every request and response uses mutual TLS. Participants carry a credential formatted as an X.509 certificate under ETSI specification 119 495, with the participant’s identifier in the subject, its role as data provider or third-party provider, and the national competent authority’s name and identifier. Participant identifiers take the form API plus six digits. Strong customer authentication has no standards-level minimum, because all data providers are regulated by the Bank.

Service levels are measurable. Data providers are held to 99.9 percent availability excluding a monthly maintenance window and a median response time of 300 milliseconds. A third-party provider is limited to four automated requests a day per account holder. Changes to interfaces need 180 days’ notice and 90 days in the test environment. Participants report transactions, service levels and disputes to the scheme manager each month.

What stays open

The standards say plainly what they have not decided. The scheme administrator, and whether it is the Bank or another body, is unspecified. Eligibility and capability criteria for both roles are marked future. Contract standards do not exist, the testing programme is out of scope, and incident and dispute standards are left to later work. Production pricing is to be decided.

These gaps are not criticism. They are the honest edge of a first version. They also set the work for the next one: a named administrator, admission rules, a testing route and an owner for disputes between the three parties who share one customer.

One account information request, step by step

The standards describe the flows in logical steps, which is useful for anyone testing an implementation. For a balance request, the account holder asks the third-party provider. The provider sends a balance request to the data provider. The data provider sends an authentication and authorisation request to the account holder, who confirms identity and consent. The data provider checks the consent and returns the balance to the provider, and the provider shows it to the account holder. In the more detailed version, the provider first asks for authorisation and receives a consent token holding the duration, scope, identity of the account holder, identity of the data provider, identity of the provider and status. It then presents the token with each request.

Payment initiation follows the same shape, with extra steps: the data provider checks the account has funds, the payer bank exists and the cut-off times allow the payment, returns the result, and later the provider asks for the payment status as often as needed. Negative flows are identical, with a negative response code and an error object.

Revocation has three paths. Consent expires. The account holder tells the provider, who destroys the token and notifies the data provider. Or the account holder tells the data provider, who marks the token inactive and rejects the provider’s next request with a failure code. The third path is the interesting one, because the provider keeps a token it believes valid until it tries to use it. A provider must therefore handle a refusal gracefully.

What the account holder must see

The standards set mandatory text at each stage. When subscribing to a third-party service, the account holder sees a statement the service is made within the scheme rules, the provider’s name and participant identifier, a link to the scheme’s web page and a link to the provider’s own support page. At the moment of request, the screen says who is asking to do what for how long. At the data provider’s authentication, the account holder sees the provider’s participation statement and the words: you are about to share, what, with whom, for how long. The standards add a rule against consent fatigue: a data provider should not require several consent steps for several account information actions with the same account holder and bank. The golden rule is stated plainly: if something is acceptable in the bank’s own app, it is acceptable through the interface.

Public information is part of the design. The scheme administrator is to publish a single page describing the mission, the participating providers and instructions for account holders with problems, and each participant links to it. The standards decline to propose a scheme brand, noting national schemes in other countries rarely carry customer-facing logos, but ask for consistent text.

What to build first

For a bank, the standards imply an order of work. Stand up a developer portal and a test environment which allows realistic testing without production data or funds. Issue and rotate participant certificates and test mutual authentication. Implement the consent flow and the revocation paths. Expose the three account information and three payment initiation services. Instrument the service levels and produce the monthly reports. Prepare for the testing programme, whose form is still undefined.

For a third-party provider, the order is similar: an interface client able to talk to each bank’s test and live portals, consent screens with the mandatory text, secure storage of tokens, and a plan for the four-requests-a-day limit, which rules out constant background polling. Providers should also keep the audit trail from the account holder’s request to the data provider’s response, because this trail is what settles a dispute among three parties who share one customer.

What this means for organisations in Namibia

A bank should plan to expose the phase 1 services through the same controls as its own channels, and should budget for certificate management and monthly reporting, because those are the parts new to most institutions.

A fintech planning to build on open banking should design consent screens to the document’s wording now, and should keep a position on who will certify it, because the standards do not yet say.