Saudi Arabia’s next infrastructure layer: Digital Assets, Blockchain infrastructure and Sovereign compute

Q: Saudi Arabia is currently undergoing an unprecedented legal and economic transformation. How do blockchain and digital assets fit into this?

Seen through the lens of Vision 2030, this is a market-architecture question: how do we enable institutional-grade tokenisation, settlement and trusted compute while maintaining financial stability, clear accountability and enforceable controls across data, cybersecurity and critical infrastructure.

Q: Why is this an infrastructure-layer question?

Digital transformation has moved beyond digitising workflows to reshaping how value is issued, transferred, recorded and governed. Digital assets and distributed ledgers can deliver efficiency and programmability, but they can also concentrate risk: market integrity concerns, fraud exposure, sanctions risk and operational fragility as activity scales. The practical question is therefore not whether digital-asset activity will expand, but under what conditions it becomes investable, auditable and compatible with financial stability, cybersecurity and data-governance objectives. This is where sovereign compute becomes central: sovereignty is not a slogan, but a discipline of measurable controls, including data handling, privileged access, auditability, incident readiness and credible exit planning.

It is our intention to give readers a practical, infrastructure-oriented reading of the Saudi regulatory landscape as it stands today, drawing on public regulations and policy statements, complemented by market experience, and focusing on design choices that affect bankability, auditability and enforceability across borders.

It is important to note this is not legal advice and is intended purely as a roadmap for structured engagement.

Q: What are some of the key pieces of legislation which shape the current market architecture?

Key Saudi regulatory anchors that repeatedly shape these designs include the Personal Data Protection Law (PDPL), the National Cybersecurity Authority’s (NCA) Essential Cybersecurity Controls (ECC) and related critical national infrastructure standards (CNIs), the Communications, Space and Technology Commission (CST) cloud and datacentre compliance frameworks, and prudential and market conduct expectations communicated by the Saudi Central Bank (SAMA) and the Capital Market Authority (CMA). Where architectures or counterparties are cross border, extraterritorial export control and sanctions regimes can also become a binding design constraint.

Q: How important are these labels?

For infrastructure and policy design, labels are often less useful than function. What matters is what an instrument does, what activity it enables, and which regulatory perimeter it triggers. In practice, the spectrum includes: (i) digitally native instruments deployed only within supervised perimeters; (ii) tokenised real world assets (RWAs) anchored to recognised rights (for example, real estate, funds or receivables); (iii) payment-like instruments and settlement tokens designed for institution-grade use cases; and (iv) DLT-enabled infrastructure applications that change reconciliation, servicing or settlement mechanics.

Q: Are there any bankability concerns which are specific to the Saudi market?

In a Saudi context, bankability tends to depend on clarity of the underlying rights, verifiable ownership chains and contracts structured to minimise uncertainty and disputes. RWA models anchored to recognised rights and official registries may therefore present a more durable pathway than structures that rely purely on market convention. Recent initiatives led through the Real Estate General Authority (REGA) and the Real Estate Registry (RER) illustrate how registry-anchored RWA tokenisation models can move from pilot to scalable reality when anchored to official records and clear contractual controls.

Q: What would you say is a good way for investors to proceed?

A durable method is to map the perimeter by activity and risk domain, rather than starting with token labels and fitting obligations afterward. For most projects, the analysis typically spans three intersecting domains: (A) markets and investor protection (issuance, distribution, trading, disclosure); (B) payments and settlement (payment functionality, clearing, redemption, cross-border flows); and (C) data, cybersecurity, cloud and infrastructure governance (hosting, sovereignty, auditability).

Across these domains, cross-cutting Saudi instruments shape design constraints, including the PDPL, the ECC issued by the NCA, cloud regulatory requirements (including CST frameworks), and sectoral controls that can touch digital onboarding, payments, AML/CFT and electronic transactions. These do not create a single “digital assets law”, but they are often the binding layer for bankable deployment.

In practical terms, the regulatory perimeter for digital-asset and blockchain initiatives is often best mapped by reference to the underlying activity, rather than the label applied to the technology. A concise, non-exhaustive way to think about common workstreams and the primary Saudi touchpoints would be as follows:
• Issuance and tokenisation (including RWAs anchored to official registries): typically engages the CMA where the structure resembles a security, fund interest or marketable instrument, alongside any sectoral regulator that governs the underlying asset or registry.
• Custody and safeguarding: commonly centres on licensing, prudential controls, segregation, auditability and liability allocation. Depending on the business model, this may intersect with CMA requirements for securities custody and/or SAMA expectations for regulated financial services providers.
• Trading, marketplaces and brokerage: generally sits within the CMA’s perimeter where trading activity resembles a securities market. As a practical matter, sponsors should also factor the current posture toward retail-facing crypto-asset trading and design accordingly.
• Payments, settlement rails and token-based money-like instruments: typically engages SAMA’s mandate over payment systems and related financial-services activity, including AML/CFT controls, operational resilience and governance requirements.
• Infrastructure, hosting and operations (nodes, cloud environments, key management and incident response): engages CST and the NCA cybersecurity baseline, alongside PDPL and data-classification requirements where sensitive workloads are involved.
• Cross-border components (vendors, public chains, foreign counterparties and extraterritorial controls): often require parallel alignment with export controls and sanctions regimes where relevant, and clear contractual mechanisms on audit, suspension and termination to manage compliance and reputational risk.

Framed this way, any further analysis can focus on how these activity-based touchpoints shape bankability, governance, and the ‘durable pathways’ that can scale within Saudi Arabia’s institutional and regulatory architecture.

Q: But this mapping seems quite high-level.

The mapping is intentionally high-level. The applicable perimeter will depend on the activity label, the customer base (retail vs institutional), and the risk posture adopted by regulators.

The strategic point is that digital-asset activity frequently sits at the intersection. Regulating “the token” alone can miss the custody model, the hosting environment and the evidence controls that institutional participants and regulators require.

Q: Digital assets is a fast-evolving field. How does the virtual assets regime in Saudi differ from other major economies?

From a financial-regulatory perspective, Saudi Arabia does not yet operate under a single, consolidated “virtual assets” regime. In broad terms, SAMA has historically approached unregulated crypto-asset activity with caution. At the same time, supervised pilots, sandbox activity and institution-facing use cases continue to develop in parallel. For sponsors, the practical takeaway is that licensing, permissions and supervisory expectations may be determinative, and timelines can be longer than the underlying technology build.

Q: Can you give some example use cases?

Not all use cases are equal. The most durable pathways are typically infrastructure-grade, supervised and measurable in outcome. Two themes repeatedly stand out: (i) tokenised instruments that improve issuance, holding, transfer and servicing of recognised rights; and (ii) institution-grade settlement rails where governance is strongest, particularly where controls around identity, compliance and auditability are embedded by design.

Recent initiatives around RWA tokenisation—particularly where tokens are anchored to official registries—illustrate how “durable pathways” can move from pilot stage toward scalable infrastructure when legal title, controls and auditability are built in from day one.

Q: How is the current architecture shaped by AML and sanctions concerns?

AML/CFT, sanctions and governance requirements can drive fundamental architectural choices: for example, projects may shift from public-chain components to permissioned networks, relocate key control functions onshore, or redesign custody and access models to satisfy auditability and sanctions-screening expectations (including, where relevant, OFAC-aligned controls).

In one recent structuring exercise, an otherwise straightforward tokenisation model had to be reengineered once counterparties required auditable screening and controllable access: the architecture moved from open participation to a permissioned network with whitelisted participants, embedded transaction monitoring, and contractual “kill switch” and suspension rights—not because the technology demanded it, but because compliance and enforceability did.

For institutional participants, compliance is not “phase two”; it is the entry ticket. At scale, the non negotiables commonly include robust AML/CFT capability, sanctions risk management (including cross border exposure), governance and accountability, and the ability to produce evidence on demand. In a Saudi context, this typically sits alongside the Anti Money Laundering Law, the Law of Combating Crimes of Terrorism and its Financing and related implementing regulations, and (where cross border flows or foreign counterparties are involved) screening, contractual safeguards and operational controls calibrated to extraterritorial regimes.

Q: What do lawyers mean when they talk about ‘custody’ in this context?

Custody is where governance becomes concrete. Bankable structures typically define who controls keys and privileged access, under what approvals, and with what traceable evidence. This includes segregation of duties, multiparty approvals for critical actions, and clear operational responsibilities between technology providers, operators and regulated entities.

From a transaction perspective, custody design is also a risk allocation question: incident response, liability, insurance, audit rights, service levels and step in or replacement mechanics often determine whether a structure is financeable and scalable.

Q: And what about sovereign compute?

Sovereign compute is the infrastructure expression of trust and control: where compute runs, who can access it, how it is audited, and under which legal and technical constraints it operates. In Saudi Arabia, the relevant control stack can include the PDPL, the ECC, and CST’s Cloud Computing Regulatory Framework. This is also where the Kingdom’s “Cloud First” direction and cloud service classifications (for example, public cloud, private cloud and government/community cloud models) become practically relevant, because they shape which deployment architectures are acceptable for government and regulated-sector workloads, including enterprise blockchain nodes and settlement rails.

Sovereign compute is meaningful only when it becomes measurable, testable and auditable. In a Saudi context, design and assurance programmes will often need to align with the PDPL, national cybersecurity control frameworks (including the ECC), and cloud and digital government requirements (including the Cloud Computing Regulatory Framework issued by CST and any sector specific hosting rules that may apply). The practical implication is that sovereign compute should be framed less as a marketing label and more as a governable capability: one that is supported by clear data-classification, access governance, incident response, auditability and regulator ready reporting.

As sovereign compute clusters grow, threat actors increasingly use automation to scale credential theft, lateral movement and vulnerability discovery. This strengthens the case for disciplined privileged access governance, segmentation, secure engineering practices and continuous control assurance.

Q: And contracting?

Contracting is where policy goals become enforceable. Bankability is the contractual translation layer between policy objectives (trust, sovereignty and stability) and operational reality (who does what, when, and with what proof). For institutional investors and lenders, the essentials are familiar: clear allocation of operational responsibility; audit and access rights; liability and limitation regimes that match the risk profile; and robust business-continuity and incident-response obligations. Governing law and dispute resolution are also central. In Saudi-facing structures, market participants often look for a clear Saudi-law interface, with arbitration mechanisms that are credible to lenders and counterparties. For technology-heavy platforms, lenders also tend to expect auditable evidence packs (including for electronic records), clear change-management and step-in/termination mechanics, and to treat smart-contract logic as one layer within the broader contractual architecture.

Near term watchpoints include (i) further clarification of the regulatory perimeter for virtual asset activities and institutional tokenisation, (ii) the likely continued use (and gradual expansion) of regulatory sandboxes and pilot frameworks, and (iii) the emergence of bankable templates for registry anchored RWA models. Market participants may also monitor whether policy discussions develop around riyal linked settlement instruments or other controlled stable value structures, and how those would be supervised, given the Kingdom’s focus on monetary stability, consumer protection and system integrity.

Q: What are some other near-term watchpoints?

These would include: (i) how activity-specific rules develop across payments, capital markets and custody (including possible expansions of regulatory sandboxes); (ii) whether public and private platforms converge around a small set of recognised tokenisation pathways anchored to official registries; (iii) the treatment of stable-value settlement instruments and wholesale/retail use cases; and (iv) how cross-border compliance expectations (including sanctions and export-control) shape architecture choices for regional hubs.

Q: Do you have any other practical recommendations for readers?

There are a few:

• Start with defined activities and enforceable rights: anchor tokenised claims to recognised registries or contractual receivables before expanding to secondary trading.

• Design for auditability from day one: implement identity, logging, key management and incident-response controls that satisfy PDPL/ECC expectations and regulated-sector customers.

• Make custody and access governance explicit: clarify who controls keys, who can issue instructions, and what happens on insolvency, disputes or sanctions-related disruption.

• Treat cross-border compliance as architecture, not paperwork: map OFAC/export control constraints, ‘deemed’ scenarios and customer screening into the technical and contractual stack.

• Use contracts to de-risk scale: bankable governing-law and dispute-resolution choices, step-in rights, waterfall mechanics and clear service levels are what unlock financing and institutional adoption.

Q: Finally, how do you see things evolving in the months ahead?

Over the next 12–24 months, the most credible signal of progress will not be volume, but the emergence of the first wave of regulated, Saudi-hosted tokenisation and settlement platforms that prioritise auditable controls and contractual certainty over speed. Digital assets and sovereign compute become meaningful infrastructure only when built for accountability and proof. The conditions for sustainable scale are consistent: map the perimeter by activity, translate sovereignty into auditable controls, and encode trust into enforceable contracts that survive scrutiny and time.