Scale at Speed™
English (Global)
French (Canada)
- KSA is expanding its Open Banking Framework beyond AIS to include PIS.
- PIS enables authorized third-party providers to initiate payments directly from customer accounts through secure APIs.
- To comply with SAMA’s PIS standards, banks need new technical capabilities in payment processing, API security, consent management, and ecosystem integration.
- The transition from AIS to PIS presents opportunities to support A2A payments, fintech partnerships, and improved customer experiences.
The State of Open Banking in KSA
The Kingdom of Saudi Arabia (KSA), under the strategic leadership of the Saudi Central Bank (SAMA), continues to advance its Open Banking Framework as part of Saudi Vision 2030. Designed to expand and modernize financial services, the initiative aligns with the Financial Sector Development Program (FSDP), a key program under Vision 2030’s broader digital transformation agenda. 1,2
Building on the success of Account Information Services (AIS) under the initiative, the next phase aims to implement Payment Initiation Services (PIS), which allows authorized third-party providers (TPPs) to directly initiate payments for bank customers. Marking a major architectural shift, this upgrade is set to create a consent-driven, API-enabled ecosystem where customer data supports market innovation, healthy competition, and inclusive financial services.
What Does This Mean for Financial Institutions?
For financial institutions across KSA, this upgrade presents both an opportunity and a challenge. It:
- Enables account-to-account (A2A) payments as an alternative to cards.
- Supports new TPP-led payment services.
- Improves customer experience through payment innovation.
- Mandates regulatory compliance with SAMA’s PIS standards.
In this context, banks’ initial focus should be on enabling third-party payment initiation through their existing payment infrastructure. Investment in these capabilities helps banks improve transaction efficiency and prepare for a broader role as the ecosystem evolves.
PIS transforms open banking from a data-sharing model into a transaction-enabled ecosystem, creating new opportunities for banks, fintechs, and customers alike.
Decoding KSA’s Open Banking Initiative
KSA’s open banking program comprises two key functional elements:
- Open Banking Framework: A comprehensive set of legislation, regulatory guidelines, technical standards, use cases, and business rules. It establishes the requirements banks must adhere to in order to provide open banking services.
- Open Banking Lab: A technical simulation-based environment designed to create, test, and certify open banking services. It provides a sandbox, mock data, and testing suites to ensure conformance with KSA’s Open Banking Framework.
Banks aspiring to offer open banking services must request access to both of these elements directly from SAMA.
A Phased Approach to Open Banking
With the framework and lab providing the foundation, the program follows a phased rollout across three stages:
- Design: The initial stage that defines the standards and requirements for the open banking service.
- Implementation: The second stage, in which banks build their services and test them against the required standards.
- Go-live: The final stage, in which the services enter the real-world environment.2
The Evolution of the Open Banking Framework
The first version of KSA’s Open Banking Framework focused solely on AIS.3 This version allowed TPPs to access information from retail and corporate accounts with customer consent.
Building on AIS, the latest version of the framework prioritizes PIS, enabling TPPs to initiate payments from customer accounts with authorization. Implementation of this version is still in progress, with banks actively using the framework and the Open Banking Lab to develop and test services before moving into production.
Customer Control Through the Consent Model
A notable feature of KSA’s Open Banking Framework is how it defines consent across service domains. Based on the applicable use case, these consents can also be viewed in terms of the customer action being authorized, whether for a single action or for ongoing access or multiple actions over a defined period.
The framework supports three consent types:
| Consent Type | What it means |
| Single-action / transaction-specific | Authorizes a specific customer action or transaction |
| Single-action, scheduled | Authorizes a single transaction scheduled for execution at a future date |
| Ongoing / multi-action | Supports ongoing access or multiple permitted actions within the consent’s defined validity and parameters |
These options provide TPPs with greater flexibility to access data without creating friction at every interaction. At the same time, revocation is built in as an important safeguard, allowing customers to withdraw consent either through the TPP application or directly with their bank.
Enabling PIS Compliance Through Banking Infrastructure
For banks that have not yet adapted their core banking infrastructure to support API-driven transactions, PIS compliance is likely to be more demanding. This is mainly because real-time payment initiation, including integration with KSA’s payment infrastructure, requires different capabilities from those used to provide account information through AIS.
To prepare for PIS implementation, banks need a comprehensive set of technical capabilities, including API design, security, payment processing, and ecosystem integration.3 The following table maps key capability areas and their implementation requirements.
| Capability Area | Implementation Requirements |
| API Layer and Functionality | ● Payment Initiation APIs aligned with SAMA open banking specifications ● Support for payment initiation, status tracking, idempotency ● JSON REST APIs, versioning, backward compatibility |
| Authentication and Authorization | ● OAuth 2.0 and OpenID Connect ● Strong Customer Authentication (SCA) ● Token lifecycle management |
| Security and Compliance | ● Financial-grade API (FAPI) security profiles ● Mutual TLS (mTLS) ● Data encryption and fraud controls |
| Consent and Customer Interaction | ● Payment-specific consent validation ● UI for authorization ● Audit trails and revocation |
| Payment Processing Integration | ● Integration with Saudi Arabian Riyal Interbank Express (SARIE) or equivalent ● Funds checks, execution, reconciliation |
| TPP and Ecosystem Management | ● TPP onboarding ● Certificate management ● API monitoring and sandbox |
Table 02: Core Capabilities for PIS Readiness3
PIS readiness requires banks to connect secure APIs and consent controls with existing payment systems to support third-party initiation.
Tech Mahindra’s Approach to Open Banking Infrastructure Development
Our open banking solution, powered by the Ozone API platform, provides financial institutions with a strategic roadmap and implementation support for PIS compliance. Helping banks meet the requirements within 8–10 weeks,3 the solution builds on existing banking systems to expedite implementation and reduce the need for extensive system replacement.
Here’s a rundown of the solution’s key offerings:
- Out-of-the-box SAMA-compliant Ozone API platform, including TPP Verification, Authorization Server, Reporting and Billing, Consent Manager, and standards-compliant APIs.
- Conformance testing preparation and API architecture rationalization to support PIS use cases.
- Real-time payment API build and KSA payment rail integration.
- End-to-end customer journey redesign for new use cases and support for SAMA certification.
With experience serving 250+ global clients and the expertise of 1,000+ integration specialists, we help banks build and manage their open banking capabilities. Our solution also enables banks to expand these capabilities as the ecosystem evolves from data sharing to payment initiation.
The Final Word
As open banking services expand in KSA, banks need a clear execution plan to meet SAMA’s PIS requirements. Aligning infrastructure, security, and customer journeys with these requirements helps banks achieve compliance and support payment innovation across the wider market.
Tech Mahindra’s open banking solution, powered by the Ozone API, helps banks in this pursuit. By supporting compliance, payment security, and service development, the solution provides a foundation for financial institutions to advance into the next phase of open banking.
TAGS:
Enterprise Applications
Digital Engineering Services
Consulting and Management Services
Banking & Financial Services
Frequently Asked Questions
Our FAQ section is designed to guide you through the most common topics and concerns.
PIS allows authorized third-party providers to initiate payments directly from a customer’s bank account after obtaining the customer’s consent. Unlike AIS, which focuses on accessing account information, PIS enables the transfer of funds through secure, regulated APIs.
AIS enables authorized providers to access account and transaction data with customer permission. PIS extends this capability by allowing authorized providers to initiate payments from a customer’s account, making open banking a transaction-enabled ecosystem rather than a data-sharing model alone.
Banks need payment initiation APIs, strong authentication mechanisms, consent management capabilities, fraud monitoring controls, payment processing integration, and secure connectivity with the broader open banking ecosystem. They must also support regulatory testing and certification requirements.
The framework supports single-action (transaction-specific), single-action (scheduled), and ongoing consent options. Customers retain control over how their data and payment permissions are used and can revoke consent through either their bank or the authorized third-party provider.
PIS can support new account-to-account (A2A) payment experiences, improve payment efficiency, enable innovative digital customer journeys, and encourage greater collaboration between banks and fintech providers while maintaining regulatory oversight and customer control.
