← Essays
Emerging marketsAcquiring & AcceptanceAugust 15, 2026 · 7 min read

UAE Open Finance Pay by Bank Needs Checkout Gates

UAE Open Finance is moving Pay by Bank from framework to checkout. Here is the go-live gate I would require before scaling it for merchants.

Article
Reading time
7 min read
Sections
8
Published
August 15, 2026
LinkedInEmail
In this essay8 sections

Pay by Bank in the UAE should not be treated as a cheaper checkout button.

Pinsent Masons' UAE open finance guide describes a framework where financial institutions and third parties can use customer-permissioned data and initiate service requests, including payment initiation. It also notes that the CBUAE Open Finance Regulation was updated by Circular 3 of 2025 and came into force on 10 July 2025.

Clifford Chance's Q&A on the UAE Open Finance Regulation describes the Open Finance licence as covering Data Sharing and Service Initiation. It also highlights explicit consent, data-protection and security obligations as core controls.

That means a Pay by Bank launch is not only a product launch. It is a regulated service-initiation workflow that touches checkout, authentication, consent, bank availability, settlement evidence, refunds, support and reconciliation.

I would not approve merchant-scale rollout until those handoffs are proven.

The Short Answer

For Gulf payments leaders, the Pay by Bank go-live decision should be a checkout-control gate: consent must be explicit, authentication must stay reliable, every failed or pending payment needs an owner, and finance must be able to reconcile the bank movement back to the merchant order.

If those controls are missing, the new rail may reduce one kind of checkout friction while creating another kind of operating ambiguity.

What Has Changed In The UAE

The UAE Open Finance programme is no longer an abstract policy story. The regulatory materials point to service initiation, trust, consent, security, customer journey design and participant obligations, not just read-only account information.

The market evidence is also now practical.

In January 2026, Lean wrote that it had worked with Ziina to take customer-initiated Open Finance payments live in the UAE. Lean framed the work as real users and real money, not a proof of concept.

In April 2026, Abu Dhabi Islamic Bank announced that it had become the first UAE bank licensed as a Third-Party Provider or Open Finance Provider under the UAE Central Bank's AlTareq initiative. ADIB said the licence enabled customer-permissioned account aggregation through its own interface, governed by consent and strong data-protection standards.

In June 2026, Lean and Ziina announced a One-Tap Pay by Bank experience under Open Finance. Wamda's write-up said Ziina users could connect a bank account once and then top up a wallet with one tap, without re-entering credentials or redirecting to a bank portal each time.

Those facts matter because they move the discussion from "when will Open Finance arrive?" to "what should a product leader require before treating this as a dependable checkout rail?"

The Rail Is Not The Product

The rail only initiates money movement. The merchant experience is the product.

A customer may see the payment as successful. The merchant may still see a pending order. The bank may be slow to confirm. The provider may return a status the checkout team did not model. A refund may need to travel through a different operational path from the original payment. Finance may not be able to match the customer approval, bank debit, provider event and merchant order.

That is where Pay by Bank becomes a payments operating problem, not a fintech headline.

I have seen this pattern on other rails while helping scale a payments platform to $1B+ in annual GTV. The first production issue is rarely "does the API work?" It is usually "who owns the state when the payment did not fail cleanly?"

The Four Gates I Would Require

The first gate is not conversion. It is proof that the customer approval is clear, durable and retrievable.

The product should store a consent reference, initiation timestamp, authenticated customer journey state, payment amount, merchant order reference, bank or account reference where permitted, and the provider response. The support team should be able to explain what happened without asking engineering to read logs.

If the customer changes device, loses network, abandons authentication, or revokes consent, the checkout state should remain unambiguous.

Gate 2: Payment State And Merchant Order State

The second gate is state discipline.

Pay by Bank cannot be squeezed into a card mental model. Cards have authorisation, capture, settlement, chargeback and reversal vocabulary. Account-to-account initiation has its own status path. The product should define the states the merchant sees, the states the provider returns, and the states finance needs later.

The minimum state model should separate initiated, customer-authenticated, bank-accepted, bank-rejected, expired, unknown, credited, refunded and reconciled.

The dangerous state is "pending" without age, owner or next action.

Gate 3: Exception Ownership

The third gate is the one many launches skip.

For every ambiguous payment, name the owner before launch. Product owns state design. Operations owns customer and merchant communication. Finance owns settlement evidence. Risk owns abnormal patterns. Engineering owns provider defects and retries. The provider owns its SLA and incident path.

If the customer paid and the merchant did not release the order, the business needs one incident owner, not five teams debating whose dashboard is right.

Gate 4: Reconciliation And Refund Proof

The fourth gate is money certainty.

A Pay by Bank transaction should reconcile across the merchant order, provider event, bank movement and internal ledger. If refunds are supported, the refund path needs the same visibility. If the rail is used for wallet top-ups, the ledger must distinguish the funding event from later wallet spend.

This is the same discipline behind three-way reconciliation. The checkout team should not declare the rail successful while finance is still proving the money manually.

The Metrics That Should Decide Scale

I would not judge the first phase by gross payment volume alone.

The scale gate should use five measures:

  1. Customer-authentication completion rate.
  2. Unknown or pending payment rate after the expected confirmation window.
  3. Merchant order mismatch rate.
  4. Refund completion time by failure type.
  5. Reconciliation break rate and value at risk.

Volume matters only after those numbers are acceptable. Otherwise the product is scaling ambiguity.

The Operator Decision

The commercial case for Pay by Bank is real: lower friction, account-to-account economics and a domestic open finance framework that can mature beyond one-off payments. But the operator decision is not whether the logo says Pay by Bank.

The decision is whether the merchant can trust the rail when something goes wrong.

For a senior product or payments leader, I would ask one board-level question before scale:

Can we prove, for any one transaction, who approved it, what state it is in, who owns the next action, and where the money is?

If the answer is yes, the rail is ready to grow.

If the answer is no, the team has not launched a checkout rail. It has launched a new source of operational uncertainty.

For related operating models, read Lean/Ziina and the UAE Pay by Bank checkout problem, checkout friction as an acceptance operating model, and three-way reconciliation at scale. If your Pay by Bank, acquiring or wallet programme needs a sharper launch gate, start at /hire/.

FAQ

Is Pay by Bank the same as card acquiring?

No. It still sits in checkout and merchant operations, but the state model, customer authentication, refund path and settlement evidence differ from cards. Treating it like card acquiring hides the wrong failures.

What is the most important launch gate?

Exception ownership. If a customer-paid or bank-pending case does not have a named owner, the first production incident will turn into a cross-functional meeting instead of a controlled workflow.

Sources

Tags
UAE Open FinancePay by Bankaccount-to-account paymentscheckoutpayment operations

Closing thought and further reading

UAE Open Finance is moving Pay by Bank from framework to checkout. Here is the go-live gate I would require before scaling it for merchants.

Share article
LinkedInEmail
Keep reading
View all essays
Payments Strategy

Lean and Ziina Turn UAE Pay by Bank Into a Checkout Test

Lean and Ziina's UAE one-tap Pay by Bank launch is more than an Open Finance milestone. It is a checkout, trust, settlement, and reconciliation test for account-to-account payments in the Gulf.

7 min read
Merchant Acquiring

Checkout Friction Is an Acceptance Operating Model

Checkout conversion does not improve because a merchant adds one feature. It improves when onboarding, saved credentials, payment choice, routing, and trust are run as one acceptance system.

7 min read
Settlement & Reconciliation

Three-Way Reconciliation at Scale

Three-way reconciliation is the only model that survives multi-rail growth. Here is how to actually build it.

10 min read
Continue the conversation

Building through similar complexity?

Discuss the operating decisions behind the essay, or explore where my experience can help.

Book introductionEmail Rizwan
Payments Infrastructure Notes

One operator email a week. No filler.

Payment acceptance, settlement and product delivery notes from running $1B+ annual GTV across frontier markets — written for founders and payment leaders.

Weekly at most. Unsubscribe with one reply.