Embedded Finance and Open Banking in the Gulf: What Is Actually Buildable
Open banking rails, payment infrastructure and licensing in Saudi Arabia and the GCC — what a non-financial company can realistically build, what requires a licence, and where the projects go wrong.
Embedded finance is the idea that financial services stop being a destination and become a feature of whatever you were already doing. You do not go to a bank to finance a purchase; the financing appears at checkout. You do not log into a banking portal to reconcile; your accounting software already knows.
In the Gulf this has moved quickly from concept to infrastructure. Saudi Arabia in particular now has open banking rails, instant payment infrastructure and a regulatory sandbox — which means the interesting question for most companies is no longer whether it is possible, but what they can build without becoming a regulated financial institution.
The rails that exist
Open banking. The Saudi Central Bank has established an open banking framework, with account information services — the ability, with the customer's explicit consent, to read their account data across banks — implemented ahead of payment initiation. This is the foundation for a large class of products: cash-flow-based lending decisions, automatic reconciliation, personal financial management, and account verification that does not depend on a customer uploading a statement.
Instant payments. Account-to-account transfers that settle in seconds rather than in banking days change what products are viable. Payouts, refunds, disbursements and settlement flows that previously required batch processing and a working-capital buffer become real-time operations.
Card and domestic payment infrastructure. A mature domestic card scheme with very high penetration, alongside international schemes and digital wallets. For most consumer products this is solved infrastructure — the question is which processor and which commercial terms, not whether it can be done.
The regulatory sandbox. A supervised environment for testing novel propositions with real customers under defined limits. Genuinely useful for models that do not fit an existing licensing category cleanly, and worth engaging with early rather than after you have built.
The line between a feature and a licence
This is the question that determines your entire project plan, and getting it wrong late is catastrophic. The general principle across GCC regulators: holding customer funds, extending credit, or providing payment services as a business are regulated activities. Presenting, routing to, or being paid for referring to a licensed provider generally is not.
In practice, most non-financial companies build in one of three ways:
Partner-led. A licensed institution provides the financial product; you provide distribution and the customer experience. You are not regulated as a financial institution, though you will carry obligations flowing from the partnership and from consumer protection and data rules. Fastest path, lowest regulatory burden, and the correct default unless you have a specific reason otherwise. The trade-off is economics — the licence holder takes the margin — and dependence on their product roadmap.
Licence-light. Obtaining a specific, narrow authorisation for the activity you actually perform, rather than a full banking licence. Payment service provider and e-money categories exist for this purpose in the region. Substantially more capital, compliance function and time than partnering, but you own the economics and the product.
Fully licensed. A digital bank or full financial institution. A different kind of company, with capital requirements and a compliance organisation to match. Very few embedded finance ambitions actually require this.
The expensive mistake is building the product first and asking the licensing question second. Regulatory perimeter should be the first design constraint, ahead of technology choices — because it determines the architecture, the partner set, the funding requirement and the timeline simultaneously.
What is genuinely buildable now
Buy now, pay later at checkout. A well-established model in the Kingdom, and one where the regulatory position has been clarified — meaning the operators are supervised. For a merchant, integration is straightforward. For anyone wanting to be the provider rather than the merchant, this is a regulated activity.
Cash-flow-based SME lending. Open banking makes it possible to underwrite a small business on its actual transaction flow rather than on financial statements that are a year old. This is one of the more genuinely transformative applications in the region, because the traditional credit file for a small Gulf business is often thin.
Embedded reconciliation and accounting. Software that connects to a business's bank accounts with consent, matches transactions to invoices, and eliminates a manual monthly task. Unglamorous, immediately valuable, and generally outside the licensing perimeter.
Payouts and disbursement. Marketplaces paying sellers, platforms paying contractors, insurers paying claims. Instant payment rails make this a materially better experience than it was, and the flows are usually structured through a licensed partner.
Verification and onboarding. Confirming account ownership and identity without documents, using open banking and national digital identity infrastructure. This removes one of the largest sources of drop-off in any financial onboarding flow.
The parts that are harder than they look
Consent is a product surface, not a checkbox. Open banking access is granted by the customer, is scoped, and expires. Your product must handle re-consent gracefully, explain clearly what is being accessed and why, and continue to function sensibly when a customer revokes. Teams that treat consent as an integration detail build products that silently stop working for a growing share of their users.
Reconciliation is the real engineering problem. Not moving money — knowing precisely where every unit of it is at every moment. Ledger design, idempotency, handling of partial failures, and the reconciliation process between your ledger and your partner's are where financial engineering actually lives. Underestimating this is the most common cause of embedded finance projects becoming operationally painful after launch.
Failure modes are asymmetric. A bug in a content feature is an annoyance. A bug in a payment flow is a customer's money. This changes the engineering standard required: idempotency keys on every mutating operation, immutable transaction logs, reconciliation that runs continuously rather than monthly, and alerting that treats a discrepancy as an incident.
Data obligations compound. Financial data is personal data, and often sensitive in practice. Personal data protection requirements apply on top of financial regulation, and the two have different retention logics — one pushing you to delete, the other to retain. Resolve that tension deliberately during design.
A sensible way in
- Establish the regulatory perimeter first. Describe precisely what you intend to do and get a view on whether it is regulated, before you design anything.
- Start with information, not money movement. Account information use cases deliver value with materially lower regulatory and operational risk than payment initiation, and they teach your team the domain.
- Choose partners on operational quality, not just commercials. Sandbox quality, API documentation, error semantics, support responsiveness and settlement reliability will matter far more over three years than a small rate difference.
- Build the ledger properly from day one. Retrofitting a correct double-entry ledger onto a system that started with a balance column is a rewrite.
- Instrument reconciliation before launch. You want to know about a discrepancy within minutes, not at month end.
The opportunity
The Gulf's advantage in embedded finance is that the infrastructure was built recently. There is less legacy to work around, mobile penetration is high, national digital identity is real, and regulators have been deliberate about creating room for new entrants. The constraint is not technology or infrastructure — it is the discipline to treat financial engineering with the seriousness it requires. Companies that bring that discipline are building things here that would take years longer to get live in older markets.
