In this essay
Saudi open banking is entering the part where product and operations matter more than the headline. On 17 September 2026, the Saudi Central Bank said its open-banking forum with banks focused on the next stage: bank readiness for Payment Initiation Services, business use of open banking, service quality, bank-fintech coordination and a more consistent customer experience.
That wording matters. Payment initiation is where open banking stops being only a data-access programme and becomes a money-movement product. A third party can help a customer start a payment from an existing bank account, but the bank, the fintech, the rail, the consent record and the exception process all have to agree on what happened.
The API is only one part of that readiness.
What SAMA actually signalled
SAMA's forum note is short, but it is specific. It does not say every bank is ready for every payment-initiation use case. It says the next-stage priorities include readiness for Payment Initiation Services, wider business use, better service quality, stronger bank-fintech coordination and a consistent customer experience.
That is a practical agenda. It recognises that payment initiation has more moving parts than account-information access.
In March 2026, SAMA announced the start of licensing for fintech companies to provide open-banking services after the regulatory sandbox phase. The licensing move creates the supervised perimeter. The September forum points to the operating model that has to work inside that perimeter.
A product team should read those two signals together: licence first, readiness next.
Why payment initiation is harder than data sharing
Account-information services can still fail in serious ways, especially around consent, security and data quality. But the customer harm is different. A broken balance view is a data problem. A broken payment initiation may debit the wrong account, strand a transaction, confuse a merchant, or create an exception nobody can explain.
That changes the product questions.
Which account is eligible. Which user can grant consent. Which limits apply. Which route is used. What happens if the preferred rail is unavailable. What the fintech sees when the bank rejects the request. What the customer sees when the fintech thinks the request succeeded but the bank has not completed the payment. Which party owns the support ticket. Which reference reconciles the payment after settlement.
If those answers are not written down, they will be discovered in production.
The readiness gates
There are six gates I would expect a bank-fintech payment-initiation programme to pass before scaling.
1. Account eligibility
The journey needs to know which accounts can be used for payment initiation, not merely which accounts can be displayed. Retail, SME and corporate accounts may have different mandates, approval rules, dormant-account handling and currency constraints.
The UAE Open Finance Standards are useful comparator evidence here. Their common rules separate account eligibility, payment-account selection and supported rails. They require LFIs to provide APIs for account types users can access in existing digital channels, and they also describe how dormant and inactive accounts should be filtered or rejected in the journey.
The Saudi framework will have its own rules, but the product lesson travels: eligibility is not a UI dropdown. It is a bank policy, risk rule and customer-experience control.
2. Consent and authority
Payment initiation needs consent that is specific enough to protect the customer and usable enough to avoid killing the journey. The product has to distinguish data-sharing consent from payment authority. It also needs revocation, evidence, expiry and a clear record of who authorised what.
That record is not only for compliance. It is the support artifact when a payer asks why a payment happened, or why it was refused.
3. Rail and fallback design
Payment initiation should not assume a single perfect rail. A bank may route a domestic payment over one instant-payment infrastructure, fall back to another system in a defined case, or reject the payment because a required data element is missing.
The UAE standards again show why this matters. They describe domestic payment initiation using Aani Core, fallback to an alternative system such as FTS in specific conditions, and rejection when required user data for the instant-payment platform is missing. That is not a Saudi rule, but it is a clear example of how rail fallback becomes a customer promise only if the rule is explicit.
For product teams, the question is simple: can the journey explain the difference between unavailable rail, unsupported account, missing data, failed authorisation and bank refusal?
4. Bank-fintech coordination
SAMA named coordination between banks and fintech companies as a next-stage priority. This is the part that often looks soft and turns out to be operationally decisive.
Coordination means common test cases, agreed error codes, escalation paths, service-level expectations, incident ownership, change-notice timelines and release calendars. Without those, each participant can be individually "ready" and the customer journey can still fail.
Open banking does not remove bilateral work. It changes what bilateral work should be about.
5. Service quality
Service quality is not a marketing phrase in payment initiation. It means latency, uptime, success rate, error clarity, repair time and reconciliation completeness. It also means the bank and the fintech look at the same evidence when something breaks.
The customer does not care whether the failure sat in consent, API gateway, bank core, payment rail or fintech checkout. The product still needs one explanation and one recovery path.
That is why payment initiation should have a shared operational scorecard before it has scale targets.
6. Business use cases
SAMA also named business use of open-banking services. That should push product teams beyond consumer aggregation and simple personal payments.
For SMEs, payment initiation can support invoice collection, supplier payments, payroll preparation, marketplace seller payouts, account-to-account checkout and cash-flow tools. Those journeys bring richer authority models: maker-checker approval, corporate mandates, ERP references, invoice matching, partial payments and role-based limits.
If the first version only handles a single retail payer approving a simple transfer, it may prove the rail but not the business product.
The evidence operators should keep
Payment initiation creates a new evidence chain. At minimum, each completed or failed initiation should preserve:
- consent identifier and scope
- payer account selected
- payee details used
- amount, currency and reference
- route selected and fallback decision
- bank response and timestamp
- fintech response shown to the user
- final payment status and settlement reference where available
- error reason and owner when the payment fails
This is not audit theatre. It is how a team resolves disputes, reconciles funds and improves the journey without guessing.
What not to claim yet
The safe claim is that Saudi open banking has moved from sandbox and licensing into a readiness phase where payment initiation, business use, service quality and coordination are explicit priorities.
The unsafe claim would be that every Saudi bank is ready, that payment initiation is live everywhere, or that pay-by-bank will immediately replace cards. None of the cited sources prove that.
Open banking usually becomes real gradually: one use case, one bank cohort, one error dictionary, one support process at a time.
A practical launch checklist
Before scaling a payment-initiation journey, ask:
- Can the user see which account is eligible and why another account is not?
- Does the consent record distinguish data access from payment authority?
- Does the customer journey explain bank rejection without exposing internal jargon?
- Do bank and fintech teams use the same status taxonomy?
- Is there a tested fallback path when the preferred payment rail is unavailable?
- Can operations reconcile a payment from initiation to final settlement using one reference chain?
- Are business users supported with mandates, approval paths and invoice references?
- Is there a joint incident runbook with bank and fintech owners?
If those answers are missing, the programme may have an API integration, but it does not yet have a payment product.
The product lesson
Payment initiation readiness is a coordination test. The customer sees one button. Behind it sit consent, account eligibility, routing, bank controls, fintech experience, settlement and support.
SAMA's September forum is useful because it names the right work. The next proof will not be the number of APIs published. It will be whether banks and fintechs can make initiated payments reliable, explainable and recoverable when the happy path breaks.
FAQ
What is payment initiation in open banking? Payment initiation lets a licensed third party start a payment from a customer's existing bank account with the customer's consent. The bank still holds the account; the third party initiates the payment journey.
Is Saudi payment initiation fully live? The cited SAMA sources do not prove market-wide live coverage. They show licensing activity and a September 2026 focus on readiness for Payment Initiation Services, business use, service quality and bank-fintech coordination.
Why is payment initiation harder than account-information access? Because it moves money. Product teams must handle account eligibility, consent, rail routing, bank responses, customer messaging, reconciliation and exception ownership.
What should banks and fintechs test first? They should test eligibility, consent evidence, rejection reasons, rail fallback, shared incident ownership and reconciliation from initiation through final payment status.
References
Closing thought and further reading
Payment initiation is where open banking stops being a data-access programme and becomes a money-movement product.
Ideas that continue the thread.
View all essays
Building through similar complexity?
Discuss the operating decisions behind the essay, or explore where my experience can help.