Launching a Fintech Product in Saudi Arabia: SAMA Compliance, Digital Wallets and Banking Infrastructure

Electronic payments accounted for 85% of Saudi Arabia’s retail transactions in 2025, representing 14.6 billion electronic transactions, according to the Saudi Central Bank. This progress reflects changing customer behaviour and a sustained policy drive under Vision 2030.

For a founder or licensed institution, launching a fintech product in Saudi Arabia involves much more than building a mobile application. A viable product requires an appropriate regulatory model, reliable ledger and transaction infrastructure, integrations with local banks and payment services, and operational controls that can support real financial activity.

These requirements apply to digital wallets, payment and merchant services, remittance products, card programmes, digital banking, BNPL and embedded finance. The exact obligations differ, but the central principle remains the same. Once a product holds, moves or lends customer money, its requirements are determined by that financial function, not by the application interface.

Start with the Regulatory Model

The Saudi Central Bank, commonly known as SAMA, supervises banks, licensed finance companies and payment service providers. Its regulatory framework includes a sandbox for testing innovative products, rules for payment service providers, dedicated requirements for activities such as BNPL, and licensing for open banking services.

SAMA issued dedicated BNPL rules in December 2023. These rules cover licensing, consumer protection, information security and financial crime controls.

Other authorities may also be relevant. Capital market, securities and investment-related fintech products may fall under the Capital Market Authority rather than SAMA. A company should therefore map its business model and money flows before determining which regulator, licence or licensed partner applies.

The key questions include:

• Who holds customer funds?
• Who initiates and processes transactions?
• Who settles payments?
• Does the product extend credit?
• Which entity enters into the relationship with the customer?
• Which entity is authorised to perform each financial activity?

Some fintech companies may operate through an already licensed bank, payment institution or finance company. In this model, the fintech provides the technology and customer experience while the authorised partner performs the regulated activity.

The selected model will influence the product architecture. KYC, AML, transaction monitoring, customer protection, cybersecurity, data governance and regulatory reporting cannot simply be added after launch. For example, a ledger that cannot produce a complete audit trail may require substantial rework before it can support reconciliation or regulatory reporting.

No single licensing route applies to every product. Companies should confirm the requirements directly with SAMA, the CMA where relevant, and qualified Saudi legal or compliance advisers. Purchasing fintech software does not provide a financial licence, SAMA approval or automatic regulatory compliance.

The Technology Behind a Saudi Fintech Product

The customer-facing application is only one layer of a fintech product. Underneath it, a financial backend must maintain accurate balances, record every movement of money and give operations teams enough control to run the business.

The main components typically include:

• customer and business account management;
• a double-entry financial ledger;
• available, pending and held balances;
• complete transaction history;
• configurable fees, limits and commissions;
• wallets, payments, transfers and payouts;
• reconciliation and settlement;
• role-based access control;
• back-office functionality;
• regulatory and operational reporting;
• APIs for customer applications and external integrations.

The platform may also need to connect with banks, payment gateways, KYC and AML providers, card issuers, identity services, accounting systems and fraud monitoring tools.

Depending on the product, a Saudi implementation may require project-specific connections to local banks and national payment infrastructure such as mada, SADAD or sarie. These connections should be identified during solution design rather than assumed to be available automatically.

The ledger is especially important because it provides the financial source of truth. It should explain every balance change, fee, settlement, reversal and payout. Errors in this layer become difficult and expensive to correct once customers are actively transacting.

Build from Scratch, Use SaaS or Start with a Software Foundation?

Companies generally have three options for creating their fintech technology.

Building from scratch provides maximum design freedom and ownership. However, it also requires significant engineering resources and creates full responsibility for ledger correctness, security, scalability, testing and ongoing maintenance.

A SaaS or managed white-label platform can reduce initial development and support a faster launch. The trade-off may be less control over the source code, infrastructure, data architecture, integrations and long-term product roadmap.

A configurable software foundation sits between these approaches. The company starts with working ledger, account and transaction functionality rather than a blank codebase. It can then configure the system, complete local integrations and develop the required customer experience.

This approach can reduce the amount of core backend development without removing the company’s implementation, operational or compliance responsibilities.

SDK.finance as a Software Foundation

SDK.finance is an API-first fintech infrastructure that licensed institutions and fintech companies can use as the software foundation for digital wallets, payment products, digital banking services, remittance and embedded finance.

The platform provides a ready-to-customise financial backend that includes:

• double-entry ledger functionality;
• customer and business accounts;
• multi-currency accounts and wallets;
• fiat and crypto asset balance management;
• crypto-to-fiat and fiat-to-crypto transaction workflows through third-party integrations;
• wallet and transaction management;
• payments, transfers and payouts;
• configurable fees, limits and commissions;
• administrative back-office functionality.

SDK.finance provides the ledger and account infrastructure for recording fiat and crypto-related transactions. Connections to blockchains, crypto exchanges, liquidity providers, custody services and compliance tools require separate third-party integrations.

This functionality is exposed through 650+ APIs, enabling the financial core to connect with customer applications and project-specific banking, payment, KYC, AML, card-issuing and identity services.

For Saudi fintech teams, this changes the starting point of the project. Engineering resources can focus on the business model, customer experience and local integrations instead of first developing ledger logic, balance management, transaction workflows and operational tools from scratch.

SDK.finance is available with a source-code licence, giving the licensee visibility and control over the code it runs. Depending on the selected delivery model, the software can be deployed on the customer’s infrastructure or in a private cloud environment.

This can be valuable for organisations that need greater control over data, infrastructure, integrations and their long-term product roadmap.

SDK.finance provides the technology foundation. It is not a Saudi financial licence, bank or regulatory service. The customer and its authorised partners remain responsible for regulatory approval, local integrations and operational readiness.

Saudi Arabia Experience: The Geidea Case

Geidea is a Saudi payment solution provider offering POS terminals, payment acceptance and business management tools to merchants and financial institutions.

Its legacy transaction accounting system created several challenges. Reconciliation involved substantial manual work, merchants had limited visibility into settlement, and the accounting model depended heavily on information from a single acquiring bank. The existing architecture also limited the company’s ability to introduce new products and support growth.

Geidea modernised its core transaction accounting using SDK.finance’s on-premise ledger layer software as the foundation.

The implementation connected the ledger with Geidea’s POS transaction network and introduced a role-based accounting model. Separate back-office interfaces gave employees and merchants access to balances, transaction histories, settlement information and payouts.

The project also introduced:

• automated reconciliation;
• configurable fees and commissions;
• support for multiple banking relationships;
• improved transaction and settlement visibility;
• merchant payout functionality;
• integration with Mastercard Payment Gateway Services for online payments.

The result was more efficient reconciliation, clearer visibility across the payment lifecycle and greater flexibility to work with multiple banks. The infrastructure supports a payment business operating at the scale of millions of transactions per day and continues to serve as an accounting foundation for Geidea’s regional operations.

The project demonstrates that SDK.finance has practical implementation experience in Saudi Arabia and can support the infrastructure requirements of a high-volume payment provider.

SDK.finance supplied the ledger and accounting layer. It did not act as Geidea’s acquirer, payment gateway or regulatory sponsor. The results of another implementation would depend on the product, regulatory model, integrations and market context.

A Practical Launch Sequence

A Saudi fintech company can structure its launch around six steps:

1. Define the product, target users and exact flow of money.
2. Identify the regulated activities and required licences or partners.
3. Design the ledger, accounts, balances, fees and settlement model.
4. Select the build, SaaS or software foundation approach.
5. Identify local banking, payment, identity and compliance integrations.
6. Test reconciliation, settlement, security and exception scenarios before launch.

The ledger and money-flow model should be designed before extensive frontend development begins. Changing an account structure on paper is much easier than rebuilding a product around it after launch.

Conclusion

A successful fintech launch in Saudi Arabia requires three elements to work together: an appropriate regulatory model, a clear product and operational design, and reliable financial infrastructure.

SDK.finance can provide the third element. Its API-first software foundation gives companies an existing ledger, account structure, wallet functionality, transaction workflows and back office instead of a blank codebase.

For Saudi teams that want to reduce core backend development while retaining control over deployment, integrations and product direction, this model offers a practical alternative to both building from scratch and relying on a fully managed SaaS platform.

The key test is whether the selected technology can represent the company’s exact money flows, connect with the services required for the Saudi market and support the product as transaction volume and regulatory expectations increase.