Every Saudi bank will meet the obligation. The ones that treat the API surface as a product — documented, fast, easy to build against — will end up carrying the fintechs the others also wanted.
SAMA's Open Banking Framework has been released in phases, account information first and payment initiation subsequently, so the current publications govern. What follows is the shape of the obligation rather than a substitute for reading them.
The endpoint list is the easy part; it is published. The difficulty is behind them — reaching a core banking system that was never designed to answer a stranger's question in under a second.
Paths shown are illustrative of the resource model. Implementations follow the current SAMA specification.
A public API can afford an API key and a rate limit. An API that moves money cannot. FAPI exists because the ordinary OAuth patterns leave gaps that are tolerable for a photo-sharing app and unacceptable for a payment.
response_type=code only; implicit flow has no place here.Consent looks like a screen. It is actually a state machine that spans the API gateway, the mobile app, the contact centre and the audit store, and it has to stay correct for years across every one of them.
The failure mode is drift. A consent revoked in the app that the gateway keeps honouring for another hour is a data protection incident, not a caching quirk. PDPL and the framework both bear on this, and the customer will ask the contact centre, not the API team.
Not in the API itself — an endpoint that returns a balance should be deterministic. AI belongs around it: in the traffic, the risk and the data the platform now produces.
Enumeration, credential-stuffing patterns and providers behaving unlike their declared use case look normal per request and obvious in aggregate. Behavioural models on traffic catch what per-call rules cannot.
Traffic anomaly · AbuseInitiation requests scored in real time on device, beneficiary, amount and behavioural signals, with thresholds routing to step-up authentication rather than silent rejection.
Real-time scoring · Step-upRaw transaction descriptors are unreadable. Categorisation and merchant identification — in Arabic and English — make the data useful to providers, and directly improve the products built on your rails.
Categorisation · Arabic merchantsWhere customers abandon the consent journey, which scopes cause hesitation, which providers convert. This is product analytics for a regulatory surface, and almost nobody instruments it.
Funnel · Drop-offPermissioned transaction data supports income verification and affordability assessment far faster than payslip collection — useful in your own lending and as a service to partners.
Income · AffordabilitySearch over your documentation, an assistant that answers integration questions, and automated example generation. Cheap to build and measurably reduces the support load a growing partner ecosystem creates.
Doc search · Integration supportBoth answers are defensible, and the question is really what you intend the API surface to be. Many banks land on a split: buy the obligation, build the experience above it.
| Approach | Suits a bank that | Trade-off |
|---|---|---|
| Vendor platform | Wants the obligation met on time with the least internal capability building. | Faster to certified, but the developer experience is the vendor's, and so is much of the roadmap. |
| Build in-house | Intends to compete on partner ecosystem and treats the API as a product with its own roadmap. | More control and better differentiation, at the cost of owning conformance and security work permanently. |
| Hybrid | Wants compliance quickly but expects the API to become strategic. | Vendor handles the regulated core; you build portal, analytics and partner experience above it. The common landing point. |
Crux works in all three shapes, including alongside a vendor platform already in place. The recommendation comes out of the review rather than out of what we would prefer to build.
Account information before payment initiation, always. It exercises the whole stack — authentication, consent, gateway, core integration — without the incident profile of moving money while you are still learning your own platform.
Current API estate, core banking reachability, latency and load headroom, and gap analysis against the framework. Ends with a build, buy or hybrid recommendation.
FAPI profile, certificate handling, consent model and lifecycle, agreed with security, compliance and legal before implementation.
Account information endpoints, gateway, consent enforcement and audit logging, against a core system that usually needs work to answer fast enough.
Documentation in Arabic and English, sandbox with representative data, onboarding flow and key management — the surface partners actually judge you on.
Conformance testing, load testing at expected partner volumes, operational runbooks and go-live with monitoring in place.
Payment initiation with fraud controls, idempotency, reconciliation and dispute handling — treated as its own programme, not a sprint.
Account information with consent and sandbox typically runs 16 to 24 weeks. The variable is nearly always core banking reachability, not the API layer.
Exposing customer-permissioned account data, and in later phases payment initiation, to providers permitted by SAMA through standardised secure APIs. That entails a consent journey, a security profile providers can authenticate against, availability and performance obligations, and auditable records of every data-sharing event. Requirements have been released in phases, so confirm current SAMA publications before design.
Account Information Services let a third party read customer data with consent — balances, transactions, account details. Payment Initiation Services let a third party start a payment from the customer's account. AIS is read-only and lower risk; PIS moves money and carries stronger authentication, fraud and liability implications.
A financial-grade profile rather than ordinary API security: OAuth 2.0 with PKCE, FAPI conformance, mutual TLS for client authentication, signed and where required encrypted payloads, certificate validation against the approved authority, and full audit logging of access and consent events.
Vendor platforms deliver compliance faster and suit banks whose objective is meeting the obligation. Building suits banks intending to compete on developer experience and partner ecosystem. Many buy the compliance layer and build the differentiating layer above it — that hybrid is the most common landing point.
The customer authenticates with the bank, sees exactly what is being requested and for how long, and approves or declines. That consent is then stored, enforced on every subsequent call, visible in the banking app, revocable at any time and expired automatically. It is the most underestimated part, because it spans the API, the app and the contact centre.
Account information APIs with consent management and a developer sandbox typically take 16 to 24 weeks. Payment initiation adds meaningfully because of stronger authentication, fraud controls and reconciliation. Timelines depend heavily on how reachable the core banking system is.
A three-week readiness review measures core reachability and latency headroom, maps your gap against the framework, and returns a build, buy or hybrid recommendation with a sequenced plan.