The common mistake is to treat open banking as an API publishing project. A bank exposes endpoints, a fintech connects to them, and the job appears finished. In reality, open banking saudi arabia requires a controlled operating model for customer consent, identity, data access, payment initiation, security, testing and ongoing service management.
For technology leaders, the important question is therefore not simply whether the organisation has APIs. It is whether its systems can grant the right access to the right regulated participant, for the right purpose, under a valid customer instruction, while producing evidence that the process worked as required.
That requirement sits inside the wider architecture of banking and financial services technology, because open banking touches channels, core banking, payments, identity, cybersecurity, data governance and third-party integration rather than operating as an isolated fintech interface.
What the Open Banking Saudi Arabia Framework Covers
The Saudi Central Bank, SAMA, describes its Open Banking Framework as a combination of use cases, business rules and technical standards. The technical component covers customer experience guidelines, API specifications, implementation requirements and operational guidelines rather than APIs alone.
This distinction matters when translating regulation into architecture. A compliant technical service must support the customer journey and business rules around access, not merely produce a technically valid JSON response.
SAMA initially structured the programme around Account Information Services, or AIS, followed by Payment Initiation Services, or PIS. The market continues to evolve: in September 2026, SAMA highlighted banks' readiness for Payment Initiation Services among the priorities discussed with the sector.
Technology teams should therefore avoid designing around a static interpretation of the framework. The safer model is to separate the regulatory business rules from the implementation components that may change as standards, use cases and certification requirements evolve.
At a systems level, the framework affects several connected capabilities:
-
Customer consent: The organisation must know what the customer authorised, for which service, and under what conditions.
-
API access: Approved participants need controlled access to the relevant account or payment capabilities.
-
Authentication and authorisation: Requests need to be correctly authenticated and permitted before sensitive information or payment functions are exposed.
-
Security controls: Customer information and credentials must remain protected during storage, processing and transmission.
-
Operational evidence: Systems need sufficient records to investigate failures, disputes, denied access and consent changes.
-
Testing and conformance: Implementations need to demonstrate that they behave consistently with the framework before production use.
The architecture should be designed around these obligations first. The API gateway is only one component inside that wider control model.
Account Information and Payment Initiation Services
AIS and PIS may use similar API infrastructure, but they create different technology and risk requirements.
SAMA's payments regulations define Payment Account Information Service as providing consolidated information about one or more payment accounts with the user's instruction and consent. Payment Initiation Service involves initiating a payment order at the user's request against an account maintained by a payment account service provider.
Account Information Services
AIS is primarily a controlled data-access problem. The fintech or other authorised provider needs access to defined account information, while the account provider needs confidence that the request relates to an authorised user and valid consent.
The design challenge is not simply retrieving account data. Systems need to understand which accounts the customer selected, which information may be returned, whether consent remains valid and what must happen when that consent changes.
SAMA's payment regulations require a Payment Account Information Service Provider to obtain user consent. They also require relevant data to be deleted when consent is withdrawn or cancelled, subject to other applicable legal retention obligations.
Payment Initiation Services
PIS moves the architecture from information access into transaction initiation. That raises different controls because a third-party service is triggering a payment process connected to the customer's account.
SAMA's rules require the Payment Initiation Service Provider to obtain consent, protect the user's security credentials, avoid altering the payment amount or payee, and limit access or storage of user data to what is necessary for the service. The provider must also communicate securely with the account provider and identify itself during each communication session.
For the bank, this means payment initiation cannot be implemented as a generic external API call into the payment engine. Authentication, authorisation, payment validation, fraud controls, transaction processing and customer communication need to remain connected throughout the journey.
Technical Requirements: APIs, Consent and Security
The technical architecture should keep three concerns separate but coordinated: API exposure, consent enforcement and security. Combining all three inside one custom application may appear simpler initially, but it makes future changes harder to govern.
APIs Need Governance, Not Just Endpoints
An open banking API is a contractual interface between regulated participants. Versioning, schemas, validation, error handling, availability, monitoring and change management matter because another organisation is building operational services around that interface.
This is where open banking becomes part of a wider enterprise API strategy. The bank needs a consistent model for publishing, securing, observing and changing external APIs without allowing each open banking use case to create its own technology pattern.
The API layer should also remain separated from core banking complexity. External consumers should not need to understand how many internal systems are required to construct an account response or execute a payment.
Consent Must Be Enforceable
A consent screen by itself is not consent management. The operational system needs a machine-readable record that downstream components can use when deciding whether an API request should be fulfilled.
That record should allow the institution to determine the customer, requesting party, approved purpose, relevant accounts or services, consent state and evidence needed to support later investigation.
SAMA's payments rules make customer consent a condition for access to payment accounts and require account providers to support secure communication and correct authentication and authorisation.
Security Must Follow the Transaction
Security cannot stop at the API gateway. A request may pass through identity services, consent stores, integration middleware, fraud controls, core systems and payment engines before a response is returned.
Each transition needs defined trust boundaries. Sensitive credentials should not become visible to systems that do not need them, and access decisions should remain linked to the participant and user context throughout the processing chain.
SAMA's rules explicitly require high standards for the secure storage, sharing and transmission of client data for account-information and payment-initiation services.
What Incumbent Banks Must Build
For an incumbent bank, the challenge is rarely the absence of technology. The challenge is connecting established banking systems to a new external-access model without weakening existing control boundaries.
A bank may already have APIs, identity platforms, mobile authentication, fraud systems and integration middleware. Open banking requires these capabilities to operate as one controlled journey.
-
API access layer: Expose permitted banking functions without exposing internal systems directly.
-
Participant validation: Establish which external participant is making the request and whether it should receive access.
-
Consent enforcement: Match the incoming request against the customer's valid authorisation.
-
Account connectivity: Retrieve the required information from authoritative banking systems.
-
Payment orchestration: Route authorised payment-initiation requests into the bank's existing payment controls.
-
Operational monitoring: Detect failures, rejected requests, performance issues and unusual behaviour.
-
Audit evidence: Preserve enough information to reconstruct what was requested, authorised and processed.
The difficult part is often the boundary between the modern API layer and existing banking platforms. That boundary should be explicitly designed through enterprise systems integration rather than allowing each open banking interface to create a separate point-to-point connection.
This also affects wider transformation decisions. The relationship between channels, payments, data, integration and core platforms is explored further in the context of banking technology consulting saudi arabia.
The architecture should protect internal systems from unnecessary external coupling. An API specification may change more quickly than a core banking platform, so the two should not have identical release dependencies.
What Fintechs Must Prove
Fintechs face the opposite side of the interface. They need to demonstrate that their service can consume open banking capabilities without treating access to bank data or payment functions as unrestricted application connectivity.
SAMA announced in March 2026 that it had begun licensing fintech companies to provide open banking services following completion of the regulatory sandbox process. SAMA also announced licences for companies providing account-information services, showing the move from experimentation towards regulated operation.
For technology teams, readiness should therefore be demonstrated operationally rather than through a prototype alone.
-
Consent integrity: The service can prove that access follows the user's current instruction.
-
Data minimisation: Applications request and retain only the information required for the approved service.
-
Credential protection: Sensitive authentication information remains protected from unauthorised access.
-
API resilience: The application handles timeouts, unavailable banks, validation errors and changing responses without creating misleading customer states.
-
Traceability: Requests and responses can be reconstructed sufficiently for operations, disputes and regulatory review.
-
Controlled change: New application releases do not silently expand data use beyond the authorised purpose.
A fintech should also separate customer experience from regulatory state. A screen may tell a customer that an account is connected, but the backend must independently know whether the underlying authorisation is still valid.
Consent Management and PDPL Interaction
Consent sits at the intersection of the Open Banking Framework and Saudi Arabia's Personal Data Protection Law, or PDPL. The two should not be implemented as unrelated checkboxes managed by separate teams.
The PDPL and its Implementing Regulations require processing purposes to be clear and specific when consent is requested. Consent must also be capable of later verification, and separate consent is required for separate processing purposes. Explicit consent is required in certain cases, including processing credit data.
This creates an architectural requirement: the consent record used to authorise open banking access must also make sense within the institution's wider personal-data governance model.
Where open banking journeys and privacy obligations need to be reconciled at system level, PDPL compliance advisory provides the related governance context rather than treating privacy as an API-layer issue.
Consent Withdrawal Is a System Event
Withdrawal should trigger more than a visual status change. Relevant systems may need to stop future access, invalidate active permissions, update downstream processing and determine whether stored information should be deleted or retained under another applicable legal obligation.
SAMA's rules for account-information providers explicitly connect consent withdrawal with deletion of relevant user data, except where other applicable obligations prevent deletion.
This lifecycle becomes easier to design when teams understand the wider privacy obligations around purpose, retention and data-subject rights. The detailed pdpl compliance saudi arabia guide addresses that broader layer separately.
The practical lesson is that consent should have an owner, a lifecycle and integration events. It should not live only inside the application that originally displayed the consent screen.
Testing, Certification and Go-Live
Open banking testing has to prove more than whether an endpoint returns a successful response. The service needs to behave correctly across normal journeys, invalid requests, consent changes, security failures and unavailable downstream systems.
SAMA's Open Banking Lab provides a technical environment where banks and fintechs can develop and test services against simulated banking APIs. SAMA also describes conformance suites used to test and certify APIs against the Open Banking Framework.
That makes conformance part of delivery planning rather than a task to leave until the production release is ready.
Test the Journey, Not Only the Interface
A useful test model should cover the full chain from customer action to bank response and back again.
-
Valid access: A correctly authorised request returns the expected information.
-
Expired consent: Access stops when the permission is no longer valid.
-
Wrong scope: A participant cannot obtain information beyond the customer's authorisation.
-
Unavailable dependency: The customer is not shown a successful state while a critical banking service has failed.
-
Payment rejection: The fintech receives an accurate result without inventing its own transaction state.
-
Recovery: Failed integrations can be retried safely without creating duplicate actions.
These behaviours depend heavily on the integration layer. The architectural patterns behind them are covered more broadly in enterprise systems integration.
Certification should also use the exact current framework version applicable to the participant. SAMA's Open Banking portal directs participants to its framework and lab, so implementation teams should avoid relying on old third-party summaries when preparing conformance testing.
Open Banking Readiness Checklist
Before treating the programme as an API implementation, technology leaders should test whether the organisation can answer the following questions clearly.
-
Define the regulated role: Establish whether the organisation is providing account services, account information, payment initiation or more than one role.
-
Map authoritative systems: Identify which platforms own accounts, customers, payments, consent, identity and audit information.
-
Map every consent state: Define creation, authorisation, expiry, withdrawal and any downstream processing triggered by those changes.
-
Separate API from core: Prevent external API changes from becoming direct changes to core banking interfaces wherever practical.
-
Trace each request: Make participant identity, customer authority, requested scope, result and failure state reconstructable.
-
Test security boundaries: Verify that credentials and customer information are visible only to components that genuinely require them.
-
Design failure behaviour: Decide how the service responds when banks, gateways, identity platforms or payment services are unavailable.
-
Prepare conformance early: Use the applicable SAMA framework and Open Banking Lab during development rather than at the end.
-
Align privacy controls: Connect open banking consent to the institution's PDPL governance, retention and deletion processes.
Once these answers are documented, teams can turn readiness gaps into an implementation sequence instead of a vendor feature list. A structured way to do that is to use our five-stage methodology to move from requirements and architecture through selection, implementation and validation before committing the programme to production.
The same principle applies beyond banking. Different regulated sectors place different demands on data ownership, integration, cybersecurity and privacy, which is why the wider industries we serve context matters when designing shared enterprise platforms.
The most useful change for a technology leader is to stop asking, “Do we have open banking APIs?” and instead ask whether the organisation can prove the complete transaction of trust: who requested access, what the customer authorised, what the participant was entitled to receive, which system supplied it, and what happened when conditions changed.
That is the real systems challenge behind open banking saudi arabia. API delivery is necessary, but production readiness depends on consent, identity, security, integration, operational evidence and conformance working together as one governed service.
For banks and fintechs, the framework should therefore be translated into architecture and operating controls before product selection or large-scale integration begins. That approach creates a system that can adapt as SAMA expands use cases and market requirements, rather than an implementation built around one release of one API specification.
Open Banking Saudi Arabia FAQs for Banks and Fintechs
What is required for open banking in Saudi Arabia?
SAMA's Open Banking Framework combines business rules, use cases and technical standards covering areas such as customer experience, APIs, implementation and operations. Banks and fintechs also need to address consent, authentication, secure data exchange and relevant payment regulations. The exact technical implementation should follow the current framework version applicable to the participant.
What is the difference between AIS and PIS in Saudi open banking?
Account Information Services provide consolidated information from one or more payment accounts based on the customer's instruction and consent. Payment Initiation Services allow a provider to initiate a payment order connected to the user's account, again based on consent. PIS therefore adds transaction-processing controls beyond the data-access requirements associated with AIS.
Does a bank need an API management platform for open banking?
The framework requires controlled technical interfaces, but the architectural answer is broader than buying one API product. Banks need capabilities for API lifecycle management, participant access, security, consent enforcement, monitoring and integration with authoritative banking systems. Existing platforms may provide some of these capabilities, so the correct design depends on the current technology estate.
How does PDPL affect open banking consent in Saudi Arabia?
Open banking consent controls access to specific financial services, while PDPL governs the processing of personal data more broadly. Saudi privacy rules require purposes to be clear and specific and consent to be capable of verification, with separate consent for separate purposes. Technology teams therefore need to align open banking permissions with wider data-governance processes.
How do banks and fintechs test open banking APIs before go-live?
SAMA's Open Banking Lab provides a technical testing environment with simulated banking APIs and conformance capabilities. Teams should test valid journeys as well as expired consent, invalid scope, downstream outages, payment failures and security conditions. Certification should be planned during development rather than treated as the final activity immediately before production.