Open Banking Phase 2 APIs in the UAE provide fintech developers with secure, regulated access to account data and payment initiation. The Central Bank of the UAE has launched this framework to standardise integration, enforce strong security, and create opportunities for innovative financial products in both B2C and B2B markets.
What Goes Live in Phase 2 (AIS + PIS)
Scope at a Glance: data access, payment initiation, central trust model
Phase 2 brings together Account Information Services (AIS) and Payment Initiation Services (PIS) under one regulated model. Through the Central Bank’s API Hub and Trust Framework, licensed fintechs can access account balances, transactions, and customer data while also initiating secure bank-to-bank payments. This eliminates the need for screen scraping and creates a single nationwide integration standard.
Who Must Comply: banks, licensed third-party providers, partner pathways
All retail and corporate banks in the UAE are required to connect to the Open Finance Platform. Third-party providers (TPPs) such as fintechs must obtain a licence from the Central Bank of the UAE or integrate through a licensed partner. Even established payment service providers are subject to new onboarding and security checks before they can use the APIs.
Key Dates and Readiness Milestones
The Central Bank issued the Open Finance Regulation in 2024, mandating all banks and insurers to connect. In April 2025, Pay10 became the first fintech licensed under the framework, initiating live transactions with a UAE bank.
This milestone confirmed that Phase 2 APIs were production-ready, with further rollouts scheduled across the year as more banks and fintechs complete certification.
Technical Architecture You’ll Build On
Consent-Driven User Journey
At the centre of UAE open banking is customer consent. A fintech app cannot access any data or initiate any payment until the customer explicitly authorises it through their bank. This is managed via AlTareq, the branded national consent interface.
When a user links their bank account to a fintech app, they are redirected to the AlTareq page, log in securely, and approve or deny the specific request. This standardised experience builds trust and prevents phishing, since users always recognise the official interface.
API Surface
The API set covers multiple use cases:
- Accounts: account details, balances, transaction history.
- Payments: single, scheduled, and recurring payments, including variable recurring payments (VRP).
- Metadata: bank service information, consent status, and error codes.
The scope will expand beyond banking into insurance and lending as the broader Open Finance vision develops.
Environments
Developers first integrate with a sandbox environment containing mock data. After building, they must pass functional and security certification. Only then will they be granted access to the production environment, where real customer data and payments flow through the central platform. This phased approach reduces risks and ensures compliance before launch.
Compliance and Licensing Workflow
Choose Your Operating Model
Startups can either:
- Apply for a direct licence from the Central Bank, which allows independent access to the API Hub.
- Partner with a licensed institution, leveraging their approval to integrate faster.
Direct licensing offers full control but requires significant compliance investment. Partnerships provide quicker time-to-market, though with shared responsibilities.
Application Dossier
Applicants must submit a detailed package covering governance, cybersecurity policies, capital adequacy, AML/CFT procedures, and outsourcing arrangements. The Central Bank reviews not only the technical readiness but also the financial sustainability of the applicant to ensure resilience.
Onboarding to the Trust Framework
Once approved, entities are registered in the Participant Directory and issued digital certificates. They configure their OAuth 2.0 credentials and mutual TLS certificates to connect to the API Hub. This process ensures that only verified and trusted parties can call the APIs.
Ongoing Obligations
Compliance does not stop at launch. Licensed fintechs must file periodic reports, maintain cybersecurity certifications, and demonstrate robust business continuity planning. Failure to meet these obligations can result in suspension from the Trust Framework.
Security Standards You Must Implement
OAuth 2.0 / OIDC with FAPI 2.0
The UAE requires adherence to the Financial-grade API (FAPI) 2.0 profile, the most advanced global security standard for financial applications. This includes:
- Pushed Authorisation Requests (PAR), ensuring sensitive data never travels through the browser.
- JWT-secured authorisation requests (JAR), preventing tampering.
- Private key authentication (private_key_jwt) requires fintechs to sign requests with registered keys.
- Fine-grained scopes, so customers authorise exactly which data or actions are permitted.
Mutual TLS
Every API call uses mutual TLS (mTLS). Not only does the fintech verify the bank’s server certificate, but the fintech must also present its own certificate issued by the Trust Framework—this double verification blocks unauthorised actors at the network layer. Certificates must be rotated regularly, and the Central Bank immediately revokes compromised keys.
Strong Customer Authentication
Banks are required to enforce multi-factor authentication for every sensitive action, from data sharing to payments. Customers confirm actions through one-time passwords, biometric checks, or device-based verification. Fintech apps must be able to handle these flows seamlessly and reflect the status of the authentication back to the customer.
Consent Lifecycle and Data Minimisation
Consent is explicit, informed, and time-bound. A fintech can only access the specific data agreed by the customer, for the stated purpose and duration. If a customer revokes consent, access must be terminated immediately, and sensitive data must be deleted or anonymised in line with regulatory timelines.
Auditability and Forensics
Every transaction is tagged with a unique interaction ID. Fintechs must maintain immutable logs that can be shared with regulators during audits. Logs must cover requests, responses, error codes, and customer actions. This ensures complete traceability for dispute resolution.
Prohibited Practices
The Central Bank bans screen scraping and credential sharing. Customers must never provide usernames or passwords to third parties. Only certified APIs may be used, protecting both consumers and institutions from fraud.
Developer Checklist (Build → Test → Ship)
Prerequisites
Before starting development, ensure your tech stack supports OAuth 2.0, PKCE, JWT signing and verification, and certificate-based authentication. Libraries that are not FAPI-compliant will not pass certification.
Resilience Patterns
Design your app for resilience. Use idempotency keys to prevent duplicate transactions, retry logic with exponential backoff for transient failures, and circuit breakers to protect systems during outages.
Error and Dispute Handling
Integrate flows for reversals and reconciliations. For example, if a payment initiation fails after debiting an account, your app must automatically trigger a dispute resolution process through the framework.
Certification Readiness
All apps must undergo functional, security, and CX certification. This includes penetration testing, compliance with error handling standards, and user experience reviews to ensure customers understand consent and authorisation.
Observability
Implement full observability using metrics, tracing, and structured logs. Use the interaction ID provided by the API Hub to correlate requests across systems for monitoring and debugging.
Privacy-by-Design
Run data protection impact assessments (DPIAs). Map how customer data flows through your system, redact sensitive information from logs, and implement strict deletion timelines to ensure data security.
Launch Readiness
Prepare a customer support function trained to handle open banking issues. Establish SLAs for incident response, and run crisis simulations before going live.
Product and UX Requirements
Consent UX
Consent screens must clearly describe the data or action requested. For example: “Share your current account balance with App X for 90 days.” Plain language is mandatory, avoiding technical jargon.
Edge Cases
Your app must handle expired consents, partially approved consents, and unresponsive providers. In these cases, customers should receive clear notifications and guidance.
Accessibility and Localisation
The Central Bank requires bilingual support in Arabic and English. Apps must also support right-to-left layouts and accessibility features such as screen readers to ensure inclusivity.
Go-to-Market Use Cases (B2C and B2B)
B2C Growth Plays
Personal finance management apps can aggregate accounts across multiple banks, providing users with a comprehensive 360-degree view of their finances. Pay-by-bank checkout options allow consumers to pay merchants directly from their accounts without card fees. Bill payment and recurring subscription models benefit from variable recurring payments.
SME and Enterprise
SMEs can automate reconciliation by feeding bank data directly into accounting platforms such as Xero or QuickBooks. Treasury dashboards can consolidate multiple bank accounts for CFOs, providing real-time cash visibility.
Lending and Risk
Lenders can perform instant affordability checks using live transaction data. BNPL providers can reduce defaults by assessing income patterns directly from bank records. These tools align with financial inclusion goals while lowering risk.
Embedded Finance
Open banking enables financial services within non-financial platforms. For example, a property rental app could use bank APIs to verify tenant income. A travel booking platform could initiate instant loans or insurance cover.
Open Finance Extensions
The roadmap extends beyond banking into loans, cards, and insurance APIs. This will enable apps that not only manage payments but also originate credit or insurance policies directly through regulated APIs.
Data Governance and Legal Grounding
Consent Records and Purpose Limitation
All customer consents must be stored with details of scope, purpose, and expiry. Regulators may request these records during audits.
Cross-Border Processing
If hosting outside the UAE, companies must comply with cross-border data transfer restrictions. Data residency planning is key to avoiding compliance breaches.
AML/CFT Alignment
Open banking apps must integrate with AML monitoring systems, identify suspicious patterns, and report them to the Central Bank. This is not optional; it is a licensing condition.
Bank and Ecosystem Readiness
Conformance Profiles
While all banks adhere to the baseline specification, some may expose extended APIs. Developers should design flexible integrations to accommodate these variations.
Capacity Planning
APIs enforce rate limits. Fintechs must implement queuing and load balancing to handle bursts, particularly at merchant checkout.
Joint Incident Management
Fintechs must notify both banks and the Central Bank in the event of an incident. Pre-agreed communication protocols are part of the Trust Framework.
| Feature | UAE (CBUAE Open Finance, Phase 2) | EU/UK (PSD2, OBIE) | Saudi Arabia (SAMA Open Banking) |
|---|---|---|---|
| Model | Centralised Trust Framework with a single API Hub (Nebras Open Finance) | Decentralised: each bank builds APIs under PSD2 rules | Phased rollout with SAMA guidelines, banks build APIs |
| Scope | Banks, payments, insurance, lending (broad Open Finance vision) | Primarily banks and payments, limited extensions | Banking first, gradual move to wider financial services |
| Security Standard | OAuth 2.0 + OpenID Connect with FAPI 2.0, mTLS, JWT | OAuth 2.0 + eIDAS certificates, variable security maturity | OAuth 2.0 + OpenID Connect, aligned with FAPI principles |
| Consent Model | AlTareq unified interface for customer authorisation | Bank-specific consent flows, inconsistent UX | Bank-led consent flows, working towards standardisation |
| Customer Authentication | Strong Customer Authentication (MFA mandatory at banks) | Strong Customer Authentication under PSD2 RTS | Strong Customer Authentication required |
| Rollout | Mandated by CBUAE, started 2024, first live fintech in 2025 | PSD2 enforced since 2018, UK OBIE driving adoption | Launched 2022, phased onboarding through 2025 |
| Key Differentiator | Centralised hub reduces integration complexity and ensures uniform security | Fragmented bank APIs create inconsistency for fintechs | Gradual but regulator-supervised implementation |
| Innovation Outlook | Unified ecosystem allows faster scaling and cross-sector products | Established ecosystem but innovation slowed by API fragmentation | Growing adoption, with regional alignment to UAE standards |
Benchmarks and Lessons from Abroad
Launch Your Fintech Start-up With Virtuzone
The UAE’s Open Banking Phase 2 creates a secure, standardised environment for fintech innovation. Entrepreneurs who comply with licensing and security requirements can deliver powerful new products in payments, lending, and financial management.
Virtuzone can guide you through company setup, licensing, visas, and regulatory liaison, so you can focus on building market-ready fintech solutions. Contact us today to explore your open-banking journey.
FAQs
Can foreigners launch an open-banking fintech in the UAE?
Yes. Foreign entrepreneurs can establish licensed fintech companies in the UAE, subject to Central Bank approval and regulatory compliance.
Do we need our own licence, or can we partner with a licensed entity?
Both options exist. Direct licensing offers independence, while partnerships provide faster entry at lower initial cost.
What are the must-have security controls to pass certification?
You must implement OAuth 2.0 with FAPI 2.0, mutual TLS, consent management, audit logging, and incident reporting.
How does the UAE Phase 2 differ from PSD2 and the KSA’s approach?
The UAE model is centralised and regulator-driven, with stricter security standards than PSD2 and a more unified architecture than KSA.
How long does onboarding and certification typically take?
Expect 3 to 6 months, depending on your preparedness and the complexity of your use case.
