iFynx Studio

Posted on Oct 2 Originally published at ifynx.com

UAE Open Finance Volumes Quadrupled — Can Your Product Be Chosen by AI Agents?

#fintech #product #ai #ux

The new product problem: volume is real — preference is not

In May 2026, the UAE’s open finance rails logged about AED 19.8 million in successful payments. By August, that monthly figure had nearly quadrupled to AED 78.2 million. Nebras, the CBUAE subsidiary operating the central Al Tareq infrastructure, has put cumulative payments around AED 250 million, with thousands of customers already using the system — largely without a national consumer marketing campaign. A public dashboard now shows which banks execute payments, which providers initiate them, and how often customers clear authorisation.

That is not a press-release curve. It is a live market forming under CBUAE Open Finance rules, with Lean Technologies doing most of the early running on Pay by Bank, and banks such as Wio and Mashreq appearing in the payment path. For product and UX teams at licensed financial institutions (LFIs) and third-party providers (TPPs), the uncomfortable question is no longer “will open finance get volume?” It is: when personal AI agents start initiating discovery, consent refresh, and payment routing, will your product be the one they choose — and on what terms?

This field note is for MENA product, design, compliance, and platform engineering teams. It maps what the rails already expose, why agent-readable documentation and machine-usable product metadata matter, and a concrete checklist so you are not optimising only for human checkout while the next buyer is software.

How the rails work (product view, not API tourism)

Al Tareq + Nebras. Al Tareq is the UAE’s standardised Open Finance API and commercial model; Nebras operates the API Hub and national infrastructure under CBUAE supervision. TPPs raise consents, pull permitted data, and initiate payments through chargeable and free endpoints. Consent creation, authentication, discovery, and many reference lookups are free; successful data pulls and payment instructions attract Nebras API Hub fees (headline 2.5 fils per chargeable call) plus LFI payment fees capped by segment and context (for example merchant collections stepping from 38 bps in Year 1 toward 25 bps by Year 5, with caps and exemptions). Data sharing is free up to daily page thresholds, then LFI-priced. Fees apply only to technically successful calls. End users must not be charged extra by LFIs for Open Finance–initiated payments under the model.

Pay by Bank is already a product suite, not a demo. Lean’s UAE Pay by Bank launch (June 2026) packaged Deposits (trading/investment/remittance top-ups with long account-on-file consent), Collections (recurring and credit repayments with pre-transaction balance checks), Checkout (e-commerce with delegated SCA for first-time buyers), and Payment Links (low-code merchant requests). Lean has reported multi-billion AED A2A volumes historically and early Open Finance milestones with partners such as Ziina and Careem. The infrastructure story and the UX story are now the same story: standardised rails + merchant journeys that feel as trustworthy as cards.

Agent-ready documentation is intentional. Nebras leadership has described rebuilding site and docs so infrastructure is intelligible to AI agents — software that can infer which services to use, what permission a customer already granted, and when to ask for more. That ambition sits beside a global race of personal assistants (Instinct-scale transaction volumes, Meta Muse, OpenAI Dots, and others). Regional commentary — including Ziina co-founder Faisal Toukan’s Wamda piece on open finance meeting AI — frames the same convergence: consent-based finance plus agents that shop, pay, and renew on the user’s behalf.

What “being chosen” means for banks and fintechs

Agents will not read your brand film. They will parse machine-readable constraints: licence status, consent scopes, SCA step-up rules, fee economics, settlement certainty, refund/dispute paths, Arabic/English error taxonomies, and whether your product data endpoints tell the truth about eligibility. If Instinct-class assistants monetise by merchants paying for referred volume, cheaper A2A rails can create room for a new commission layer — but only if the assistant can reliably complete the journey. Incomplete consent UX, opaque fee disclosure, or bilingual error voids become selection filters, not support tickets.

“Best” for an agent is rarely a single scalar. It may mean cheapest for the merchant, safest for the user, fastest settlement, Sharia-aligned product flags, or “matches the user’s already-granted consent so we do not re-prompt.” Those objectives conflict. Your product must expose preference-relevant attributes without dumping a PDF into the agent’s context window.

UX and product implications MENA teams under-estimate

1. Consent is inventory for agents. Design consents as versioned, purpose-bound objects with machine labels: scope, duration, renewal_policy, revoke_url, sector, payment_context. Human screens must still explain in MSA Arabic and clear English; agents need structured fields, not only paragraphs.

2. Discovery endpoints are shelf space. If product and account-data APIs return incomplete merchant categories, missing fee caps, or English-only product names, agents will skip you for a competitor with cleaner metadata — even if your consumer app looks prettier.

3. Authorisation completion rate is a ranking signal. Public dashboards already surface how often customers finish authorisation. Treat drop-off after bank redirect as a product defect with owners, not a “bank app problem.” Prep screens, return deep links, and Arabic recovery copy are ranking work.

4. Fee transparency beats fee theatre. Nebras publishes a clear three-stream model. Your merchant and end-user UX should show total cost of a Pay by Bank path versus cards in the moments that matter (checkout, collections setup, deposit top-up) — without burying LFI/TPP economics that agents will eventually model anyway.

5. SCA and delegated auth need dual audiences. First-time Checkout with delegated SCA must stay comprehensible to humans and produce deterministic states agents can poll: pending, authorised, failed with reason code, retryable vs terminal.

6. Kill switches and human override remain mandatory. CBUAE AI guidance and regional risk frameworks still expect explainability and control when automation sits near money movement. An agent-initiated payment path without a user-visible confirm/override story is a compliance and trust failure.

7. Arabic is a reliability surface. Agents that localise poorly will still hit your Arabic bank screens. Mid-range Android, RTL overflow, and MSA microcopy for “insufficient funds,” “consent expired,” and “beneficiary mismatch” decide whether volume becomes support load.

8. Me2Me, P2P, merchant collections are different products. Pricing and UX differ by context in the Al Tareq commercial model. Do not ship one generic “open finance pay” button; match journey chrome to payment context so agents (and auditors) can classify the flow.

Concrete product checklist (ship this quarter)

Publish an agent-oriented capability card for each Open Finance product: scopes, SCA, fee class, settlement rail notes, languages, kill switch owner.
Expose machine-readable consent metadata (JSON) alongside human consent screens; keep them in sync on every change.
Instrument authorisation funnel by bank, language, device class, and payment context; review weekly against public dashboard peers.
Add a bilingual prep + resume pattern for every bank hop (session TTL, Retry, Switch method).
Ship fee comparison modules for merchant Checkout and Collections (card vs Pay by Bank) with sources dated.
Map 8–12 user-facing error reasons EN+AR; never surface raw hub codes to customers or agents without a glossary.
Version product data endpoints so eligibility and limits are queryable without scraping marketing pages.
Define agent vs human confirm policy: which payment contexts always require explicit in-app confirm even if an agent initiated.
Run a tabletop: agent requests payment outside granted scope — does your stack re-consent cleanly or fail closed?
Document commission / referral posture if you plan to pay assistants for routed volume; legal + risk sign-off before experiments.
Align Privacy Policy and consent receipts with PDPL + Open Finance purpose limitation; link both languages from consent UI.
Provide a status page / maintenance signal that agents can poll (not only a human Twitter account).
Separate metrics: human checkout conversion vs agent-initiated completion vs consent renewal success.
Keep a sandbox scenario pack for agent developers (Me2Me, merchant collection, deposit top-up) with deterministic fixtures.
Assign a named owner for Nebras/Al Tareq doc drift — when standards change, your capability cards update within one sprint.

What good looks like in metrics

Early open finance volume is still concentrated. That is an opportunity: quality of authorisation completion, consent renewal without friction, and clean failure taxonomy will matter more than splash campaigns. Aim for: authorisation completion competitive with card 3DS on the same cohort; median time-to-paid under a few seconds after bank approval for on-file consents; Arabic ticket rate on Open Finance errors trending down; zero silent fee surprises in merchant QA; and a documented answer to “what does our product emit that an agent can trust?”

Sources

Closing craft note

Open finance volume in the UAE is no longer hypothetical — May to August 2026 made that obvious. The next competitive layer is quieter: whether agents can understand, prefer, and complete your journeys without inventing a third consent pattern. Banks and fintechs that treat Al Tareq as “an integration project” will watch intermediaries and assistants capture the choosing layer. Teams that ship capability cards, bilingual recovery, fee-honest Checkout, and deterministic agent states will still own the customer relationship when software starts negotiating on the customer’s behalf. That is the product craft iFynx builds with Gulf platforms: be choosable — on purpose.

Operating model: who owns “choosability”

Split ownership explicitly. Product owns journey outcomes and agent confirm policy. Platform engineering owns capability cards, sandbox fixtures, and status signals. Compliance/risk owns scope taxonomy, retention, and override rules. Design owns bilingual prep/resume/error components in the design system so agents and humans do not diverge. Meet biweekly for eight weeks after any Pay by Bank or consent schema change. If marketing ships a new “AI-ready” claim, require the capability card link in the same release — slogans without metadata are how agents learn to ignore you.

Scenario lab: three journeys to prototype this month

A. Careem-style wallet deposit. User grants long-lived account-on-file consent; later an assistant tops up before a trip. Prototype: consent receipt, balance check, confirm threshold (e.g. above AED X always show user confirm), and Arabic failure if the linked account changes.

B. Merchant Checkout first-time buyer. Delegated SCA once; subsequent purchases reuse consent where allowed. Prototype: clear “pay from bank” value vs cards, progress during bank hop, and a post-payment receipt agents can cite.

C. Collections / repayment. Pre-transaction balance check reduces failed debits. Prototype: scheduled consent renewal reminders EN+AR, and a merchant dashboard that explains Open Finance declines without blaming the customer generically.

Run each scenario with a human tester and a scripted agent client. Gaps between the two are your backlog.

Design system tokens for agentic open finance

Encode reusable blocks: ConsentPurposeCard, BankHopPrep, ResumeBanner, FeeCompareRow, ScaProgress, AgentConfirmGate, ErrorRecoveryMSA. Publish props for payment context (Me2Me, P2P, merchant collections, bulk). If coding agents generate screens, constrain them to these blocks — freestyle “verify later” patterns fracture trust and audits.

Risk note without fear theatre

Agentic routing does not retire CDD, sanctions screening, SCA, or complaint handling. It compresses the time between preference and payment. Your job is to make that compression legible: who initiated, under which consent version, with which fee class, and how the user can undo or escalate. Legibility is how you stay choosable when regulators and customers ask the same question agents already ask — can I trust this path?

Originally published on iFynx.

DEV Community