Licensing and sandboxesالترخيص والبيئة التجريبية Sandbox

A licence is a regulator's permission to carry on one particular financial activity. A regulatory sandbox (البيئة التجريبية) is a temporary, bounded permission to test a product on a small number of real customers under closer supervision.

A screen map alone does not tell you what business you are actually operating.

Why not launch first and get licensed later?

Every founder arriving from software asks this. A tech product ships and then gets corrected, and the market is the judge. So why does that not apply here?

Because a mistake with money is not fixed by an update.

Ship a delivery app badly and users leave and you lose your own money. Ship a financial product without permission and fail, and thousands of people have lost their money, and there is no new release that returns it.

So a licence is not a fee you pay or a form you fill. It is proving in advance that you can do what you are about to promise: that your capital is sufficient, that your systems hold, that you employ someone who knows the rules and signs in their own name, and that you have a plan for what happens if the company shuts down.

There is a second, less obvious reason: operating unlicensed is a crime under most regimes, not an administrative breach. The fine is not the worst outcome. Being closed permanently and barred from the sector afterwards is. What you gained from launching early costs you the whole market.

Regulators understood that tension, which is why a middle path exists that you will read about shortly: testing your product on a limited number of customers under supervision, before holding the full licence.

Start with the activity

Regulatory permission attaches to a financial activity, not the label in a company registration. A business calling itself a technology platform may receive customer funds and pass them to merchants. Another may sell accounting software without touching a riyal. Both can display a payment button, but the first may need permission while the second remains a technology supplier.

Break a proposed product into actions before designing its journey. Identify who receives funds, where they remain, who chooses their destination, who bears credit risk, and who promises a return. Map each action to its contract, account, and data flow. The regulated activity then becomes visible behind the marketing language.

Calling the business an intermediary does not settle the issue. An app may redirect a customer to a licensed bank without seeing or controlling money. Another app may collect funds into an account in its own name and settle with merchants later. That small screen-level difference changes possession, responsibility, and potentially the permission required.

Three authorities for different functions

The Saudi Central Bank, or SAMA, supervises banking, payments, finance, credit, and other activities within its mandate. A wallet holding stored value is not merely a shopping app. A provider carrying payments between customers and merchants does not become a neutral messenger because it does not manufacture the goods.

The CMA, or CMA, oversees securities and capital-market business. A platform arranging an investment in a fund or managing a portfolio does not fall under SAMA merely because money travels through a bank. The investment function and the bank's account or transfer function retain their own regulatory treatment.

The Insurance Authority supervises Saudi insurance. An app offering phone-screen protection may only distribute the product, while the licensed insurer issues the policy and underwrites the risk. One checkout journey can contain insurance and payment functions, each with its own framework.

Follow the function rather than the most visible logo. If a bank lends to an ecommerce app's customer, the lending activity remains with the bank even when the app owns the interface. If the app bears credit risk or promises finance in its own name, the analysis changes. Contracts and flows matter more than screenshots.

A sandbox (البيئة التجريبية) is a limited test

A regulatory sandbox lets an innovation be tested under supervision. It is neither a full licence nor open-ended permission. The authority may impose a customer cap, maximum amounts, and a fixed test period. It may also require regular reporting, customer redress, and an exit plan.

The test purchases evidence, not immunity. A company can show that verification works, customers understand the offer, and complaints are handled. The authority can observe a new risk at a containable scale. The test then ends with a next step such as applying for a licence, changing the model, or stopping it.

Sandbox admission must not be marketed as permanent regulatory approval. A customer may read "regulator (الجهة الرقابية) approved" as an endorsement of the company or product. Admission only allows a conditional test; it is not a recommendation to buy.

Core controls still apply during the test. The company must identify customers, protect data, retain records, and handle complaints under its applicable conditions. It must monitor test limits and stop onboarding at the cap. A system unable to count customers or value cannot obey its sandbox boundary.

A licensed partner is an operating route

A product can be delivered with a company that already has the required permission. A licensed bank or payment provider might hold funds and execute transfers, while your app provides the interface, customer service, and technical connection. This is a common legitimate model when the roles are genuine and clear.

The partner does not remove every obligation from your company. An agent or distributor may need approval, registration, or specific operating conditions. Data protection, promotions, complaints, and cybersecurity duties may still apply. The licensed partner will often demand audit rights and incident reports because your failure can affect its customers and licence.

The contract should identify who accepts the customer, owns the balance, executes refunds, screens sanctions, monitors transactions, and answers complaints. Saying that both parties are responsible for compliance without allocating the work leaves an ownerless gap.

Failures expose whether the model is real. A customer whose account was debited without merchant receipt needs one party to track the case. If the partner restricts a suspicious account, the platform must know what it may tell the customer. If the partnership ends, both companies need a plan for balances, records, and customer communications.

The compliance officer (مسؤول الامتثال) is a named person

A compliance officer needs a name, authority, information, and access to management. The role is not a signature added to the end of an application. It translates requirements for the team, reviews controls, escalates breaches, and manages regulatory reports and deadlines.

That work cannot begin after the product is complete. Compliance needs to participate in decisions about pricing, money flows, outsourcing, and launch. The officer needs access to incidents and senior management rather than an approval chain that hides bad news. The board and executives retain their own responsibilities; one person does not carry the entire framework alone.

Evidence matters as much as policies. Approval logs show who authorised a change. Training records show who understood an obligation. Monitoring reports show exceptions and their closure. A polished policy is weak evidence when the system contradicts it every day.

Check permission before design

Describe the product using verbs rather than brand language. Say that the company receives one riyal from a customer, holds it for two days, and sends it to a shop. Do not begin with a claim about building intelligent commerce. Then draw the parties, accounts, timing, risks, and customer promises.

Compare each action with the relevant authority's rulebook, activity definitions, and exemptions. Put the map before legal specialists, the compliance officer, and the authority where appropriate. Do this before technology and advertising contracts are signed.

Evaluate four routes: a full licence, a sandbox test, a licensed partnership, or a model that genuinely avoids performing the regulated activity. Each route has different cost, time, control, and limits. The fastest route may not fit if the partner would own the relationship on which the product depends.

Finally, write the decision so an engineer can apply it. Define which funds the system may touch, which limits it must enforce, which records it must retain, and what happens after an incident. Regulatory permission then becomes a set of design constraints that can be built and tested, not a legal file discovered at launch.