On 26 March 2026, the Saudi Central Bank moved open banking out of the sandbox. Account Information Services, Payment Initiation Services and Confirmation of Availability of Funds are now formally supervised activities requiring a SAMA licence, with firms expected to demonstrate adherence to standards covering API performance, data security, consent management and governance.
For anyone building a Saudi fintech product, that changes the first question of the project. It is no longer "can we connect to the banks" — it is "are we licensed to do the thing this feature does, and if not, who is".
Engineering context, not legal or regulatory advice. SAMA is the authority on licensing; confirm your position with it or with Saudi-qualified counsel before building.
How Saudi open banking got here
The sequence matters, because a lot of guidance still online describes an earlier stage:
- December 2020 — SAMA issues the Open Banking Policy.
- November 2022 — the Open Banking Framework launches.
- 2023 — open banking goes live for account information and payment initiation; the first third-party providers begin operating.
- 26 March 2026 — SAMA moves open banking from a controlled sandbox initiative to a formally supervised, licensed activity. Lean Technologies is reported as the first licensee.
The 2026 step is the one that changes project planning. A sandbox regime tolerates "build it and see". A licensing regime does not: the activity is either authorised or it is not, and the answer determines whether your product can exist in the form you drew it.
The three regulated services
The framework's technical standards cover three service types. Knowing which one a feature falls into is the difference between a licensing conversation and a straightforward build.
Account Information Services (AIS) — reading a customer's account data with their consent. Balances, transactions, account details. This is what powers budgeting apps, affordability checks, accounting integrations and any "connect your bank" flow that displays data.
Payment Initiation Services (PIS) — initiating a payment from a customer's account with their consent. Pay-by-bank checkout, bill payment, account-to-account transfer.
Confirmation of Availability of Funds (CAF) — a yes/no answer on whether a specific amount is available. Narrower than AIS, and deliberately so: it answers one question without exposing the balance.
Most product ideas that sound like one thing turn out to touch two. "Let users pay from their bank account and show them their balance first" is PIS and AIS. Map each feature to a service type early — it is cheaper than discovering the mapping during a licensing conversation.
Building as an unlicensed party
The obvious question for a product team: can we build this without a licence?
There are legitimate routes, and one that is not.
Work through a licensed TPP. The most common commercial answer. A licensed provider holds the regulatory relationship and exposes the data or payment capability to you. Your product is a consumer of their service. This is a genuine pattern, not a loophole — but understand that your product's continuity now depends on that partner's licence, and the contractual and operational dependency deserves real diligence.
Build for a licensed institution. Banks and licensed firms build open banking capability, and someone builds it for them. The licence sits with the client. Much of the engineering described here applies unchanged.
Seek a licence. A real option for a company whose whole business is the regulated activity, and a project of its own with a timeline that is not an engineering timeline.
What does not work is shipping the regulated activity unlicensed and describing it as something else. Screen-scraping a bank on a customer's behalf, or holding their credentials, is not a technical alternative to AIS — it is the same activity performed worse, and the framework exists in part to end it.
What the standards mean for engineering
SAMA's security profile is reported to align with the Financial-grade API (FAPI) standard — mutual TLS, signed request objects, and strong consent management. Treat the specifics as something to verify against SAMA's current technical standard rather than from secondary summaries, but the shape is clear enough to design against.
Mutual TLS makes certificates a production concern. Both ends authenticate. You will hold client certificates per bank or per environment, with their own issuance, storage, expiry and rotation. Certificate expiry is the single most predictable outage in this class of system, and the one most often left to be discovered.
Signed request objects mean the request itself is a signed artefact, not just a payload over a secure channel. The signing key needs the same custody discipline as any other production key — not in config, not in the repository, not copyable by a person.
Consent is a first-class domain object, not a checkbox. It has a scope, a grant time, an expiry, a revocation state, and a customer who can withdraw it at any moment. Modelling consent as a boolean on the user row is the mistake that makes everything afterwards hard. Model it as its own record with a lifecycle, log every state change, and make revocation genuinely stop the data flowing — including anything cached or derived.
API performance is explicitly in scope. SAMA's framework names API performance among the standards firms must adhere to. Availability and latency are therefore not only product qualities but regulatory ones, and they need measuring and retaining as evidence rather than merely alerting on.
Data minimisation is the strongest default. Bank transaction data is about as sensitive as consumer data gets, and it falls under Saudi data protection obligations — see Saudi PDPL for application architecture. Pull what the feature needs, keep it only while the feature needs it, and keep derived results rather than raw statements where the product allows. Where that data may physically live is its own question — Saudi cloud data residency.
Riyadh, specifically
Saudi financial services concentrate in Riyadh — SAMA, the major banks, the Financial District, and the regulatory and partnership conversations that determine whether a fintech product ships. For a build that depends on a licensed partner or a bank relationship, that proximity is a practical input into delivery, not a marketing line: the meetings that unblock integrations happen there.
The counterpart is that the Saudi fintech market is now a licensed market with incumbents in it. The opportunity is less "be first" than "be correct" — products that handle consent, revocation, error states and reconciliation properly are distinguishable from those that do not, and the regulated environment makes that difference visible. For payment rails beyond open banking, see our guide to mada, STC Pay, Apple Pay and BNPL, and for building in the city, app development in Riyadh.
Frequently asked questions
What changed on 26 March 2026?
SAMA moved open banking from a sandbox initiative to a formally supervised activity. Firms offering AIS, PIS or CAF must hold a SAMA licence and demonstrate adherence to the framework.
Which services need a licence?
Account Information Services, Payment Initiation Services and Confirmation of Availability of Funds.
Can I build an open banking product without a licence?
Commonly, by working through a licensed third-party provider or by building for a licensed institution. What you cannot do is perform the regulated activity yourself unlicensed.
What are the licence categories and capital requirements?
We are not going to state figures we have not verified. Take these from SAMA directly or from Saudi-qualified counsel.
Is there a transition period for firms already operating?
Not something we could verify. Ask SAMA — this is exactly the question where a wrong assumption is expensive.
What technical standard applies?
SAMA's security profile is reported to align with FAPI, implying mutual TLS, signed request objects and strong consent management. Verify against SAMA's current published standard before building.
How should consent be modelled?
As its own entity with scope, grant time, expiry and revocation state — never a boolean. Revocation must actually stop data flowing, including from caches and derived stores.
Is screen-scraping an alternative?
No. It is the same activity done less safely, and the framework exists partly to replace it.