Banking Technology Consulting Saudi Arabia: How Banks Should Sequence Core, Compliance and Open Banking Decisions

Saudi banking technology leaders rarely face a shortage of projects. The harder question is which change must happen first. A core modernisation programme can affect APIs, compliance systems, data architecture, fraud controls and every digital channel connected to the core.

That is why banking technology consulting saudi arabia should start with sequencing rather than a product shortlist. The cost of getting the order wrong is not limited to implementation spend. Banks can create duplicated integrations, temporary architectures that become permanent, regulatory rework and dependencies that make later transformation harder.

The right programme therefore separates four major decisions, identifies their dependencies, and determines which capabilities must be stable before the next layer is changed.

Banking Technology Consulting Saudi Arabia: The Four Technology Decisions Banks Face Now

For Saudi banks, finance companies and fintechs, four technology decisions increasingly interact with one another. They should be managed as connected decisions rather than independent procurement exercises.

1. Modernise the banking core. Decide which capabilities genuinely need replacement, which can be isolated behind services, and which legacy components can remain temporarily without blocking digital change.

2. Build regulatory capability. Ensure technology change preserves SAMA supervision, cybersecurity, outsourcing, data, AML and governance obligations instead of treating compliance as a review performed after architecture decisions are complete.

3. Prepare API architecture. Open banking changes how customer-authorised data and services move between banks and regulated third parties. API readiness therefore needs ownership, security, consent, monitoring and lifecycle management.

4. Control platform dependencies. Cloud, fraud, analytics, identity and specialist platforms create operational value but can also increase concentration and integration risk. Architecture must preserve the bank's ability to change providers and maintain critical services.

The order varies by institution. A bank with a stable core but weak API architecture should not copy the roadmap of a bank whose product configuration and batch processes are constraining every digital release.

The correct starting point is therefore the constraint that blocks the next several decisions, not the project with the strongest vendor presentation.

Core Banking Modernisation Without a Big-Bang Replacement

Core banking modernisation does not always mean replacing the entire core at once. For many banks, the more useful question is which parts of the existing estate prevent faster product change, better integration or stronger control.

A big-bang replacement concentrates technical, operational and migration risk into one programme. An incremental model reduces some of that concentration, but only if the target architecture is defined before individual components are modernised.

Identify what the core is actually preventing

Start with constraints rather than age. An old platform that remains stable and performs a narrow function may create less strategic risk than a newer platform that cannot expose services cleanly or forces manual reconciliation.

Common constraints include slow product configuration, tightly coupled channels, point-to-point integrations, difficult batch dependencies, fragmented customer records and limited real-time processing.

Choose the modernisation pattern deliberately

Build the migration boundary before selecting the replacement

Define which customer records, products, transaction histories, interfaces, reports and regulatory feeds move in each phase.

This matters because core modernisation is not simply a database migration. Downstream AML, finance, regulatory reporting, digital channels, card platforms and data environments may depend on behaviours that are not obvious from an application inventory.

For banks evaluating whether to replace, isolate or progressively decompose older platforms, the broader decision patterns are covered in legacy system modernisation.

Do not modernise the core before defining the future integration model

A new core connected through the same uncontrolled point-to-point integrations can reproduce the old operating problem on newer technology.

Integration principles should therefore be decided early: API ownership, event patterns, batch use, canonical data, exception handling and the boundary between core services and channel-specific logic.

Open Banking Obligations and API Readiness

Open banking should not be treated as another external API project. It introduces a regulated operating model around data sharing, customer consent, third-party connectivity and technical conformance.

SAMA's Open Banking Framework includes use cases, business rules and technical standards covering areas such as customer experience, APIs, implementation and operations. The Open Banking Lab provides testing and certification capabilities for participants. 

In March 2026, SAMA announced the commencement of licensing fintech companies to provide open banking services following the regulatory sandbox phase. That makes API readiness an active operating concern rather than a distant architecture objective. 

Separate API exposure from API capability

A bank can expose an endpoint without having a mature enterprise API capability.

Long-term readiness requires ownership, version control, authentication, authorisation, consent management, logging, throttling, service-level monitoring, developer onboarding and clear processes for retiring interfaces.

Design APIs around business capabilities

A weak API programme simply recreates existing application boundaries. A stronger programme identifies reusable business capabilities such as customer information, account information, payments and identity services.

This reduces the chance that every new fintech connection or digital channel creates another custom integration.

If open banking is exposing wider integration weaknesses, the bank should define an api strategy enterprise model that covers internal and external interfaces rather than treating regulatory APIs as a standalone estate.

Resolve core dependencies early

Open banking can reveal limitations in legacy processing, customer data consistency and response times.

If an API needs information that is assembled overnight, dependent on several systems or reconciled manually, the API layer alone cannot solve the underlying problem.

This is where open banking and core banking modernisation become one sequencing decision. The bank needs to identify which core limitations must change before API commitments become harder to meet.

SAMA and NCA Control Expectations for Technology Change

Technology transformation inside a Saudi bank operates within supervisory and cybersecurity requirements. Compliance therefore cannot sit at the final approval gate after architecture, cloud and outsourcing decisions have already been made.

SAMA's Cyber Security Framework remains in force across the banking sector and requires institutions to assess cybersecurity maturity and manage cybersecurity through a structured control framework. SAMA's related circular for banks requires a gap assessment and a roadmap towards at least Maturity Level 3, with board visibility and approval of the roadmap. 

The National Cybersecurity Authority also maintains ECC 2-2024 as the current Essential Cybersecurity Controls, while its CCC-2:2024 extends cybersecurity requirements into cloud computing. 

Translate controls into architecture decisions

A control should not remain a line in a compliance spreadsheet. It needs an implementation point inside the technology estate.

For example, identity governance affects directory architecture and privileged access. Logging requirements affect platforms, retention and SOC integration. Third-party control requirements affect contracts, technical access and monitoring.

Make control ownership explicit

Security may define a requirement without owning the system that implements it. Operations may run a control without owning its regulatory interpretation.

The bank therefore needs an accountability model that connects policy owners, technology owners, risk, compliance, cybersecurity and operational teams.

Where that ownership is inconsistent across transformation programmes, IT governance advisory should address decision rights and accountability rather than adding another layer of technical documentation.

Govern transformation, not only steady-state technology

Major technology change creates temporary states: duplicate systems, transitional integrations, data migration utilities, temporary access and parallel processes.

Those temporary states need governance because they can exist for months or years. A practical it governance framework should therefore cover programme decisions and transition risks as well as the final operating environment.

A useful next step for a bank already carrying several transformation programmes is to create one control-to-change map: list major programmes, applicable supervisory requirements, system owners, temporary exceptions and evidence owners. This reveals where regulatory work is duplicated and where no programme currently owns a material dependency.

Data Residency and Cloud Adoption in Banking

Cloud decisions in banking should begin with workload classification and regulatory treatment rather than a general cloud-first or cloud-avoidance position.

SAMA's Cyber Security Framework states that financial institutions should obtain SAMA no-objection before using cloud services or signing the relevant cloud contract. It also sets an in-Kingdom principle for cloud location, with SAMA no-objection required where cloud services outside Saudi Arabia are used. :contentReference[oaicite:5]{index=5}

Classify workloads before evaluating providers

Separate workloads by customer-data sensitivity, criticality, integration depth, recovery requirements, latency and regulatory treatment.

A collaboration workload, analytics platform and core transaction engine should not automatically receive the same cloud decision simply because they sit under the same enterprise cloud strategy.

Evaluate operating responsibility, not only hosting location

Data location is one question. Responsibility for identity, encryption, logging, configuration, resilience, incident response and subcontractors is another.

Cloud architecture should define the control boundary between the bank and provider before implementation begins.

Avoid creating a second uncontrolled estate

Cloud adoption can reduce infrastructure constraints while increasing platform sprawl if each programme creates its own landing zone, identity pattern, integration tools and data services.

Common architecture standards should therefore be defined before individual teams scale cloud adoption.

Fraud, AML and Analytics Platform Decisions

Fraud and AML platforms depend on data from customer systems, channels, transaction engines, payment platforms and external sources. Their effectiveness therefore depends heavily on integration and data quality.

SAMA's rules for ongoing account and transaction monitoring state that manual monitoring is not sufficient and require banks to use appropriate electronic systems. The rules also state that monitoring systems should be integrated with core systems, with precautions and manual procedures where integration incompatibility exists. 

Do not treat AML as a standalone compliance application

The platform can only analyse what the bank can provide accurately and quickly.

Poor customer identifiers, inconsistent transaction descriptions, delayed feeds or incomplete product data can reduce the value of a sophisticated monitoring engine.

Separate detection technology from decision governance

Analytics can generate alerts or risk scores. It cannot independently determine the bank's policy for investigating, escalating or closing them.

Technology selection should therefore be accompanied by an operating model covering alert ownership, thresholds, investigation workflows, case management, evidence and model governance.

Plan for model and rules change

Fraud patterns and customer behaviour change. A platform that requires extensive vendor intervention for every rule adjustment can slow the bank's response.

Buyers should assess who can change detection logic, how changes are tested, how false positives are measured and how model performance is governed after implementation.

Keep analytics architecture reusable

AML, fraud, credit, customer behaviour and operational analytics often require overlapping data.

A bank should therefore question whether each new use case requires another extraction pipeline or whether common governed data products can support several risk and business functions.

Vendor Concentration Risk in Banking Estates

Standardisation can reduce operational complexity, but excessive concentration creates a different problem. If one provider controls core processing, integration, cloud, managed operations and specialist security, changing one component may become commercially or technically difficult.

SAMA's outsourcing rules explicitly require banks to consider the risks of outsourcing multiple activities to the same provider, the difficulty and time required to find alternatives, and the institution's ability to continue meeting regulatory requirements if a provider fails. Material outsourcing also requires written SAMA no-objection.

Measure concentration by dependency, not vendor count

Having ten suppliers does not prove diversification if one provider controls the identity plane, integration layer or data platform on which the others depend.

Map providers against critical services, data, operational knowledge and replacement difficulty.

Ask what happens when the contract ends

Exit planning should be part of architecture evaluation, not merely a contractual clause.

• Data portability: can the bank extract information in usable formats?

• Configuration ownership: who owns scripts, rules, models and integrations?

• Operational knowledge: can internal teams or another provider take over?

• Interface portability: how many connected systems must change if the vendor changes?

• Transition support: what technical assistance is contractually available during exit?

Prefer architectural options over artificial neutrality

Vendor concentration is not solved by forcing every workload onto a different technology. That can simply replace concentration risk with integration complexity.

The objective is to preserve meaningful options around critical capabilities while using standardisation where it lowers cost and risk.

Before a bank locks several transformation workstreams into long contracts, a structured decision process can expose dependencies that are difficult to see in separate procurement exercises. our five-stage methodology provides one way to structure discovery, requirements, comparison and implementation decisions.

Sequencing a Multi-Year Banking Technology Programme

The sequence should be built from dependencies rather than executive preference or vendor availability. In banking technology consulting saudi arabia, supervisory expectations can constrain the programme order more strongly than technical elegance.

A programme may therefore need to strengthen governance, identity, data or integration before replacing the business platform that originally triggered the transformation.

Phase 1: Establish the decision baseline

Document business objectives, regulatory obligations, current architecture, technical debt, critical dependencies, active contracts and transformation commitments already underway.

This phase should also identify decisions that have effectively already been made through contractual commitments or regulatory deadlines.

Phase 2: Stabilise control foundations

Address foundational capabilities that every later programme depends on. These may include identity, integration standards, data ownership, security monitoring, architecture governance and resilience.

Skipping this stage often results in every programme solving the same foundational issue independently.

Phase 3: Define the core and integration boundary

Decide which capabilities remain within the core, which move into specialist platforms and which are exposed through reusable services.

This boundary should exist before large-scale core procurement or API implementation.

Phase 4: Sequence customer and regulatory change

Open banking, digital channels, regulatory reporting, AML and customer-data programmes can then be sequenced according to the capabilities created in earlier phases.

This reduces duplicated interfaces and makes temporary architecture more visible.

Phase 5: Modernise progressively

Move workloads according to business value, risk and dependency.

The bank should define measurable exit criteria for each transitional state so temporary dual-running arrangements do not survive indefinitely.

Phase 6: Reassess the roadmap continuously

A three-year technology roadmap should not be a fixed procurement calendar. Regulatory requirements, vendor capabilities, customer behaviour and the bank's own delivery performance will change.

Review sequencing when a dependency changes rather than continuing a programme simply because its original date remains in the plan.

A bank that needs a single decision structure across core, cloud, compliance, APIs and data should treat the roadmap as a strategic portfolio rather than separate technology projects. That is the role of IT strategy consulting when sequencing is the problem rather than a shortage of potential technologies.

For teams building the internal document before seeking external support, an it strategy roadmap should identify dependencies, decision gates, owners, transition states and measurable outcomes rather than listing projects by calendar year.

Frequently Asked Questions About Banking Technology Consulting Saudi Arabia

What should a Saudi bank modernise first: the core or its digital channels?

The answer depends on the dependency causing the constraint. If the core prevents real-time access, product configuration or reliable integration, some core changes may need to happen first. If the core remains stable and can expose the required services, channel modernisation may proceed while deeper core changes are sequenced separately.

Does open banking require a bank to replace its core banking system?

Not automatically. Open banking requires secure, controlled and conformant API capabilities, but an existing core may remain viable if it can provide the necessary data and services reliably. The real test is whether legacy processing, batch dependencies, customer-data fragmentation or integration limitations prevent the bank from meeting the required operating model.

How should SAMA compliance affect a banking technology roadmap?

SAMA requirements should be translated into architecture, ownership and programme decisions from the beginning. Banks should identify relevant cybersecurity, outsourcing, cloud, data, AML and governance requirements before selecting platforms. This prevents a technically valid design from later requiring substantial changes because a regulatory obligation was considered only during final approval.

Should Saudi banks move critical systems to the cloud?

The decision should be made workload by workload. Banks need to consider regulatory treatment, SAMA no-objection requirements, data location, cybersecurity, resilience, exit options and provider dependency. Cloud may be appropriate for some critical workloads, but a generic cloud-first rule is not a substitute for evaluating the specific service and its operating model.

What should banking technology consultants evaluate before recommending vendors?

They should establish business requirements, supervisory obligations, current architecture, integration dependencies, data requirements, operating ownership, migration constraints and vendor concentration exposure before comparing products. A recommendation made before those issues are understood risks optimising an individual platform while making the wider banking estate more difficult and expensive to change.

The practical change for technology leaders is to stop approving core, compliance, open banking, cloud and analytics decisions as separate programmes. Their dependencies should be visible in one architecture and one portfolio sequence before major contracts are committed.

Effective banking technology consulting saudi arabia should leave the bank with clearer decisions even if no immediate implementation follows. If your team needs to test the sequencing before committing to a platform, use the sector requirements in banking and financial services technology as a starting point, then compare the decision model with the broader industries we serve to identify which dependencies are genuinely banking-specific.