Market analysis

Bahrain open banking framework: dedicated interfaces and testing

Bahrain’s rules are unusually explicit about what banks owe AISPs and PISPs: a dedicated interface, a testing facility, uptime parity and core data access.

Bahrain’s open banking framework is not notable because it is abstractly pro-innovation. It is notable because the public rules are unusually concrete about what banks owe the ecosystem.

That makes Bahrain worth reading even if you are not building there first. In much Gulf coverage, “open banking” appears as a label attached to strategy documents and launch announcements. In the Central Bank of Bahrain’s material, it quickly becomes an operating model: who gets access, what interface the bank must expose, what data has to be shared, and what testing path must exist before a provider is fully live.

What the framework says at a high level

The Central Bank of Bahrain launched the Bahrain Open Banking Framework in October 2020 and said at the time that it followed comprehensive open-banking rules previously issued in December 2018.

The launch announcement defines two broad service categories:

  • Account information service, which lets customers access bank account information in an aggregated manner through a single platform
  • Payment initiation service, which lets licensed third parties initiate payments on the customer’s behalf

That is the familiar open-banking shape. What makes Bahrain stand out is what the rulebook does with it afterwards.

Banks must grant access on an objective, non-discriminatory basis

The CBB rulebook states that retail bank licensees must grant AISPs and PISPs access to customer accounts on an objective, non-discriminatory basis, using customer consent as the basis for that access.

That wording matters more than it looks.

It is one thing to say banks should participate in open banking. It is another to say, in the rulebook, that access criteria must be disclosed and applied objectively, and that access has to be extensive enough for AISPs and PISPs to operate in an unhindered and efficient manner.

That is the kind of language that changes programme design. A bank is not merely asked to make an API available; it is told how that access relationship has to behave.

Core customer data is meant to move, and mostly without a bank fee

The same rulebook section is unusually specific about data scope.

At the customer’s direction, banks are obliged to share, without charging a fee, the information they hold in digital form that the customer can access digitally. The rulebook expressly includes transaction data, Merchant Category Code information and product or service data that banks are required to disclose publicly.

Two limits are worth noting:

  • identity-verification support information does not have to be shared with a data recipient
  • banks may charge AISPs for value-added or aggregated data

For core open-banking use cases, though, the starting position is clear: ordinary customer-access data is supposed to move.

The data-history rule is also concrete. The framework requires access to 12 full months or 365 days of account activity and balances for a wide list of retail products, including current accounts, savings, cards, loans and electronic wallets.

That is enough specificity to shape real product decisions. “Open banking” here is not merely “some transaction history”. It is a published baseline for data depth and product coverage.

Bahrain pushes banks toward a dedicated interface

The CBB requires banks offering online-accessible customer accounts to establish at least one interface for AISPs and PISPs, and it says that interface must be a dedicated interface.

That is a meaningful design choice.

It means the third-party route is not treated as an informal extension of consumer online banking. It is a distinct operational surface, with its own technical documentation, communication requirements and service obligations.

For anyone used to vague policy statements, this is where Bahrain starts to look less like a future aspiration and more like a regime that had already decided what the plumbing should be.

The testing-facility rule is the line most markets do not publish

The most interesting requirement may be the one that rarely appears in high-level open-banking commentary.

Banks must establish and make available a testing facility for:

  • authorised AISPs and PISPs
  • firms operating in the CBB regulatory sandbox as open-banking service providers
  • AISPs and PISPs granted in-principle confirmation to proceed with licensing

Banks must also display a link to that testing facility on their website, and no sensitive information may be shared through it.

That is unusually useful because it acknowledges the real order in which ecosystems get built. Testing is not reserved for fully live participants. The framework makes room for firms that are still in sandbox or in-principle stages, which lowers the distance between regulatory progression and technical evaluation.

For teams assessing a market, that is one of the most practical lines in the whole framework.

Uptime parity is not optional

Bahrain’s rules also say that the dedicated interface made available to AISPs and PISPs must offer the same level of availability and performance, including support and contingency measures, as the interface the bank makes available to its own customers for direct online access.

That closes an easy loophole.

Without a rule like that, a bank can nominally “support” open banking while quietly making the third-party route slower, less reliable or less recoverable than its direct channel. Bahrain’s framework makes that harder by writing parity into the expectation and linking outages and deficiencies back into CBB reporting.

Why Bahrain looks like it went first

The launch announcement itself says the 2020 framework followed detailed rules issued in 2018. That is the simplest explanation for why Bahrain still reads differently from later Gulf frameworks.

It is not just that Bahrain announced open banking early. It is that the public materials show a market that had already committed to the operational questions:

  • what services exist
  • what access rights licensed providers get
  • what interface banks must expose
  • what data must be shared
  • how far testing access extends
  • what service level parity is expected

That makes Bahrain important in a regional comparison. The UAE is more centralised in its architecture. Saudi Arabia now has a clear licensing signal. Bahrain remains the one whose public rules are easiest to read as day-to-day obligations imposed on banks.

What to take from it

If you are comparing the Gulf, Bahrain’s framework is the clearest reminder that open banking is not one thing.

In some markets, the hard part is the central ecosystem and certification queue. In Bahrain, the public rulebook leans harder on the responsibilities of the account-holding institution: dedicated interfaces, testing facilities, access parity and concrete data-sharing obligations.

That is why a regional plan needs to start with market-specific implementation assumptions rather than a single “GCC open banking” slide.

Related: Open banking in the Gulf: UAE, Saudi and Bahrain compared

Sources

This article describes the public rules and framework materials, not the full private experience of integrating with a specific Bahraini bank. Where implementation hinges on the current wording of the rulebook, read the source itself.