Payments Should Become Infrastructure-But the GCC Is Not One Payments Market

The payment is an event. The financial operating model is the opportunity.

A successful payment does not necessarily tell a business which invoice was settled, which customer account to credit, which supplier is now due, what cash is available for another obligation, or why the bank statement differs from the ERP. Those questions are often answered elsewhere, by another system or a finance team working through exceptions. A CEO should therefore ask a different question from “How do we accept more payment methods?” The better question is: “What work begins before and after money moves, and who owns that work?”

This is where payments can become infrastructure. An embedded financial operating layer connects the commercial action inside an ERP, marketplace, SaaS product or banking app to the associated financial workflows. It can coordinate collections and payouts, verify account information, record obligations in a ledger, support onboarding and compliance processes, and return usable information to finance. It need not own every underlying capability. Its job is to make the journey coherent while the appropriate institutions provide regulated services and access to payment systems.

The proposition is commercial, not merely technical. A platform that helps a customer complete the whole transaction may have a stronger reason to be used every day. An enterprise that can see collections, scheduled payouts and unresolved exceptions together may make better cash decisions. Neither outcome is automatic: the value depends on adoption, data quality, controls and whether the new workflow removes work rather than relocating it.

From gateway to ecosystem: five stages, not five inevitable upgrades

The evolution is easiest to understand as a widening scope of responsibility. A payment gateway helps initiate or accept a transaction. Payment orchestration coordinates choices across methods, providers or routes. Embedded finance places relevant financial actions inside the customer’s existing software journey. Financial operations infrastructure then connects those actions to payables, receivables, reconciliation, ledger records and cash visibility. A monetizable financial ecosystem is possible when a platform can distribute useful services through those workflows under viable commercial and regulatory arrangements.

These are strategic stages, not a claim that every company should become a financial-services business. A software company may create most of its value by removing reconciliation work. A bank may strengthen its corporate proposition by making treasury and payment workflows available where clients already operate. A marketplace may need better allocation and settlement before it considers additional services. The sequence should be driven by a customer problem and defensible economics, not by a desire to add financial features.

Nor does one API turn an enterprise into a bank. An integration layer can simplify access and workflow design, but it does not erase obligations around safeguarding funds, regulated activity, fraud, data, outsourcing or customer treatment. The distinction between presenting a service, operating a workflow and providing a regulated financial product belongs in the first board discussion, not the final legal review.

Why the GCC changes the design brief

The GCC is a credible setting for this model precisely because the opportunity must be localized. Saudi Arabia, the UAE, Qatar, Oman, Bahrain and Kuwait can share an executive ambition-less fragmented money movement and better financial operations-without sharing identical rails, provider relationships or permissions. An operating layer serving multiple markets should therefore be designed for common business logic and distinct country execution.

Consider the official examples. The Saudi Central Bank describes SARIE and its instant-transfer and beneficiary-verification capabilities on its payment-system page. Qatar Central Bank describes Fawran as an instant-payment system launched in 2024 in its retail payment systems overview. These are useful examples of domestic capabilities; they are not evidence that a single integration delivers the same payment experience throughout the GCC.

Permissions also matter. The Central Bank of the UAE’s Open Finance Regulation distinguishes open-finance activity from authorization for other regulated activities or holding customer funds. Oman’s central bank has published a regulatory framework for open banking, whose current status and applicable obligations should be verified before a product decision. In June 2025, the Central Bank of Kuwait announced a draft open-banking regulatory framework; a draft must not be treated as final without a subsequent official check. Bahrain likewise requires its own current regulatory and partner assessment rather than an assumption imported from a neighboring market.

This is more than a compliance footnote. A platform proposition may depend on who contracts with the customer, who onboards a business, which institution holds funds, what payment methods are available, how settlement information is delivered and who resolves a failed payout. Even where an enterprise wants one regional dashboard, the operating model beneath it may need different bank partners and control procedures by country. The BIS/CPMI’s work on harmonising APIs for cross-border payments reinforces a related point: API fragmentation is a real coordination problem, not something the word “API-first” solves by itself.

For a European company entering the GCC, the practical implication is to reuse the proposition where it genuinely travels-such as invoice-to-cash visibility-while testing each local route to delivery. “Regional launch” should describe the commercial ambition, not substitute for six market-level assessments.

What the model looks like in a customer’s day

The best test of infrastructure is whether it disappears into useful work. Each example below is a potential operating design, not a claim about an existing deployment or a guaranteed result.

• ERP or accounting software: An invoice is created; the customer receives an appropriate way to pay; receipt information is matched to the invoice; the ledger and receivables position update. The platform sells a more complete finance workflow, not simply a payment button. The commercial test is whether matching accuracy and exception handling justify the added complexity.
• Marketplace: A customer pays; the platform records what belongs to each seller and what represents its own commission; eligible payouts are instructed through appropriate partners; settlement and commission records reconcile. The board-level questions are who holds funds, who bears dispute and fraud exposure, and what the platform actually earns after servicing costs.
• Large enterprise or distributor: Dealer collections are identified against orders or accounts; supplier payouts follow approvals; finance sees expected receipts, scheduled obligations and exceptions together. Better visibility can support working-capital decisions, but visibility alone does not accelerate collections or change payment terms.
• Property or facilities platform: Tenant collections are allocated to the relevant property and owner; maintenance invoices move through approval; owners and vendors receive payouts through an authorized arrangement. The value is a clearer operational record for all parties, subject to the required treatment of client funds.
• Lending or fintech platform: A customer moves through onboarding and applicable verification; an authorized provider supports disbursement; subsequent collections are matched to the obligation; missed or mismatched payments become exceptions. The workflow must not be confused with permission to lend, hold funds or perform another regulated activity.
• Bank or financial institution: Corporate customers access payments, approvals, account information and treasury views through a banking proposition or an agreed enterprise integration. A bank can use specialist components without surrendering accountability for its customers, controls or regulated obligations.
• Logistics or B2B commerce platform: Delivery confirmation or an accepted purchase order informs an invoice or payout workflow, subject to approvals and contractual terms. This is promising only where the platform’s operational data is reliable enough to support financial decisions.

The economics: revenue opportunity is not payment volume

A software platform that already hosts a commercial transaction may be able to add a financial layer without building every payment capability or becoming a bank. Possible category economics include platform or API access fees, eligible transaction economics, charges for valuable automation services, enterprise contracts, treasury or financial-operations services, and partner or white-label arrangements. These are alternatives and combinations to evaluate-not a claim that every provider can charge for each one.

The important move is from subscription-only thinking to value-per-workflow thinking. If a marketplace resolves seller allocation and payout exceptions, it may create value beyond listing software. If an ERP product connects invoices to collections and reconciliation, its customer may regard it as part of the finance operating model rather than a replaceable record-keeping tool. That can support stickiness, but only when the financial journey works consistently and switching would require rebuilding genuinely useful processes.

There is also a reason to be skeptical. More transaction volume can bring more partner fees, fraud exposure, customer support, reconciliation exceptions and operational liability. Revenue share may be narrow. Enterprise implementations may be expensive. A credible investment case measures contribution by customer segment and workflow: revenue attributable to the service, less direct processing and partner costs, fraud and losses, compliance, implementation, servicing and ongoing operations. It then asks whether the platform improves retention, customer acquisition or core-product value enough to justify the investment. Do not present gross payment volume as margin.

Banks, fintechs and software companies will occupy different positions in that value chain. A bank may provide regulated services and distribution. A fintech may supply focused capabilities. A software company may control the context in which a financial need arises. An enterprise may simply want fewer handoffs. The strongest partnerships make those roles explicit before debating who receives a share of revenue.

A CEO framework: design the money journey before selecting the stack

The starting point is a map of one customer journey, from the commercial event to the final finance record. This prevents a familiar mistake: purchasing an orchestration layer while leaving invoice quality, approval ownership and exception handling untouched. A useful pilot should have a named business owner, a limited set of flows and a baseline for work performed today.

Then separate experience from authority. A platform can offer one interface while banks and licensed partners perform the activities they are authorized to perform. Contracts and controls should specify who verifies customers and suppliers, who instructs payments, who holds funds if applicable, who owns the ledger record, who investigates exceptions and who is accountable when something fails. These decisions shape both the product and the economics.

• Map: Where do orders, invoices, approvals, payments, settlement records and accounting entries originate? Where do people re-enter data?
• Prioritize: Which collections, payouts, AP, AR or reconciliation problem has a measurable customer and finance cost?
• Localize: For each GCC country, confirm applicable permissions, partner roles, rails, data requirements and operating procedures against current official guidance.
• Control: Define delegated authority, segregation of duties, fraud checks, exception queues, audit trails and dispute ownership before automation.
• Measure: Track adoption, matched transactions, unresolved exceptions, time spent on manual work, settlement visibility and contribution after direct costs. Attribute working-capital effects only when the evidence supports them.
• Expand: Add financial services or white-label distribution only after the initial workflow works reliably and the parties understand who serves the end customer.

The next layer: payment infrastructure and AI agents

AI may eventually make this operating layer more responsive. An agentic workflow could identify an invoice, check it against a purchase order and supplier record, assess whether it is eligible for payment, propose a suitable route, request approval, initiate the authorized instruction, match the resulting transaction and update the ERP. It could flag a missing document, changed bank detail or settlement mismatch for a person to review.

That is a design possibility, not a reason to give an autonomous system unrestricted access to money. The model needs defined permissions, transaction limits, identity and account-verification checks, separation between recommendation and execution, human approval where required, an auditable record and a reliable way to stop or reverse a workflow where the underlying systems permit it. Exceptions should be visible rather than hidden behind an apparently seamless interface.

The commercial opportunity for AI is not that it makes a payment faster in isolation. It is that finance staff may spend less time assembling context across systems and more time resolving the decisions that require judgment. If the underlying invoices, ledgers and permissions are poor, an agent can scale mistakes just as efficiently as it scales useful work. Financial infrastructure must be governed before it becomes autonomous.

The strategic question

What if every software company with money moving through its platform could also become a financial-services distribution layer? The question is worth asking because software often knows the commercial context of a payment: what was ordered, who delivered it, which invoice is due and which participant should receive the proceeds. Banks and financial institutions retain an essential role in regulated services, access and trust; software and enterprise platforms can make those services relevant at the point of work.

My view is that the winning proposition will not be “payments everywhere.” It will be a governed financial operating layer that solves an identifiable customer problem, proves its contribution after costs and adapts to each market in which it operates. For GCC leaders, that means resisting two easy answers: treating payments as a checkout feature, and treating the region as one implementation. The first leaves commercial value on the table. The second can put the entire proposition at risk.

Frequently asked questions

What does it mean to treat payments as infrastructure?

It means connecting collections and payouts to the surrounding business work-onboarding, invoices, approvals, reconciliation, ledgers and cash visibility-inside the software or banking journey customers already use. A payment becomes one event in a governed financial workflow rather than the endpoint of a checkout process.

Does embedded finance mean a SaaS company must become a bank?

No. A SaaS company may present and coordinate a financial workflow while appropriately authorized banks or other providers deliver regulated services. The precise roles, permissions and treatment of customer funds must be checked in each market.

Why can’t a business use one payments integration across the GCC?

One interface may be achievable, but the services beneath it can depend on different domestic rails, banking relationships, regulatory permissions and operating procedures. A regional product therefore needs market-specific execution rather than an assumption of interchangeability.

How can a platform make money from an embedded financial layer?

Possible models include platform or API fees, eligible transaction economics, paid workflow services, enterprise contracts and partner arrangements. The relevant test is customer value and contribution after direct costs and risk-not the amount of money passing through the platform.

Where should an enterprise start?

Choose one money journey with costly handoffs, such as invoice-to-cash or approved supplier payouts. Map its records and exceptions, establish the responsible regulated and operational parties, pilot with explicit controls, and measure whether the workflow actually improves.

Can AI agents safely execute payments?

They may help prepare, route and reconcile authorized transactions, but execution should remain subject to defined permissions, approvals, limits, fraud controls and auditability. Automation should not acquire financial authority simply because it can perform a task.