In short: a Saudi bank cannot launch a sharia compliant BNPL product by adding a Sharia wrapper to a conventional instalment loan. The Murabaha contract has to be a native contract type in the core, because the ledger, not the application layer, is what the Sharia board audits and what SAMA reporting draws from. A wrapper records a deferred payment obligation and calls it a sale. A ledger-native product engine records the commodity purchase, the transfer of title, the disclosed cost and the disclosed profit as separate events.
Saudi banks are moving into BNPL territory that fintechs built, claimed and defended for three years. The commercial logic is sound. Banks enter with distribution advantages that Tamara, Tabby and Postpay cannot replicate: branch networks, existing customer relationships, salary data, and the trust that decades of brand presence create. But that logic collapses without the right infrastructure underneath it. A bank cannot win this market by draping a Sharia wrapper over a conventional instalment product.
This matters for anyone evaluating core infrastructure for Sharia-compliant BNPL deployment. The distinction between a ledger-native Murabaha contract and a retrofitted compliance layer is not theoretical. It determines whether a bank can price, book, report and audit a Murabaha sale in real time, or whether it routes every transaction through a compliance workaround that creates operational risk and delays settlement.
The regulatory moment in Saudi Arabia
The conditions for bank-led BNPL are already in place. The Saudi Central Bank (SAMA) reported that electronic payments accounted for 79% of all retail transactions in 2024, up from 70% in 2023. With 12.6 billion non-cash retail transactions over the year against 10.8 billion the year before. Consumer readiness is equally established: Visa’s Consumer Payment Attitudes Study 2024 found that 75% of Saudi consumers were familiar with BNPL and 33% had already transacted through it.
What has changed is the regulatory treatment. SAMA’s Rules for Regulating Buy-Now-Pay-Later Companies treat BNPL not as a checkout convenience but as regulated consumer credit. With licensing, pricing transparency, minimum capital requirements and consumer protection standards. The rules also set hard, enforceable numerical limits: under SAMA Circular No. 472038475, dated 24 December 2025. Total outstanding BNPL financing per individual consumer is capped at SAR 10,000, and the number of instalments granted is capped as well.
Those are not disclosure obligations. They are ledger obligations. A bank has to know, at the point of approval and in real time. What a customer’s total outstanding position is across every BNPL contract it holds. It has to be able to evidence that position to the regulator from its own records. That is a question about the data model, not about the application form.
What Sahlha and DAFA’AT actually tell us
Two products from incumbent Saudi banks make the infrastructure argument concrete, and both do it through the profit rate.
Al Rajhi Bank’s Sahlha programme lets customers pay in monthly instalments for amounts provided by approved merchants. With no profit rate and no administrative fees, over tenures of up to 60 months. The bank’s own product example shows an annual percentage rate of 0%.
Riyad Bank’s DAFA’AT programmed follows the same logic. Offering products and services through personal finance with zero fees and no profit margin. Riyad Bank also lists Tawarruq as a separate product. In the same personal finance range, alongside education finance at zero fee and zero profit.
Read those product sheets as an architecture brief and two requirements fall out immediately.
First, a zero profit rate is the hardest case for a conventional ledger, not the easiest. A core that stores Islamic profit as an interest rate equivalent will record a 0% Sharia instalment sale and a 0% conventional interest-free loan identically. Every downstream system, the general ledger, the regulatory report, the Sharia audit extract. Then has to be told which one it is by something outside the ledger. That is the reconciliation layer, and it is where the risk lives.
Second, these banks are not running one Islamic contract type. Tawarruq sits next to merchant instalment programmes sits next to education finance in a single retail range. Each has a different accounting treatment. A core that handles one structure natively and the rest by exception. Does not scale across a product range like that.
Both of these validate Islamic banking capability as the competitive moat in Saudi BNPL. A bank running these products on a conventional core with a Sharia compliance layer bolted on at the application tier. It has to reconcile that layer back to the ledger on every transaction. The reconciliation creates latency, manual risk, and an audit trail that struggles under SAMA’s requirements.
The infrastructure problem banks aren’t discussing publicly
The architecture failure that most Islamic BNPL deployments run into is the gap between where the Sharia compliance sits and where the transaction is recorded.
A wrapper approach adds Islamic structuring at the front end. In the customer application, the contract documentation and the SAMA disclosure screens. While the underlying ledger records a deferred payment obligation using the same data model as a conventional instalment loan. The profit margin is stored as an interest rate equivalent. The asset sale is treated as a loan disbursement. The Murabaha commodity purchase, where the bank actually buys the asset before selling it to the customer, has no representation in the ledger at all, because the ledger was never built to hold it.
This creates three problems that compound over time.
Regulatory reporting and limit enforcement. SAMA requires accurate, timely disclosure of the nature of financing contracts, and it enforces per-consumer exposure caps. A bank running Murabaha transactions through a conventional ledger cannot generate a compliant report from the ledger itself. The reporting layer has to transform the data, which introduces mismatch risk between what the ledger holds and what is disclosed.
Sharia audit trails. The Sharia board at a Saudi bank reviews actual transaction structures, not disclosures. If the ledger records a deferred payment and the Sharia disclosure describes a Murabaha sale, the audit finds a discrepancy. Ledger-level compliance is a practical prerequisite for Sharia board sign-off, not a documentation preference.
Cross-product Islamic structures. Extended Buy Now Pay Later, or XNPL, is instalment credit that runs across multiple product categories, time horizons and financing structures under a single framework. A customer using Islamic XNPL across electronics, healthcare and travel financing needs consistent contract handling on each purchase, regardless of merchant category or financing horizon. A Murabaha sale for a laptop, an Ijara lease for medical equipment and a Wakala agency arrangement for travel bookings each require a different accounting treatment. A conventional core with a wrapper cannot handle that variation without a separate workaround for each structure.
Why the Murabaha contract has to live in the ledger
The core requirement is straightforward: the ledger must treat a Murabaha sale as a sale, not as a loan with a different label.
That means the ledger records two distinct events, the bank’s purchase of the commodity or asset, and the bank’s sale of that asset to the customer at cost plus the agreed profit margin. The profit margin sits in a separate field from the cost basis, so that a zero margin remains a Murabaha profit of zero rather than an interest rate of zero. Asset ownership transfers between parties at defined points. The customer’s obligation is to pay a sale price in deferred instalments, not to repay a principal with interest.
When these structures live natively in the core, four things become possible that a wrapper cannot provide:
- The bank generates a Sharia-compliant BNPL contract directly from the ledger, with the disclosed cost, the disclosed profit and the transfer of title all documented in the transaction record.
- Regulatory reporting and exposure limits are calculated from ledger fields rather than from a reconciliation layer.
- The Sharia board audits the ledger and finds that the transaction structure matches the documentation.
- New Islamic product variants, an Ijara lease for higher-value purchases or a Wakala arrangement for service financing, are configured in the same product engine and share the Islamic accounting treatment rather than requiring separate integration work.
This is the architectural position Fimple calls Islamic XNPL. Fimple is an AI-native, API-first, composable financial platform, and its product engine holds Murabaha, Ijara and Wakala as first-class contract types rather than documentation labels applied to conventional data structures. The Sharia audit trail is generated from transaction events. A bank launching Sharia-compliant BNPL on Fimple configures the product once and deploys it across merchant categories without rebuilding the compliance layer for each use case.
What bank product teams need to audit before launching
Any Saudi bank evaluating BNPL infrastructure for Islamic banking deployment needs answers to five questions before the product team builds the acquisition journey.
One: does the ledger record a Murabaha sale or a deferred payment obligation? Ask the vendor to show the actual transaction data model, not the reporting output. The Murabaha commodity purchase and the sale to the customer should appear as distinct ledger events.
Two: where does the profit margin live in the data structure? It belongs in a separate field from the cost basis. If the vendor shows an APR field carrying the Islamic profit, the ledger is treating the contract as a rate structure on a conventional loan. That is a wrapper, and it becomes visible the moment the bank launches a zero profit rate product.
Three: can the system produce SAMA reporting and enforce per-consumer exposure limits directly from the ledger? Both should draw from the same fields that produce the financial accounting, not from a separate layer maintained manually by the compliance team.
Four: how does the core handle Ijara, Wakala and Tawarruq alongside Murabaha? A bank offering Islamic XNPL across product categories needs multiple contract types in a single product engine. If the vendor treats each structure as a separate integration project, the operational cost of expanding the range compounds with every new merchant category.
Five: does the Sharia audit trail record asset ownership transfers? The board needs to verify that the bank owned the commodity before selling it to the customer. If the ledger has no asset custody event, the Murabaha structure is incomplete regardless of what the documentation says.
The competitive position for Saudi banks in 2026
Saudi banks entering BNPL face a market where fintech incumbents hold consumer familiarity, merchant integrations and three years of credit data. The bank advantage comes from trust, distribution, and the ability to extend credit to customers whose financial behaviour the bank already understands from salary, savings and transaction history.
That advantage compounds when the BNPL product is structurally Sharia-compliant rather than compliance-documented. A customer choosing between a fintech BNPL product and a bank BNPL product carries an expectation that the bank’s Islamic product genuinely follows Murabaha principles, not because SAMA requires the disclosure but because the bank’s Sharia board has verified the ledger. In a market where three quarters of consumers already know what BNPL is and a third have used it, that expectation is a conversion driver rather than a compliance cost.
The infrastructure decision, ledger-native Murabaha or retrofit wrapper. Determines whether bank-led BNPL growth is sustainable or constrained by operational and compliance risk that accumulates with every transaction.
The category argument for Islamic XNPL is not that Sharia compliance differentiates a BNPL product at the marketing level. It differentiates at the infrastructure level, and that difference compounds as SAMA reporting requirements tighten. As product ranges expand from Murabaha into Ijara, Wakala and Tawarruq structures, and as the audit scrutiny that comes with scale requires a ledger that stands up to direct examination.
Saudi banks that build on a wrapper today will rebuild on a native ledger tomorrow. The cost of that rebuild grows with every transaction they process in the interim.
Sources
- Saudi Central Bank (SAMA), retail payments data for 2024, reported April 2025: electronic payments at 79% of retail transactions and 12.6 billion non-cash retail transactions.
- Saudi Central Bank (SAMA), Rules for Regulating Buy-Now-Pay-Later (BNPL) Companies. SAMA Rulebook, including Circular No. 472038475 dated 24 December 2025 on the SAR 10,000 per-consumer outstanding financing cap.
- Visa, Consumer Payment Attitudes Study, 2024.
- Al Rajhi Bank, Sahlha Programme product page, 2026.
- Riyad Bank, Personal Finance product range including the DAFA’AT Programme and Tawarruq finance, 2026.
