KSA Banking

Social Share

On 26 March 2026, the KSA Central Bank moved Open Banking out of its controlled sandbox and into a formal licensing regime, granting its first licences to Neotek and Lean Technologies on the same day. For KSA banks, this was more than a regulatory milestone it marks the moment when “being innovative” is no longer enough. Since March, SAMA has kept licensing new open banking and payment companies. More approvals came through the year, including in the second and third quarters. In fact, by 22 July 2026, the number of SAMA-licensed payment services companies had grown from 2 to 33, a clear sign that licensing has become an ongoing, continuous process, not a one-time event. The message for banks is clear: it is not enough to say a system is safe. Banks must now prove it, with real evidence not just test results from a pilot. 

From Sandbox to Scrutiny 

Before, banks and fintech companies could test Open Banking ideas inside SAMA’s supervised sandbox. There was some room to experiment. That room has now become much smaller. To get a licence, a company must show it is ready in several ways: strong governance, strong cybersecurity and strong operational resilience. It must also show that its systems can connect safely using secure, standard APIs. 

In simple terms, this means Saudi banks can no longer treat Open Banking as just a technical project. It is now also a compliance project and a strict one. Every API, every data-sharing agreement and every new digital service must now come with proof. Good intentions are not enough anymore. Under Article 23 of the Banking Control Law, SAMA has the legal authority to act on non-compliance including restrictions on services or, in serious cases, licence revocation. This is the same authority that now sits behind every Open Banking licence granted since March. 

Where the Pressure Is Actually Landing 

Across the Kingdom’s banking sector, this shift is surfacing in different ways, depending on where each bank is in its transformation journey. 

Banks scaling AI at pace are feeling it most acutely. As AI-driven marketing revenue surges and generative AI platforms roll out across corporate and retail channels, the risk of productivity gains failing to materialise or worse, AI systems behaving unpredictably in production has become a board-level concern. SAMA’s tightening cybersecurity and governance expectations mean AI features can no longer launch on the strength of a good demo. They need to be explainable and auditable from day one. 

Banks with near-total digital reliance face a different kind of exposure. When almost all transaction volume moves through digital channels, even a minor downtime incident or interface glitch carries outsized reputational risk. In this environment, resilience isn’t a feature, it’s the entire customer relationship. 

Banks pursuing blockchain and DLT initiatives — including cross-border payment sandboxes and tokenisation pilots are discovering that innovative infrastructure introduces new categories of security and custody risk that traditional testing frameworks were never designed to catch. 

Banks modernising wholesale and corporate banking platforms are wrestling with integration complexity on a different front: connecting new API-led wholesale banking systems to legacy cores and existing customer platforms, all whilst maintaining release quality under frequent update cycles. 

Banks expanding card and payment campaigns internationally are under quiet but constant pressure to keep transaction, rewards and reconciliation systems performing flawlessly as cross-border usage grows. 

Different starting points, same underlying question: when SAMA asks for evidence that a system is safe, reliable and secure, can the bank actually produce it quickly and without disrupting the next release? 

Two Deadlines, One Release 

This is the tension every KSA bank is now managing. The board wants faster digital and AI banking. SAMA wants proof it’s safe first. Miss either one and the risk sits squarely with the institution whether that’s a delayed launch, a licensing setback or a public incident that erodes years of digital trust. 

The banks that will move fastest through this next phase are not the ones cutting testing to hit a launch date. They are the ones that have built proof into the release process itself, so that when SAMA asks the question, the answer is already sitting in evidence not being assembled after the fact. 

What “Ready” Actually Looks Like 

For KSA banks navigating SAMA’s licensing regime, readiness now means: 

  • Licence-grade testing — validating systems to the production standard SAMA now expects, rather than the lighter benchmark of a sandbox trial. 
  • AI you can explain — ensuring AI-driven banking features are auditable and defensible under regulatory scrutiny, not just functionally impressive. 
  • Integration proof, not integration hope — confirming that new Open Banking APIs, wholesale platforms and legacy cores genuinely work together under real transaction conditions, before a regulator or a customer finds out otherwise. 

How Testhouse Closes the Gap Between Launch and Proof 

This is exactly the gap Testhouse works in closing the space between “we launched it” and “we can prove it was safe to launch”, so KSA banks don’t have to choose between speed and SAMA’s expectations. 

  • For AI at scale — we validate AI-driven banking features for accuracy, bias and unpredictable behaviour before release and structure the evidence so it’s explainable and auditable if SAMA asks for it later, not reconstructed under pressure. 
  • For near-total digital reliance — we build resilience and performance testing into every release cycle, so downtime and interface failures are caught before they reach customers, not after. 
  • For blockchain, DLT and tokenisation initiatives — our security and DevSecOps testing is built for novel infrastructure, covering custody, data integrity and access risks that standard testing frameworks typically miss. 
  • For wholesale and core integration projects — we run end-to-end integration testing across new API-led platforms, legacy cores and customer systems, so data flows correctly and consistently under real transaction conditions, not just in a controlled test environment. 
  • For cross-border payment and card growth — we performance-test transaction, reconciliation and rewards systems under realistic international load, before volume growth exposes the weak points. 

Across all of these, the approach is the same: proof is built in during development and testing, not assembled retrospectively when a regulator, an auditor or a customer asks the question. 

SAMA’s shift from sandbox to licensing is not a one-off event. It is the clearest signal yet of where Gulf banking regulation is heading: production-level accountability, applied continuously, not just at launch. 

For banks operating under this regime, the real competitive advantage will belong to whoever can move quickly and prove it was safe to do so, in the same breath. 

Can Your Platform Handle What’s Next?

Get a Readiness Gap Assessment of your digital systems before they become regulatory or production risks. Write to contac@testhouse.net