SAMA PIS References Are a Product Control

Saudi open banking already has a broad readiness question: can banks and fintechs make payment initiation reliable for customers and businesses?

The sharper follow-up is narrower: can every initiated payment be explained from consent to reference to customer evidence?

SAMA's 17 September 2026 Open Banking Forum brought bank open-banking leaders together at Money20/20 Middle East. The current note says the next-stage discussion focused on bank readiness for Payment Initiation Services, wider business use of open banking, service quality, coordination between banks and fintechs, and a more consistent customer experience.

That is the broad signal. The control detail sits in SAMA's rulebook. Articles 97 and 98 turn consent, PISP identity and transaction references into product requirements, not back-office documentation.

The product mistake is to treat the reference as a receipt string. In PIS, the reference is a control surface.

The useful boundary is not the button

SAMA's first open banking release focused on Account Information Services. That is important infrastructure, but it is mostly about controlled access to financial data. The second release of the Open Banking Framework, issued in September 2024, focuses on Payment Initiation Services and standardises how participants can offer PIS reliably and securely.

The operating burden is different.

With AIS, the core question is whether the customer has consented to share account information and whether the provider can access only what it should. With PIS, the question extends into payment execution: who initiated the order, what the payer saw, what the bank accepted, what reference was returned, what happened when the initiation failed, and how the customer can prove the status later.

That is why the bank readiness discussion matters. PIS does not become reliable because a fintech can call an endpoint. It becomes reliable when the bank's consent, authentication, payment, support and reconciliation teams all recognise the same event.

The control boundary is already visible

The SAMA rulebook makes the boundary concrete. Article 97 says a Payment Initiation Service Provider must obtain the user's consent before providing the service, must not hold user funds, must not modify the amount or payee, must secure personalised security credentials, must limit data use to what is needed for the service and must identify itself in each communication session.

Article 98 then turns the customer evidence into a product requirement. Before initiation, the provider must give the payer clear information about the provider and contact route. Immediately after initiation, the provider must give confirmation of successful initiation with the payer's account service provider, a reference that lets the payer and payee identify the transaction, the amount, any relevant charges and a payment-transaction reference for the account service provider.

Those are not legal footnotes for the policy team alone. They are acceptance criteria for the product flow.

If the payer sees "payment initiated" but support cannot find the initiation reference, the flow is not ready. If the payee receives money but cannot match it to the payer, the flow is not ready. If the bank can show API uptime but cannot separate rejected initiation, accepted initiation, executed payment and pending settlement, the flow is not ready.

Five reference-control tests for banks

The first test is consent-state design. The bank should be able to show when consent was requested, granted, used, expired or revoked, and which payment instruction it authorised. Consent should not live only in the third-party app's log.

The second test is session identity. The PISP must identify itself in each communication session, and the bank should preserve that identity inside the event trail. That matters for complaints, fraud review, partner performance and customer explanation.

The third test is reference propagation. A PIS transaction needs references that survive from the third-party app to the bank, customer support, merchant or payee, and reconciliation. If the reference changes at each layer, the customer journey becomes a search exercise.

The fourth test is exception ownership. A failed initiation, expired consent, authentication problem, insufficient funds response and downstream execution issue should not all collapse into "payment failed." Each state needs an owner, a customer message and a retry or closure rule.

The fifth test is payee-side evidence. PIS is valuable only if the receiving side can match money to the commercial event. The payer's bank, the payee, the fintech app and the support team should be able to agree on the amount, reference and status without manual archaeology.

What fintechs should expect from bank partners

Fintechs building Saudi open banking products should ask banks for more than API availability.

Ask for the status taxonomy. Ask which references will be returned and where they appear in statements, callbacks, support tooling and settlement files. Ask what happens when initiation succeeds but execution later fails. Ask whether charge, fee and amount fields are stable enough to show to a customer without rewriting the bank's meaning.

Also ask how service-quality issues will be governed. SAMA's forum note names coordination between banks and fintech companies and a more consistent customer experience as next-stage priorities. That is a hint that partner operations will matter as much as integration.

A good fintech launch plan should therefore include bank-by-bank behaviour testing, not only conformance testing. The same PIS use case can feel different if each bank returns different failure language, reference timing or support evidence.

The practical evidence gate

Before launching PIS at scale, I would ask for evidence on eight points:

1. Can the bank reconstruct the full initiation journey from one reference?
2. Is customer consent linked to the exact payment instruction?
3. Is the PISP identity preserved for every communication session?
4. Can support distinguish initiated, accepted, rejected, executed, failed and pending states?
5. Are payer and payee references stable across app, bank and reconciliation records?
6. Are fees and amounts presented consistently before and after initiation?
7. Do retry rules protect against duplicate payment attempts?
8. Can the product team measure failures by bank, cause and customer impact?

If those answers are not available, the institution may have an API integration but not a reference-control model.

The product lesson

Payment Initiation Services make open banking visible at the moment a customer expects money to move. That is a trust moment, not an API demo.

SAMA's September forum points to the right next question: bank readiness. Articles 97 and 98 make the practical evidence test clearer. Product and programme teams need consent evidence, session identity, stable references, exception ownership, payee matching and customer language that does not overstate what happened.

The fintech app can make PIS feel simple. The reference trail is what makes it true.

Sources

• SAMA, "SAMA Holds Open Banking Forum with Banks", 17 September 2026.
• SAMA, "SAMA Announces Issuance of Second Release of Open Banking Framework", 2 September 2024.
• SAMA Rulebook, Implementing Regulations of Payments and Payment Services Law, Article 97.
• SAMA Rulebook, Implementing Regulations of Payments and Payment Services Law, Article 98.

FAQ

What is a PIS reference-control model? It is the operating design that keeps consent, PISP identity, payment references, status, exception ownership and reconciliation evidence linked across the bank and fintech journey.

Is PIS the same as account information sharing? No. Account information sharing exposes customer financial data with consent. PIS initiates a payment order, so it carries execution, customer-status and money-movement controls.

What should banks test before launch? Test consent-state handling, PISP session identity, reference propagation, failure-state ownership, duplicate retry protection, payee matching and customer-support evidence.