Every bank running an Open Banking programme in Saudi Arabia is navigating a version of the same question: what does SAMA Phase 2 actually require of our authentication and authorization infrastructure, and how much of what we have already built needs to change? The answer is not comfortable. SAMA Open Banking Phase 2 mandates FAPI 2.0 as the security profile for all TPP access — Account Information Services, Payment Initiation Services, and Confirmation of Funds. FAPI 2.0 is not an upgrade to your existing OAuth 2.0 setup. It is a different security model that adds mandatory controls most current implementations do not have.

The decision is not whether to implement FAPI 2.0 — SAMA has made that decision for you. The decision is how to implement it, in what sequence, at what cost, and who in the organization owns the consequences of getting it wrong. Those choices have significant implications for your IdP budget, your TPP onboarding timeline, your consent management architecture, and the user experience that PSUs (Payment Service Users) encounter every time they authorize a TPP to access their account.

What SAMA requires

SAMA Open Banking Phase 2 aligns to the FAPI 2.0 Security Profile (FAPI2SP) and the FAPI 2.0 Message Signing profile (FAPI2MS). Practically, this means five things that your current OAuth 2.0 implementation almost certainly does not have. First, Pushed Authorization Requests (PAR): all authorization parameters must be sent from the TPP’s server to the authorization server directly, before the browser redirect, producing a short-lived request_uri that the redirect carries instead of the parameters themselves. Second, sender-constrained tokens: every access token issued to a TPP must be bound to the TPP’s cryptographic identity — either a DPoP proof-of-possession key pair (RFC 9449) or the TLS client certificate the TPP presents during the token request (RFC 8705). Third, Rich Authorization Requests: the consent model must capture the exact accounts, amounts, and operations covered by each TPP authorization, not just a broad OAuth scope. Fourth, JARM — JWT Secured Authorization Response Mode: the authorization code returned after consent must be wrapped in a signed JWT, not returned as a plain redirect parameter. Fifth, no implicit grant and no resource owner password credentials — both are banned under FAPI 2.0 and the SAMA Open Banking Technical Standards.

Your IdP must support all five of these features before you can onboard a single TPP in Phase 2. If your current identity platform is not on the FAPI 2.0-certified list, either the platform must be upgraded or replaced, or you build the missing controls in your API gateway layer — a path that creates ongoing maintenance debt and increases the complexity of your SAMA examination evidence package. Keycloak 24 ships a built-in FAPI 2.0 Security Profile realm policy that handles all five requirements natively. IBM Security Verify also carries FAPI 2.0 certification. The upgrade budget decision must happen before the technical implementation can start, and it must be owned at the VP level because it is not a technical upgrade — it is a compliance infrastructure investment.

An IdP that is not FAPI 2.0 certified is not a minor gap — it is a prerequisite blocker. No amount of API gateway workarounds makes a non-certified IdP FAPI 2.0 compliant in a way that survives a SAMA technical examination.

The business trade-off

FAPI 2.0 adds steps to the authorization flow that standard OAuth 2.0 does not have. PAR requires a server-to-server call from the TPP to the bank before the user sees a consent screen. DPoP requires the TPP to generate an ephemeral key pair and sign a proof JWT for every API call. Sender-constrained tokens bind the authorization to the specific TPP client that requested it — which is the security benefit, but it also means the consent cannot be transferred or reused in ways that some aggregator business models depended on. Each of these controls adds latency, increases TPP integration complexity, and in some cases changes the PSU experience in the authorization flow.

The business framing that I have seen used most often — “this will reduce conversion rates” — is accurate but incomplete. Yes, a multi-step authorization flow with an explicit consent screen for each specific payment reduces the friction-free experience that some Open Banking architectures targeted. But that friction is not a design failure. The friction is the security control. The difference between an OAuth 2.0 payment authorization and a FAPI 2.0 payment authorization is precisely this: in the FAPI 2.0 model, the PSU sees and approves a specific payment amount to a specific account, and that consent is cryptographically bound to that specific TPP. In a weaker model, the PSU approves a general “payments” scope and may not see the specific payment details at all until after the fact. SAMA has decided which model Saudi banking consumers deserve. The executive trade-off is not conversion rate versus security — it is compliance versus non-compliance.

The DPoP versus mTLS decision is a genuine trade-off with no universally correct answer. DPoP is lower-friction for TPP onboarding: the TPP generates key pairs in software and does not need a client certificate provisioned by the bank’s PKI. mTLS is operationally simpler at the gateway: the binding is enforced at the TLS layer before any application logic runs, and there is no per-request proof JWT to validate. The choice between them depends on your TPP population, your PKI infrastructure maturity, and your API gateway’s DPoP validation capabilities. Both are SAMA-compliant; the decision should be driven by what your organization can operate reliably at scale, not by what sounds more secure in a presentation.

What leadership must own

Four decisions in the FAPI 2.0 programme cannot be delegated to the engineering team because they have budget, governance, and regulatory implications that require VP-level authority.

The first is IdP selection or upgrade budget. If your current identity platform does not support FAPI 2.0, the programme cannot proceed without a platform decision. This is not a security team budget item — it is an enterprise architecture investment that spans payments, retail banking, and the CTO’s technology roadmap. The decision must be made with the full cost in view: not just the license cost of a certified IdP, but the migration cost of moving existing OAuth 2.0 clients to the new platform, the operational cost of running and supporting it, and the timeline impact on SAMA Phase 2 go-live.

The second is TPP onboarding process governance. FAPI 2.0 TPP onboarding is not a developer portal registration. It requires verification of the TPP’s SAMA Open Banking Directory registration (the Software Statement Assertion), automated or manual client certificate issuance if mTLS is chosen, mapping the TPP to a rate plan by API class, and activation in the consent model. This is a process that spans compliance, IT security, and operations — not a task that the API team can own end to end without explicit governance and SLAs. The VP of Enterprise Integration or equivalent must define the TPP onboarding process, the SLA for activation, and the escalation path when a SAMA-registered TPP cannot be onboarded within the agreed timeline.

The third is consent lifecycle management. SAMA’s consent model requires that a PSU can revoke consent at any time through the bank’s own channels, that the TPP is notified of revocation within a defined window, and that the bank maintains an auditable record of every consent grant, status transition, and revocation. This is not a feature — it is regulatory infrastructure. The bank must build and operate a consent management system, expose a PSU-facing consent management interface (through the bank’s app or internet banking portal), and integrate consent status with the authorization server’s token lifecycle. None of this is in scope for a standard OAuth 2.0 implementation, and none of it can be built as an afterthought after TPP onboarding has started.

The fourth is the annual security assessment. SAMA requires that Open Banking APIs undergo an annual security assessment aligned to FAPI 2.0. This means a penetration test by an accredited vendor that specifically covers FAPI 2.0 attack surface — PAR replay, DPoP jti replay, token binding bypass, RAR consent tampering, JARM response injection. The VP must own the budget for this assessment, the remediation budget for findings, and the attestation process that reports results to SAMA. This is not a one-time activity; it is a recurring cost of operating a SAMA Phase 2 Open Banking programme.

For the engineering depth behind these decisions — PAR implementation, DPoP proof-of-possession internals, mTLS binding, RAR consent model, JARM configuration in Keycloak 24, Kong enforcement, and the production checklist — see the companion Lab article: API Security: FAPI 2.0 & Open Banking Security.