The SAMA Compliance Checklist Nobody Gave Me

When we started building a fintech wallet that needed SAMA (Saudi Arabian Monetary Authority) compliance, I searched everywhere for a practical checklist. What I found was either too high-level ("implement good security") or too low-level (specific encryption algorithm requirements without context).

After going through two audits and building the compliance infrastructure for a 7-figure wallet product, here is the checklist I wish someone had given me.

Before You Write a Single Line of Code

1. Understand Which SAMA Framework Applies to You

Payment Service Provider (PSP) regulations from SAMA
PDPL (Personal Data Protection Law) requirements
E-commerce Regulations if you process online payments

Each framework has overlapping but distinct requirements. The PSP regulations are the strictest — if you comply with those, you will likely comply with the others.

2. Register Your Intent Early

SAMA requires you to submit your business plan and technical architecture for review before you start building. We waited three months for preliminary approval. Start this process on day one.

Technical Compliance Requirements

Data Encryption

At rest: AES-256 for all PII (Personally Identifiable Information). This means names, ID numbers, phone numbers, and addresses — encrypted before storing in the database.
In transit: TLS 1.2 minimum, TLS 1.3 preferred. No exceptions.
Key management: Store encryption keys separately from the data they encrypt. We used AWS KMS with key rotation every 90 days.

// NEVER store sensitive data in plain text
@Column(name = "national_id", nullable = false)
@Convert(converter = Aes256Encryptor.class)
private String nationalId;

Authentication & Authorization

Multi-factor authentication for all admin access (SMS OTP is acceptable, authenticator apps are preferred)
Role-based access control with audit logging for every role change
Session timeout of 15 minutes for admin portals, 5 minutes for financial operations
IP whitelisting for internal admin access

Audit Logging

Every financial transaction, user login, role change, and data access must be logged with:

Timestamp (UTC, never local time)
User ID
Action type
IP address
Device fingerprint
Request and response payloads (with PII masked in logs)

We stored audit logs in a separate database with append-only access. Even database administrators cannot delete or modify audit records.

Transaction Integrity

Every financial transaction must have a unique reference number
Transactions must be idempotent — processing the same reference number twice returns the original result
Balance checks must be atomic (use database transactions, not application-level locks)
Daily reconciliation reports comparing internal balances with bank statements

Business Continuity

RPO (Recovery Point Objective): Maximum 1 minute of data loss
RTO (Recovery Time Objective): Maximum 4 hours of downtime
Geographic redundancy with a failover site in a different region
Quarterly disaster recovery drills with documented results

The Audit Process

Pre-Audit Readiness Review (4-6 weeks before)

We hired a third-party security firm to perform a mock audit. They found 23 issues that would have been audit findings. We fixed all 23 before the real audit.

The Actual SAMA Audit

The auditors spent three days with us:

Day 1: Architecture review, data flow diagrams, encryption implementation
Day 2: Access control verification, audit log inspection, penetration testing results review
Day 3: Business continuity documentation, incident response procedures, and findings discussion

We passed with zero critical findings and two minor observations (one was about log retention duration, the other about password expiration policies).

The Checklist

Here is the practical checklist, organized by category:

Infrastructure

[ ] All data encrypted at rest (AES-256)
[ ] All data encrypted in transit (TLS 1.2+)
[ ] Key management system with rotation (KMS or equivalent)
[ ] Geographic redundancy (primary + DR site)
[ ] Network segmentation (app tier, data tier, management tier)
[ ] WAF (Web Application Firewall) configured

Application

[ ] MFA for all admin access
[ ] RBAC with principle of least privilege
[ ] Idempotent transaction processing
[ ] Comprehensive audit logging
[ ] Input validation on all endpoints
[ ] Rate limiting on all public APIs
[ ] Session management with proper timeout
[ ] CSP headers configured
[ ] No sensitive data in URLs or logs

Operations

[ ] Incident response plan documented and tested
[ ] Quarterly DR drills documented
[ ] Penetration test results (annual)
[ ] Vulnerability scanning (continuous)
[ ] Change management process with approval workflows
[ ] Monitoring and alerting for all financial transactions

Compliance

[ ] SAMA registration and preliminary approval obtained
[ ] PDPL compliance documented
[ ] Data residency requirements met (data stored in KSA)
[ ] Third-party security assessment completed
[ ] All findings from pre-audit resolved

What Nobody Tells You

The compliance process takes 6-12 months from start to finish. Budget your timeline accordingly.
You will need a dedicated compliance officer. This is not a part-time responsibility.
SAMA auditors appreciate documentation more than implementation. A well-documented process with minor gaps is better than a perfect implementation with no documentation.
Start your DR drills immediately, not when the audit approaches. You need at least two documented quarters of successful drills.