Building Payment Systems Under SAMA and ADGM Rules: A Practical Guide 

A fintech founder we advised had a payment product live in the UAE under an ADGM sandbox licence and assumed the Saudi launch was a deployment task. Same code, new region, maybe a translation pass. Eight months later they were still in SAMA's review process, rebuilding their transaction layer to meet requirements that ADGM had never asked about. Nothing about that surprised us, and it shouldn't surprise you either. SAMA compliant payment gateway development and ADGM-regulated development are overlapping but distinct disciplines, and the differences live in the architecture, not the paperwork. Here's the practical version of what each regulator wants and where teams get caught.

Two Regulators, Two Philosophies

ADGM, the Abu Dhabi free-zone regulator, runs a principles-based regime through its Financial Services Regulatory Authority. It cares that you can demonstrate sound risk management and operational resilience, and its sandbox lets you launch limited products while you prove it. SAMA, the Saudi Central Bank, is prescriptive. Its Cyber Security Framework spells out control families you implement and evidence, item by item, and its payment services rules define specific expectations for transaction integrity, dispute handling, and reporting. The practical consequence: an ADGM submission is largely an argument, while a SAMA submission is largely an audit. Teams that treat SAMA like ADGM show up with a well-written risk narrative and get sent back for control-level evidence they never built the tooling to produce.

Data Residency Decides Your Infrastructure Before You Do

SAMA expects financial data for Saudi customers to be hosted in the Kingdom, and that single requirement cascades through everything. It's why the major clouds stood up Saudi regions, and it's why your architecture needs a clean answer to the question 'which data can leave, and which can't.' On one wallet build we scoped, the original design used a single EU-hosted ledger with regional read replicas. That design was dead on arrival for Saudi Arabia. The rebuilt version ran a full ledger instance in a Saudi region with only anonymized aggregates leaving the country for analytics. Plan for this on day one: retrofitting residency into a single-region system means touching every service that stores or moves customer data, which on a mature codebase is a six-figure exercise.

The Transaction Layer Carries the Compliance Load

Both regimes ultimately care about the same operational questions. Can you reconstruct any transaction end to end? Can you detect and report suspicious activity? Do failed payments leave money in a knowable state? That translates into engineering requirements: an immutable, double-entry ledger rather than balance columns you update in place, idempotency keys on every payment operation so retries can't double-charge, and reconciliation jobs that compare your ledger against processor settlements daily and page someone when they diverge. We treat a mismatch above a few hundred riyals as an incident, not a ticket. AML screening also has to sit in the flow itself, not in a nightly batch, because SAMA expects real-time controls on sanctioned parties and thresholds. None of this is exotic. All of it is much cheaper on day one than on day four hundred.

Build the Evidence Trail as a Feature, Not an Afterthought

Here's the difference between teams that sail through a SAMA review and teams that stall in it: the first group can produce evidence on demand. Access reviews, deployment approvals, incident timelines, key rotation records, the audit log for any transaction. When a reviewer asks how you know an engineer can't read production card data, 'our policy forbids it' is a wrong answer and 'here's the access matrix, the last quarterly review, and the log of every production access this month' is a right one. We build the evidence tooling into the platform itself: structured audit events from day one, an admin surface that exports them per control family, and deployment pipelines that record who approved what. It sounds bureaucratic. It's actually about 3 to 4 percent of the build effort, and it converts every future audit, and there will be many, from a two-week scramble into a half-day export. The teams that bolt this on later pay for it every single year.

Timelines and Numbers Worth Planning Around

From what we've seen across engagements, realistic planning looks like this. ADGM sandbox admission takes roughly two to four months of preparation if your documentation is honest and your controls exist. SAMA authorization for payment services commonly runs six to twelve months including review cycles. Penetration testing is mandatory in both regimes and needs to be booked with an approved firm about eight weeks before you need the report. Budget-wise, expect compliance engineering to consume 20 to 30 percent of the build on a first regulated product: the ledger discipline, the logging and evidence tooling, the residency architecture, and the test cycles. Founders who budget compliance as a legal line item instead of an engineering one are the ones who discover the gap mid-review.

A Pre-Build Checklist

• Decide which regulator's regime applies to each market, and design for the strictest one you'll face within two years
• Settle data residency per country before choosing infrastructure, not after
• Build the ledger as double-entry and append-only from the first commit
• Put idempotency keys and daily reconciliation in the first release, not the hardening phase
• Book the penetration test and start the evidence binder eight weeks before submission
• Budget 20 to 30 percent of engineering effort for compliance on a first regulated build

The Honest Takeaway

Regulated payments in the GCC reward teams that read the actual frameworks and punish teams that pattern-match from other markets. The founder from the opening did eventually launch in Saudi Arabia, and the rebuilt transaction layer turned out to be a better product: fewer reconciliation surprises, cleaner dispute handling, easier audits. Compliance done in the architecture tends to work that way. It feels like overhead until the first incident, and then it feels like the reason you still have a licence.