For a Saudi fintech product, first choose one customer journey, identify who will handle the money or financial data, and establish the regulatory and provider route. Build a testable version around that decision, with simulated data where live access is not available. A development sprint can produce a useful first version, but bank onboarding, security work and any regulatory approval have their own timelines and costs.
TL;DR
- Start with one financial workflow and simulated data while you establish the regulatory route and provider access.
- SAMA's Open Banking Lab simulates bank APIs. Its Regulatory Sandbox is a separate, controlled test for eligible new models.
- SAMA's sandbox FAQ describes a six-to-twelve-month live testing stage after readiness; a 45-day build is not a licensing timeline.
- A Micro Payment Institution license requires at least SAR 1 million in paid-up equity and a SAR 20,000 issuance fee; capital is not the fee.
- Hapy advertises a US$4,999 scoped 45-day sprint. One supplier estimates SAR 150,000–560,000 for fintech MVPs; these are not equivalent bids.
- Electronic payments accounted for 85% of Saudi retail payments in 2025, so test the payment methods relevant to your customers.
- Put failed payments, reconciliation, support, ownership, security and provider access in the proposal, not just the screen list.
What should the first release include?
Choose the smallest journey that can test the business idea without hiding the work behind it. For an invoice-payment product, that might be a customer opening an invoice, choosing an available payment method, seeing the status and contacting support. The operations team also needs to see failed or uncertain payments and match provider records with its own records. A screen that says “paid” is not enough if the team cannot resolve a mismatch.
Write down who receives customer funds, who provides the payment service, which company holds customer data, and which party answers complaints. A founder adding checkout to their own product has a different business model from a company offering payment services or holding funds for others. Working with a licensed provider can reduce what the team needs to build, but the contract and the product’s actual activities still determine the obligations to assess.
Saudi customers may expect local payment options. The Saudi Central Bank (SAMA) reported that electronic payments accounted for 85% of Saudi retail payments in 2025, up from 79% in 2024. That covers retail payments generally, not the preferences of users of a particular app. Agree the required methods and test them with the chosen provider rather than assuming that every integration is available on day one.
Which testing route fits the product?
A technical test environment and a regulatory sandbox solve different problems. Use a simulation to prove a flow before committing to live integrations. Assess the regulatory route in parallel; do not assume every fintech product must enter the same sandbox.
| Route | What it can help you test | What it does not establish |
|---|---|---|
| Prototype or provider test environment | Screens, customer journeys and integration behaviour using simulated or permitted test data | Permission to offer a regulated service or use live customer data |
| SAMA Open Banking Lab | Conformance testing against a simulation of bank open-banking APIs for participating banks and fintechs | Production access or permission to provide a live service |
| SAMA Regulatory Sandbox | An accepted, eligible new model can be tested with live customers within SAMA’s conditions after readiness checks | An automatic full license or permission to scale beyond the approved test |
| Live service | The authorized activity using the necessary production arrangements and controls | That a prototype, provider contract or test alone satisfies every obligation |
SAMA describes the Open Banking Lab as a technical environment that simulates bank APIs. Its Regulatory Sandbox FAQ describes a separate route for new models not covered by existing rules. At the readiness stage, an accepted applicant can test integrations with dummy data; live customers and data follow the required checks and a Letter of Acceptance. The FAQ states that the live testing stage lasts six to twelve months. That is the stated testing period, not a promise of acceptance or the full time from application to a license.
For investment or capital-market activities, also consider the Capital Market Authority’s FinTech Lab. The right authority and permissions depend on the service, the entities involved and the flow of money or data. Have the responsible Saudi regulatory advisers establish that route before the team commits to a live launch date.
What should a Saudi fintech build cost?
Separate the price of a scoped first version from the cost of a live, operated financial service. A useful comparison specifies the same journey, integrations, security work and support period before comparing prices.
| Published example, checked November 11, 2026 | Price and time | Scope and limits |
|---|---|---|
| Hapy’s financial software sprint | US$4,999 one-time; 45 days | A focused first version with an agreed journey and scoped work. Test or simulated flows can be agreed when live access is pending. Bank onboarding, licensing and regulatory approval have separate timelines. |
| Competenza’s Saudi fintech MVP estimate | SAR 150,000–560,000; 12–20 weeks | One development supplier’s broad estimate for a fintech MVP. The page does not disclose a survey method or a complete equivalent scope. It is not a quote for your product. |
These figures use different currencies, and the sources do not specify equivalent work. They are not competing bids for the same specification. The larger range does not prove that a smaller sprint is inadequate, and a short sprint does not establish that a product is ready for regulated live operation. Hapy sells the sprint described above; our commercial interest is to help build the agreed product.
A first-year planning example
Assume a founder chooses a narrowly scoped financial workflow and budgets SAR 150,000 for the build, at the lower end of Competenza’s published estimate. The other amounts below are invented allowances to show how to assemble a budget; they are not supplier quotes or Saudi market rates. The example assumes independent security and regulatory work are outside the build price, which a real proposal must confirm.
| Item | Assumption | SAR |
|---|---|---|
| Defined first build | One agreed customer journey and operations flow | 150,000 |
| Independent security review | One allowance | 12,000 |
| Regulatory advice | One allowance | 10,000 |
| Hosting, monitoring and messages | SAR 1,000 a month for 12 months | 12,000 |
| Support and further engineering | SAR 2,500 a month for 12 months | 30,000 |
| Build plus 12 months of operation | Before the exclusions below | 214,000 |
The arithmetic is SAR 150,000 + 12,000 + 10,000 + 12,000 + 30,000 = SAR 214,000. It excludes VAT, provider and transaction fees, founder and operations salaries, acquisition costs, licensing fees and any required regulatory capital. It also assumes the build is delivered before the 12-month operating period. A supplier has not quoted or approved this scenario, and it is not a promise that the allowances buy a compliant live product.
If you apply for your own payment-service license, keep capital separate from spending. SAMA’s payment regulations require an applicant for a Micro Payment Institution license to show at least SAR 1 million in paid-up equity. The same regulations list a SAR 20,000 license issuance fee for that category after approval. The equity requirement is not an additional fee or an app-development price. Other categories have different requirements, and the relevant classification and other obligations need confirmation.
When is a ready-made payment product enough?
If the immediate need is to collect payments for your own business, first assess whether a provider’s ready-made product does the job. As of November 11, PayTabs lists its Saudi Paymes standalone app at SAR 49 a month and a 1% mada card fee, with prices described as being in a testing phase. This is a standalone product’s published price, not a quote for PayTabs’ separate payment gateway or an offer to power another fintech service.
At 1,000 successful mada payments of SAR 100 each in a month, 1% of SAR 100,000 is SAR 1,000. Adding the listed SAR 49 monthly charge gives SAR 1,049, before any VAT, refunds or other charges. The example assumes that price and volume apply to the account. A custom product can make sense when the customer journey or operational rules cannot be met by a suitable ready-made tool; obtain the provider’s actual eligibility, settlement and pricing terms before deciding.
What should you agree with the development partner?
Ask for a proposal built around an observable customer journey and the people who operate it. A useful partner should explain what happens when a provider response is late, a payment fails, or the customer submits the same request twice. The team should be able to reconcile a transaction with the provider before retrying an uncertain action, and route unresolved cases to a named support owner.
Compare proposals on these points:
- Scope and acceptance: name the customer and staff journeys, Arabic and English screens, devices, permissions, and the checks that show each flow works.
- Provider access: name each payment, identity or banking integration; distinguish simulated, test and production access; identify who obtains approval and what happens if access is delayed.
- Security and data: identify the information collected, where it moves, who can access it, and who owns the security review, audit records, backups and incident response. Agree the applicable data and outsourcing requirements with the responsible advisers and regulated parties.
- Operations and ownership: describe reconciliation, refunds or corrections where relevant, customer support, source-code and account ownership, documentation, and the handover if the relationship ends.
- Price and time: separate the agreed build from specialist reviews, provider charges and ongoing support. Show the dependencies that can move the delivery date.
The MVP partner guide provides a broader proposal comparison. The banking app guide covers the customer and security design questions in more detail when the product is a banking app. Hapy’s engagements show the financial-product sprint alongside its other delivery options.
How long should you allow?
Use the build schedule for the work the delivery team controls, then show provider and regulatory milestones separately. Hapy’s published sprint describes 45 days for an agreed first version; Competenza’s estimate describes 12–20 weeks for its general fintech-MVP category. Neither figure guarantees when a bank will provide production access or a regulator will approve an activity. SAMA’s stated six-to-twelve-month sandbox testing period, where that route applies, is a separate part of the plan.
A practical first milestone is a reviewed prototype and a documented provider-access plan. Proceed to a controlled pilot or live operation only when the relevant permissions, agreements, support and recovery processes are in place. If your question is the wider market rather than this release decision, start with the Saudi startup ecosystem guide.
