Quick answer: A fintech MVP intended for the SAMA Regulatory Sandbox should be more than a clickable prototype. SAMA's current sandbox framework explicitly assesses MVP and technology readiness for testing, alongside innovation, consumer benefit, risk mitigation, and an exit plan. :contentReference[oaicite:0]{index=0}

• Typical regulated fintech MVP: SAR 120,000–200,000
• Typical delivery timeline: 10–16 weeks for an MVP designed for regulated testing
• The goal: Build the security, identity, audit, consent, monitoring, and environment controls into the first production-ready codebase so you are not rebuilding the architecture after your sandbox application or operational-readiness assessment.

The Saudi Central Bank's Regulatory Sandbox is designed to let eligible innovators test new financial products, services, technologies, and business models in a supervised environment before wider deployment. The current framework is not simply a place to demonstrate an idea: its eligibility criteria include MVP and technology readiness for testing, and the application asks specifically about whether an MVP is ready, integrations, test scenarios, partnerships, and the applicant's operational plan.

For a fintech founder, that changes how the MVP should be built. The objective is not to build every enterprise feature before applying to SAMA, but to make the core architecture capable of carrying the product through testing without replacing its security, data, identity, logging, and transaction foundations later.

What the SAMA Regulatory Sandbox is — and who it is for

SAMA's Regulatory Sandbox is a supervised testing environment for eligible fintech innovators proposing new digital business models, concepts, or technologies that fall within the sandbox's scope. The current framework allows several applicant categories, including SAMA-licensed innovators, non-licensed local fintechs and startups, and certain non-licensed international fintechs.

The framework also makes an important distinction: the sandbox is not intended to be used to circumvent existing legal or regulatory requirements, and it is not intended for technology that is too immature for testing. Applicants must demonstrate genuine innovation, identifiable consumer or market benefit, risk assessment and mitigation, readiness for testing, and an exit plan.

SAMA's current process has four stages: application, operational readiness, testing, and exit. The current operating model gives the application stage a stated timeframe of up to 60 business days and the operational-readiness stage a period of up to 120 days, so founders should not confuse a 10–16-week software build with the full regulatory journey.

In June 2026, SAMA also launched an enhanced Regulatory Sandbox service through its e-services portal, with integrated processes for submitting and tracking applications.

For capital-market products, the relevant regulator is different. The CMA FinTech Lab provides an experimental environment for innovative FinTech products, services, and business models related to securities activities, with a FinTech Experimental Permit used for testing within defined parameters and timeframes.

That distinction matters before development starts: a payments, lending, BNPL, or banking-related proposition may fall into a SAMA pathway, while a securities-related product may instead belong within the CMA framework.

Why a normal fintech MVP can become a regulatory rebuild

A conventional startup MVP is often designed around one question:

Can users complete the core transaction?

A regulated fintech MVP has another question:

Can we demonstrate how the transaction, identity, data, access, consent, audit trail, and operational controls work?

A founder may initially build registration, login, a dashboard, payments, and a transaction flow. Six months later, the team discovers that customer identity evidence was not structured correctly, privileged actions were not logged, production and testing environments share resources, consent cannot be reconstructed, or sensitive data is stored without the required architecture.

That is where the expensive rebuild begins.

The better approach is to keep the product scope small while keeping the architectural foundations deliberate.

---

The 8 architecture decisions to make at MVP stage

1. KSA data residency and PDPL architecture

Decide where customer, transaction, identity, and operational data will live before writing the first production database schema.

A fintech MVP should separate sensitive data logically, define who can access it, document data flows, and make the hosting and backup architecture compatible with the applicable Saudi data-protection requirements.

This does not mean every MVP needs a huge enterprise data platform. It means the initial architecture should not make future data governance impossible.

Plain-language translation: You can launch with fewer features. You should not launch with a database structure that becomes impossible to govern once real customers arrive.

For Saudi fintech products, data classification should be considered alongside encryption, access control, retention, backups, logging, and third-party integrations.

---

2. NAFATH identity and KYC

If the product requires verified Saudi identity, identity architecture should be considered at MVP stage rather than added as a separate login feature later.

The application should have a clear identity model separating the user account from verification evidence and the status of the KYC process. Integration points should also be designed so identity verification can be replaced or expanded without rewriting the customer model.

Where NAFATH is relevant to the product and regulatory pathway, the integration should be treated as part of the identity architecture rather than as a cosmetic verification step.

Plain-language translation: The system needs to know not only that someone has an account, but also what was verified, when it was verified, what the verification status is, and which actions that identity is allowed to perform.

---

3. Encryption at rest and in transit

Sensitive fintech data should be protected both while moving between services and while stored.

TLS should protect service-to-service and client-to-server communication, while database and storage encryption should protect information at rest. Secrets such as API credentials, encryption keys, database passwords, and third-party tokens should not be hard-coded into application repositories.

A regulated MVP does not need hundreds of microservices to demonstrate good security architecture. A well-structured modular application with controlled secrets and clear service boundaries can be much easier to review and operate.

Plain-language translation: If the MVP handles money or financial information, security cannot be something the team adds after the first demo.

---

4. Audit logging

A fintech system should be able to answer:

• Who performed this action?
• What did they change?
• When did they change it?
• Which customer or transaction was affected?
• What was the previous state?
• What happened afterward?

That requires structured audit events rather than ordinary application logs.

For example, an administrative user changing a transaction status should create an auditable event containing the operator identity, timestamp, affected record, action, and result.

Plain-language translation: If someone asks six months later why a transaction changed, the system should have an answer.

Audit logging should also cover security-sensitive events such as privileged access, authentication changes, KYC status changes, configuration changes, and transaction exceptions.

---

5. Role-based access control and MFA

Do not build one generic admin role and assume it will be sufficient.

Define roles according to actual operating responsibilities. A compliance user may need access to customer verification records without being allowed to modify payment configurations, while an operations user may need transaction visibility without access to sensitive identity information.

MFA should be incorporated into privileged access from the beginning.

Plain-language translation: Your MVP can have five screens instead of fifty, but those five screens should not give everyone the same keys.

---

6. Consent capture

Consent should be represented as data.

The system should be able to record what the customer consented to, the applicable version of the notice or terms, when the consent was provided, and where appropriate, when consent was withdrawn.

This becomes particularly important when fintech products use customer data for communications, financial recommendations, open-banking access, or other purposes requiring clear authorization.

Plain-language translation: A checkbox is not the same thing as an auditable consent record.

---

7. Transaction-monitoring hooks

You do not necessarily need a huge transaction-monitoring platform in version one.

You do need an architecture that can produce the events required for monitoring later.

A transaction should have structured attributes such as customer, amount, timestamp, channel, destination, status, and relevant risk signals. The system should make it possible to apply rules or connect a monitoring engine without redesigning the payment flow.

For example, an MVP can start with basic velocity checks, transaction limits, flagged patterns, and manual review queues where appropriate.

Plain-language translation: Build the plumbing now even if the sophisticated monitoring dashboard comes later.

---

8. Separation of environments

Development, staging, and production should not be the same environment with different passwords.

Use separate databases, credentials, storage, API keys, and deployment configurations. Production data should not simply be copied into development for convenience.

SAMA's sandbox guidance also makes clear that unauthorized testing with live data in production environments is not permitted; testing with banks and financial institutions before acceptance is limited to development environments with dummy data.

Plain-language translation: Your developers need a safe place to break things without breaking customer financial data.

---

What can stay manual in the MVP — and what cannot

A common mistake is assuming that a regulated MVP needs every operational workflow fully automated before testing.

It does not.

The better distinction is between manual operations that sit around a controlled system and missing controls inside the system itself.

Can reasonably remain manual at MVP stage	Should be designed into the system
Periodic reporting exports	Authentication and access control
Some back-office reconciliation	Audit logging
Manual compliance review queues	Transaction records and status history
Manual customer support workflows	KYC status and identity records
Some operational approvals	Consent capture
Spreadsheet analysis for internal planning	Encryption and secrets management
Manual test-case preparation	Environment separation
Scheduled management reports	Transaction-monitoring event hooks

For example, an operations employee may manually download a CSV and prepare a management report during early testing.

That does not mean the transaction database should lack timestamps, unique transaction IDs, customer references, status history, and audit events.

The principle is simple: automate less, but architect correctly.

---

Sub-sector notes: the MVP architecture changes with the product

Payments

Payment products need transaction-state architecture from day one.

A payment should move through explicit states such as initiated, authenticated, submitted, successful, failed, reversed, or under review where applicable. Idempotency, reconciliation hooks, transaction identifiers, and failure handling should be designed before the first live test.

For broader Saudi fintech architecture considerations, see SAMA-compliant fintech software development in Saudi Arabia.

Plain-language translation: A payment app cannot treat a successful API response as the entire story. The system needs to know what happened before, during, and after the payment.

---

BNPL

BNPL architecture needs more than checkout and repayment screens.

The MVP should model customer eligibility, financing decisions, repayment schedules, payment status, overdue states, limits, and the relevant audit trail. Risk and affordability logic should be isolated from the user interface so it can be reviewed and changed without rewriting the application.

See the dedicated BNPL app development guide for Saudi Arabia for the broader product architecture.

Plain-language translation: If your MVP approves credit, the approval logic should not be buried inside a button-click handler.

---

Digital lending

A lending MVP needs structured customer, application, decision, facility, repayment, and exception records.

The architecture should also leave room for credit-decision inputs, document verification, repayment events, collections workflows, and monitoring without turning the first version into an enterprise loan-management platform.

Logiolegion's Saudi SME digital lending platform development guide covers the broader lending architecture.

Plain-language translation: Start with one lending product and one clear customer journey, but make every financial decision traceable.

---

Wealth and savings

Savings and investment products require careful separation between customer instructions, balances, financial products, transactions, and reporting.

For an Islamic savings-circle concept, founders may not need to build the entire platform from zero. Logiolegion also offers Halqa, a ready-made savings-circle infrastructure option, where a product fits that model.

Plain-language translation: If the business model already fits an existing product foundation, buying or adapting that foundation can be more practical than rebuilding every component.

---

Open banking

Open-banking products need explicit consent, account-access permissions, token handling, data-access scopes, API logging, and clear separation between customer authorization and financial data retrieval.

The architecture should make it possible to demonstrate which data was requested, why it was requested, what the customer authorized, and when the authorization changed or ended.

See open banking app development in Saudi Arabia for a deeper look at the Saudi open-banking environment.

Plain-language translation: The MVP should be able to explain exactly what financial data the customer allowed you to access.

---

Build for the sandbox — not just for the demo

SAMA's application process specifically asks applicants about their MVP and technological readiness, including whether an MVP is ready for testing, integrations, test scenarios, and relevant partnerships.

That means the MVP should demonstrate more than a polished customer interface.

A useful pre-application technical package can include:

• System architecture diagram
• Data-flow diagram
• Authentication and identity flow
• KYC process
• Role and permission matrix
• Environment architecture
• API documentation
• Audit-log design
• Transaction-state model
• Encryption approach
• Backup and recovery approach
• Monitoring and alerting design
• Integration inventory
• Test scenarios
• Known limitations and manual controls

The point is not to produce paperwork for its own sake.

The point is to make the software understandable to the people who will eventually assess, test, operate, secure, and support it.

---

The MVP should carry into operational readiness

SAMA's current sandbox lifecycle moves from application into an operational-readiness stage before live sandbox testing. The current framework states that eligible innovators receive pre-go-live requirements through an assessment criteria process and have a defined operational-readiness period to meet those requirements. :contentReference[oaicite:9]{index=9}

This is why building a disposable prototype can create problems.

Suppose version one has:

• temporary authentication,
• shared database credentials,
• no audit history,
• hard-coded KYC states,
• no consent versioning,
• no staging environment,
• and transactions stored as basic rows without lifecycle states.

You may have something that demonstrates the idea.

But you do not have a strong foundation for the next stage.

A regulated MVP should therefore be small in features but deliberate in architecture.

---

Cost of doing it correctly at MVP stage vs retrofitting later

The cost difference is not only about developer hours.

Retrofitting regulated architecture can require database migrations, security redesign, new authentication flows, data restructuring, infrastructure changes, testing, documentation, and rework across the frontend and backend.

Area	Built into MVP	Retrofitted later
Identity and KYC	Designed into user model	User records may need migration
Audit logging	Events captured from first transaction	Historical actions may be impossible to reconstruct
Consent	Versioned from launch	Existing consent records may be incomplete
RBAC	Roles designed around workflows	Permissions often require application-wide changes
Environment separation	Infrastructure starts correctly	Production migration becomes more disruptive
Transaction monitoring	Events structured from day one	Existing transaction data may lack required signals
Encryption	Storage and transport designed together	Data migration and credential rotation may be required
Reporting	Structured records support exports	Historical data may require manual reconstruction

The underlying lesson is the same one covered in Logiolegion's SAMA-compliant fintech software development guide: the earlier security, compliance, identity, and operational requirements are reflected in the architecture, the less likely they are to become a separate rebuild project.

---

How long does a SAMA-ready fintech MVP take?

A regulated fintech MVP typically needs 10–16 weeks when the scope is controlled and the architecture is planned around the relevant regulatory testing requirements.

A practical delivery sequence can look like this:

Phase	Typical focus
Weeks 1–2	Product discovery, regulatory-scope mapping, architecture
Weeks 3–5	Core backend, database, authentication, KYC
Weeks 6–8	Core fintech workflows, transaction engine, integrations
Weeks 9–11	Audit logging, RBAC, MFA, consent, monitoring hooks
Weeks 12–14	Admin operations, reporting, security testing
Weeks 15–16	UAT, deployment, documentation, testing preparation

The exact sequence depends on the product.

A payment MVP with several external integrations can require more integration work, while a simpler workflow with fewer external dependencies can spend more time on customer experience and operational controls.

The 10–16 weeks refers to the software development window, not SAMA's application and operational-readiness timelines.

---

Regulated fintech MVP pricing

A regulated MVP should be priced according to the financial workflow, integrations, security requirements, and testing readiness rather than the number of screens.

MVP tier	Typical scope	Indicative price
Fintech prototype	Core customer journey, basic backend, admin panel, architecture foundation	SAR 60,000–100,000
Regulated fintech MVP	KYC, RBAC, audit logging, consent, transaction architecture, integrations, security foundation	SAR 120,000–200,000
Advanced regulated platform	Multiple financial workflows, external integrations, monitoring, reporting, advanced operations	SAR 200,000–350,000+

The SAR 120,000–200,000 range is the relevant starting point for a regulated fintech MVP intended to progress toward supervised testing.

These are development estimates rather than regulatory fees, licensing costs, third-party charges, infrastructure costs, or professional legal/compliance advisory fees.

---

Custom fintech MVP or ready-made infrastructure?

Not every fintech idea needs to start with a completely blank codebase.

For a new financial product with unusual workflows, a custom MVP can make sense because the product logic, customer journey, integrations, and regulatory controls need to be designed around the specific proposition.

For an Islamic savings-circle product, the alternative may be a ready-made foundation. Logiolegion offers both a custom-built fintech MVP and Halqa, a ready-made savings-circle infrastructure option.

The right path depends on how closely the product matches the existing infrastructure and how much custom financial logic the founder needs.

---

What makes a fintech MVP actually ready for SAMA testing?

A useful way to think about readiness is to divide it into five layers.

Product readiness

The core customer journey works end to end.

A tester should be able to understand what the product does, who it serves, what problem it solves, and how the proposed innovation differs from existing offerings.

Technology readiness

The system can actually execute the test scenario.

SAMA's eligibility criteria specifically include MVP and technology readiness for testing, along with an operational-readiness and testing plan.

Security readiness

Identity, access control, MFA, encryption, logging, secrets management, environment separation, and security testing have been considered rather than left as future work.

Operational readiness

Someone inside the company knows how to handle failed transactions, customer complaints, incidents, manual reviews, system outages, and operational exceptions.

Regulatory readiness

The team understands the relevant regulatory pathway, the scope of the sandbox, the proposed testing boundaries, consumer risks, mitigation measures, reporting requirements, and exit plan.

SAMA's eligibility framework explicitly considers consumer benefits, risks and mitigations, resources for consumer redress, testing milestones, prior simulations, and the ability to mobilize resources after acceptance.

---

The biggest mistake: treating compliance as a final sprint

A founder can postpone a marketing website.

They can postpone a loyalty programme.

They can postpone an advanced analytics dashboard.

They should be much more careful about postponing the foundations that determine whether the system can be secured, audited, tested, and operated.

The goal is not to build a massive banking platform before proving the idea.

The goal is to build a focused MVP on an architecture that can survive the next stage.

That distinction can save a fintech team from building the same backend twice.

---

Why Logiolegion for a SAMA Sandbox fintech MVP?

Logiolegion approaches a regulated fintech MVP as a product and software architecture problem, not simply as a UI development project.

The development approach can cover:

• Product discovery and MVP scope
• Saudi fintech architecture
• NAFATH and KYC workflows
• RBAC and MFA
• Audit logging
• Consent architecture
• Transaction-monitoring hooks
• Secure API architecture
• Environment separation
• Fintech integrations
• Admin and compliance workflows
• Security testing preparation
• Technical documentation for testing

For founders evaluating the broader development landscape, see MVP development in Saudi Arabia.

The company also supports product-specific fintech work around SAMA compliance, open banking, fintech APIs, and regulated financial workflows.

If your proposition is an Islamic savings-circle product, the alternative is not necessarily a new custom build: Halqa provides a ready-made savings-circle infrastructure option.

---

Final thoughts

A SAMA Sandbox fintech MVP does not need to contain every feature you eventually want to build.

It does need to demonstrate a credible product, a testable technology foundation, appropriate risk controls, and an architecture that can move into the next stage without being replaced.

SAMA's current framework explicitly evaluates MVP and technology readiness, and its application process asks applicants to demonstrate readiness for testing rather than simply presenting an idea.

Build the smallest product that proves the business model, but build the identity, security, audit, consent, monitoring, and environment foundations as if the next version will be the one entering testing.

If you are asking "what does my fintech MVP need before applying to SAMA?", that is the right question to answer before development begins.

Talk to Logiolegion about your fintech MVP →

---

Frequently Asked Questions

1. What is the SAMA Regulatory Sandbox?

The SAMA Regulatory Sandbox is a supervised environment where eligible innovators can test new financial products, services, technologies, or business models within defined parameters. SAMA's current framework covers application, operational readiness, testing, and exit stages.

2. Who can apply to the SAMA Regulatory Sandbox?

SAMA identifies several applicant categories, including SAMA-licensed innovators, non-licensed local fintechs and startups, and certain non-licensed international fintechs. The route can differ depending on whether the applicant is already licensed and whether it works with a Saudi Central Bank-licensed partner.

3. What does SAMA look for in a fintech MVP?

The current eligibility framework includes MVP and technology readiness for testing as one of four major eligibility areas. Applicants also need to address genuine innovation, consumer or market benefits, risks and mitigations, operational readiness, and an exit plan.

4. How do I build a fintech app that SAMA can test?

Logiolegion builds fintech MVPs with the core testing architecture considered from the start. A typical technical foundation includes KYC and identity workflows, RBAC and MFA, encryption, structured audit logs, consent records, transaction-monitoring hooks, and separate development, staging, and production environments. The aim is to keep the MVP focused while making the codebase suitable for progression into regulated testing.

5. Does my fintech MVP need NAFATH before applying to SAMA?

Logiolegion treats identity as an architectural decision rather than simply a login screen. Where NAFATH is relevant to the product and regulatory pathway, the MVP can structure the identity model around verification status, customer records, and controlled access to identity evidence. The technical proof point is a separated identity and KYC state model that allows verification workflows to evolve without rewriting the customer account system.

6. Should audit logging be included in a SAMA Sandbox MVP?

Logiolegion recommends designing structured audit logging into the MVP when the product will process regulated financial activity. The audit layer can capture operator identity, timestamps, affected records, actions, and outcomes instead of relying only on ordinary application logs. This gives the testing environment a traceable record of security-sensitive and operational events.

7. Can some fintech MVP operations remain manual before SAMA testing?

Yes, Logiolegion can design an MVP where selected back-office activities remain manual while the core financial records remain structured. For example, reporting exports or manual review queues can be operated by staff while transaction IDs, status changes, KYC states, consent records, and audit events are captured automatically. The technical proof point is the separation between a manual operational workflow and the underlying system-of-record data.

8. How much does a regulated fintech MVP in Saudi Arabia cost?

Logiolegion's indicative range for a regulated fintech MVP is SAR 120,000–200,000, typically over 10–16 weeks, depending on integrations and product complexity. A smaller fintech prototype can start around SAR 60,000–100,000, while an advanced regulated platform can move into the SAR 200,000–350,000+ range. The regulated MVP architecture includes elements such as RBAC, audit logging, consent, transaction architecture, KYC, integrations, and security foundations.

9. How long does it take to build a fintech MVP for the SAMA Sandbox?

Logiolegion typically plans 10–16 weeks for a regulated fintech MVP when the scope is controlled. The development window can include discovery, architecture, core workflows, KYC, integrations, audit logging, access control, security testing, UAT, and technical documentation. SAMA's own application and operational-readiness stages are separate from this software-development timeline.

10. Can Logiolegion build an Islamic savings-circle fintech MVP without starting from zero?

Yes. Logiolegion offers both a custom-built fintech MVP and Halqa, a ready-made savings-circle infrastructure option. Halqa can be relevant when the proposed product closely matches the savings-circle model, while a custom MVP is appropriate when the business needs substantially different workflows. The technical proof point is that a custom path can model the product's own member, contribution, cycle, and operational logic rather than forcing it into a generic banking workflow.

11. What is the difference between the SAMA Sandbox and the CMA FinTech Lab?

Logiolegion treats the regulator as a product-scope decision made before development begins. SAMA's Regulatory Sandbox is designed around eligible financial innovations within the Saudi Central Bank's scope, while the CMA FinTech Lab is focused on innovative FinTech products, services, and business models related to securities activities.

12. Can Logiolegion help with a fintech MVP before a SAMA Sandbox application?

Yes. Logiolegion can work on the software architecture, MVP scope, fintech workflows, integrations, security foundations, technical documentation, and testing preparation. A typical proof point is a documented architecture covering identity, transaction processing, audit logging, consent, access control, monitoring hooks, and separated environments. Regulatory eligibility and approval remain matters for SAMA and the applicant's legal and compliance advisers.

---

Related resources

• SAMA-compliant fintech software development Saudi Arabia
• Open banking app development Saudi Arabia
• BNPL app development Saudi Arabia
• Saudi SME digital lending platform development
• Islamic fintech app development Saudi Arabia
• Halqa savings-circle platform
• MVP development Saudi Arabia

Note: The compliance discussion in this article is for general informational purposes and is not legal, regulatory, tax, or licensing advice. Founders should confirm their specific regulatory pathway and requirements with SAMA, CMA, and qualified Saudi legal or compliance advisers.