Key Takeaways:
- AED 1 million is the minimum capital requirement for an Open Finance Provider.
- Fintech app development can range from AED 80,000–150,000 for basic apps and AED 200,000–500,000+ for advanced Open Finance products.
- CBUAE Open Finance covers Data Sharing and Service Initiation, with businesses able to apply for one or both.
- Banks and insurance companies are included in the first phase of Open Finance implementation.
- CBUAE licensing decisions can take up to 60 working days after the required conditions are met.
- Compliance requires more than secure coding, covering consent, authentication, APIs, governance, risk management, privacy, reporting, and audit controls.
Introduction : Why Open Finance Compliance Matters for Fintech Apps in the UAE
Dubai has become one of the most active fintech markets in the Middle East, supported by a highly digital population, sophisticated banking infrastructure and growing demand for connected financial services. As fintech applications move beyond simple payments into account aggregation, financial management, payment initiation and embedded finance, regulatory compliance is becoming a core product requirement rather than a legal task that can be addressed after development.
The UAE's Central Bank has established a dedicated Open Finance Framework under its Open Finance Regulation, C 03/2025. The framework combines an API Hub, Trust Framework and Common Infrastructural Services to enable regulated data sharing and transaction initiation across financial sectors.
For technology companies, this changes how fintech applications need to be designed. Consent, authentication, secure APIs, data protection, liability management and regulatory roles must be considered at the architecture stage.
A fintech application can look simple on the customer's phone while requiring sophisticated infrastructure underneath. A user might see a single dashboard showing information from multiple financial providers, but behind that experience are APIs, authentication processes, consent records, security controls and regulated participants.
What the CBUAE Open Finance Regulation Changes for App Builders
The regulation creates a structured framework through which Open Finance Providers can perform Data Sharing and/or Service Initiation. A business wishing to provide an Open Finance service generally needs the appropriate CBUAE Open Finance Licence unless it falls into a category of Person Deemed Licensed.
This distinction matters to app developers because the technology architecture must correspond to the regulatory role of the business.
For example, an application that simply provides technology infrastructure to a licensed Open Finance Provider may have a different regulatory position from a fintech company that directly accesses customer financial information and initiates transactions.
Who This Guide Is For (Fintech Startups, Banks' Tech Partners, TPPs)
This guide is particularly relevant to fintech startups, financial institutions working with technology partners, third-party providers, payment businesses and companies planning financial applications for customers in Dubai or the wider UAE.
Dubai’s growing digital economy is driving demand for secure, scalable fintech applications, with AI, cloud infrastructure and cybersecurity playing an increasingly important role in financial services.
It is also useful for founders who are asking a common question: "Can my technology company build the application without becoming the regulated financial entity?"
The answer depends on what the company actually does. Under the CBUAE framework, a Technical Service Provider may support regulated participants without an Open Finance Licence when its activities remain limited to technical support and it does not itself engage in regulated Open Finance activities. However, regulatory responsibility cannot simply be transferred to the technology provider.
Understanding the CBUAE Open Finance Regulation

The CBUAE Open Finance Regulation establishes the regulatory foundation for secure financial-data sharing and transaction initiation in the UAE. It is designed to move the ecosystem away from fragmented access models toward standardised and controlled connectivity.
The framework is built around the API Hub, Trust Framework and Common Infrastructural Services, creating an environment in which participants can authenticate one another, exchange information securely and provide Open Finance services under defined rules.
Open Banking vs Open Insurance Under the Framework
Open Finance extends beyond traditional Open Banking.
The framework covers financial products and services within the CBUAE's regulatory scope and includes both banking-related data and insurance-related participation. The CBUAE identifies banks and insurance companies among the entities mandated to provide Open Finance access, with onboarding occurring in phases.
For app developers, this means the opportunity is broader than creating another banking dashboard.
A future-facing fintech platform could potentially connect financial information across different categories of products, provided its business model, licensing status and technical implementation satisfy the relevant regulatory requirements.
Data Sharing vs Service Initiation: The Two License Categories
The CBUAE framework separates Open Finance activities into Data Sharing and Service Initiation.
Data Sharing focuses on enabling authorised providers to access relevant customer information with the customer's consent. A personal-finance application, for example, could use this capability to present financial information from participating institutions in one interface.
Service Initiation goes further by allowing an authorised provider to initiate transactions on behalf of a customer through the Open Finance framework.
Businesses can apply for one or both options. The Open Finance Licence itself does not automatically authorise other regulated financial activities, such as holding customer funds or providing financial advice. Additional licences may therefore be required depending on the business model.
Mandatory Participation for CBUAE Licensees
Participation is mandatory for relevant CBUAE Licensees in relation to products and services covered by the framework. The regulation identifies banks, finance companies, payment service providers, retail payment systems providers, stored value facility providers, exchange houses, certain crowdfunding companies, insurance brokers and insurance companies among the mandated entities.
The implementation is phased rather than requiring every institution to enter the ecosystem simultaneously. The first phase includes banks, including branches of foreign banks, and insurance companies.
This phased model gives fintech businesses an important planning advantage: they can build their integration roadmap around the institutions and services entering the framework.
Who Needs a License Under the Open Finance Framework
One of the biggest compliance mistakes in fintech development is assuming that every participant has the same regulatory obligation.
The CBUAE framework differentiates between licensed Open Finance Providers, existing CBUAE-licensed entities that are treated as Persons Deemed Licensed, mandated data holders and service owners, and technical service providers.
Banks, Finance Companies and Payment Service Providers
Banks, finance companies and CBUAE-licensed payment service providers are among the institutions covered by the framework. Certain existing CBUAE licensees are treated as Persons Deemed Licensed for Open Finance services, meaning they do not need to obtain a separate Open Finance Licence but must notify the CBUAE and obtain approval before starting the relevant service.
This is important for financial institutions that already have a regulatory relationship with the Central Bank.
Third-Party Providers (TPPs) and When You Need Your Own License
A third-party fintech provider that wants to directly provide Data Sharing or Service Initiation under the Open Finance Framework generally needs an Open Finance Licence unless it qualifies as a Person Deemed Licensed.
The technology itself does not determine the licensing requirement. The actual activity does.
Consider two companies developing similar financial dashboards. Company A only supplies software to a licensed bank, while Company B independently accesses customer data and performs regulated Open Finance services. Their technology may look similar, but their regulatory responsibilities can be substantially different.
Deemed Participants and the No-Objection Certificate Route
Existing CBUAE licensees that fall within the Persons Deemed Licensed category do not apply for a separate Open Finance Licence. Instead, they must provide prior written notification to the CBUAE, describe the intended service, resources and governance arrangements, and obtain approval before commencing. The regulation states that the CBUAE's decision period is no more than 60 working days after the relevant notice requirements are met.
This route should not be confused with a general exemption from Open Finance compliance. Once approved, the relevant provisions of the regulation continue to apply.
Core Requirements for Open Finance Compliance

Building a compliant fintech app requires the regulatory framework to be reflected directly in product architecture.
The CBUAE regulation addresses areas including capital, governance, risk management, internal audit, record keeping, reporting, authentication, secure communication, customer obligations, privacy, consent and liability.
Governance and Control Requirements
A compliant fintech product needs more than secure code. The organisation behind the application needs appropriate governance, risk management, compliance and internal-control arrangements.
The CBUAE framework specifically addresses corporate governance, risk management, compliance and internal audit.
For founders, this means the compliance roadmap should include responsibilities, escalation procedures, incident management, access controls, record retention and regulatory reporting.
Minimum Capital and Professional Indemnity Insurance
The current Open Finance Regulation requires an Open Finance Provider to hold minimum capital of AED 1 million, while the CBUAE can impose additional capital requirements based on the risk, size or complexity of the provider's activities.
Professional indemnity insurance is also part of the regulatory framework. The required coverage must be appropriate to the risks associated with the provider's activities.
These are regulatory requirements, not software-development costs, and should therefore be budgeted separately from the app build.
Customer Consent and Secure Authentication Standards
Consent is one of the foundations of Open Finance.
A fintech app cannot treat consent as a generic checkbox buried inside registration. The user needs to understand what information is being accessed, why it is required and which service is being authorised.
The CBUAE framework explicitly requires Data Sharing and Service Initiation to be based on user consent, appropriate authentication and secure communication.
This creates a direct product-design requirement. Consent screens, authentication journeys, revocation mechanisms and audit records need to be considered during UX and backend development.
Data Sharing Through the API Hub
The API Hub is a central component of the UAE's Open Finance infrastructure.
The framework includes an API Manager and API Aggregator designed to provide a harmonised interface for participating APIs, while the Trust Framework includes participant directories, identity and access management, digital certificates, API documentation and a sandbox for testing and conformance certification.
For developers, this means integration should be designed around standardised connectivity rather than relying on screen scraping or unofficial access methods.
Data Protection and Security Obligations
Financial data demands a security architecture capable of protecting both the information itself and the connections through which that information moves.
How PDPL Intersects With Open Finance Data Sharing
The UAE's Personal Data Protection Law adds another layer to fintech compliance. Open Finance participation does not eliminate privacy obligations.
The UAE PDPL establishes requirements governing personal-data processing, including principles around lawful processing, security and data-subject rights.
For a fintech application, this means developers need to understand what personal information is collected, where it is stored, how long it is retained and with whom it is shared.
The best approach is to build privacy controls into the product rather than adding privacy documentation after development.
Information Security and API Infrastructure Standards
Open Finance APIs need strong authentication, secure communication, access management, monitoring and certificate-based trust.
The CBUAE regulation requires participants to use common secure communication standards, while online-accessible products must provide an interface through which Open Finance Providers can securely identify themselves, request information and initiate services. Dedicated interfaces must also use relevant ISO 20022 elements, components or approved message definitions for financial messaging.
This has practical implications for architecture: API gateways, encryption, certificate management, authentication services, monitoring and detailed logging should be considered core components rather than optional security upgrades.
Liability Rules Between Institutions and Providers
A secure financial system also needs to determine what happens when something goes wrong.
The CBUAE framework contains specific liability provisions covering unauthorised transactions, defective transactions and data breaches.
This matters when designing incident-management workflows. A fintech application should be able to establish what happened, which system initiated the transaction, which authentication event occurred and what data was exchanged.
Clear audit trails are therefore valuable not only for cybersecurity but also for dispute resolution and regulatory accountability.
Rollout Timeline and Phased Implementation
Open Finance is being introduced as a structured ecosystem rather than an overnight technology switch.
The CBUAE's current regulation states that mandated licensees will be onboarded in phases, with the first phase covering banks, including foreign-bank branches, and insurance companies. Later phases are to be announced through official channels.
Which Institutions Are in the First Phase
Banks and insurance companies form the first phase of mandated Open Finance participation under the current framework. This gives fintech businesses a clear starting point for assessing which institutions and services they need to support.
A fintech company planning account aggregation, for example, should monitor the availability and onboarding status of the institutions relevant to its customer base.
Key Compliance Deadlines to Track
Rather than relying on an old implementation calendar, fintech founders should monitor CBUAE announcements and the current regulatory framework for phase-specific requirements.
This is particularly important because the current C 03/2025 regulation supersedes the earlier C 7/2023 framework, which is now marked repealed in the CBUAE Rulebook.
What to Do If Your App Falls in a Later Phase
A later implementation phase should not be treated as permission to postpone preparation.
Founders can use the additional time to map data flows, define consent architecture, select appropriate infrastructure, establish security controls, prepare governance documentation and build against available sandbox and API specifications.
This reduces the risk of discovering regulatory or technical gaps when a required institution enters the framework.
Cost of Building a CBUAE-Compliant Fintech App
The cost of fintech mobile app development in Dubai varies significantly because "fintech app" can describe anything from a payment interface to a regulated financial platform.
A consumer finance dashboard with third-party integrations is fundamentally different from a regulated Open Finance Provider performing Data Sharing and Service Initiation.
Licensing and Legal Setup Costs
The CBUAE Open Finance Regulation establishes a minimum capital requirement of AED 1 million for an Open Finance Provider. This should not be confused with the cost of obtaining professional legal or regulatory assistance.
Legal structuring, regulatory consulting, application preparation, compliance documentation and professional services can add substantially to the project budget.
The CBUAE may also impose licensing and other fees associated with Open Finance Providers and the operation of the framework.
Technical Costs: API Integration, Security and Infrastructure
For development planning, a basic fintech application with secure authentication, a defined backend and selected financial APIs may begin around AED 80,000–150,000.
A more sophisticated Open Finance product with multiple integrations, consent management, API orchestration, transaction initiation, audit trails, security monitoring and advanced administration can move toward AED 200,000–500,000+.
These are indicative software-development ranges, not CBUAE fees or official market prices.
Ongoing Compliance Costs: Audits, Insurance and Governance
The initial build represents only part of the total cost.
Fintech companies should budget for security testing, penetration testing, compliance reviews, professional indemnity insurance, infrastructure monitoring, vulnerability management, legal advice, governance activities and future regulatory changes.
A regulated fintech application should therefore be treated as a continuously maintained financial platform rather than a project that ends at launch.
What Affects Your Total Budget
|
Cost Factor
|
Lower Complexity
|
Higher Complexity
|
|
Regulatory role
|
Technology provider
|
Licensed Open Finance Provider
|
|
Data access
|
Limited integrations
|
Multiple financial institutions
|
|
Services
|
Data display
|
Data Sharing + Service Initiation
|
|
Security
|
Standard secure APIs
|
Advanced security, monitoring and audits
|
|
Consent
|
Basic consent management
|
Centralised, granular consent lifecycle
|
|
Infrastructure
|
Standard cloud architecture
|
High-availability financial infrastructure
|
|
Compliance
|
External compliance support
|
Dedicated governance and reporting
|
|
Administration
|
Basic dashboard
|
Advanced operations, reconciliation and audit tools
|
A critical point is that AED 1 million minimum capital is not the cost of developing a fintech app. It is a regulatory capital requirement for an Open Finance Provider and should be planned separately from engineering expenditure.
A Step-by-Step Framework for Building Your Compliant Fintech App
Step 1: Determine Which License Category Applies to You
Start with the business activity, not the technology.
Determine whether your company is simply providing technology, operating as a Data Sharing Provider, providing Service Initiation, or conducting another regulated financial activity.
This decision influences the entire compliance and architecture roadmap.
Step 2: Map Your Regulatory Business Plan and Governance Structure
Document how the application operates, what financial data it handles, who owns regulatory responsibility, which third parties are involved and how risks are managed.
The CBUAE licensing framework requires applicants to satisfy legal-form, capital, fit-and-proper and other applicable requirements.
Step 3: Build Your Consent and Authentication Architecture
Design consent before designing the final payment or account-access journey.
The architecture should record user permissions, authentication events, data-access requests, consent status and revocation where applicable.
This creates an auditable foundation for both customer trust and regulatory compliance.
Step 4: Prepare Your CBUAE Application or NOC Notification
The appropriate route depends on whether the business requires an Open Finance Licence or falls under the Persons Deemed Licensed category.
The CBUAE states that a licensing application must include the relevant supporting documents and that an application can specify Data Sharing, Service Initiation or both.
Step 5: Plan for Ongoing Monitoring and Reporting
After launch, monitoring should cover API availability, failed transactions, unusual access, security incidents, consent events, authentication failures and regulatory reporting requirements.
A strong monitoring system allows technical teams to detect problems before they become customer-impacting incidents.
Common Mistakes Fintech Founders Make With Open Finance Compliance

Assuming a DIFC or ADGM Setup Removes CBUAE Obligations
DIFC and ADGM have their own financial regulatory frameworks, but incorporating a company in one of these jurisdictions does not automatically mean every UAE financial activity falls outside CBUAE regulation.
The applicable regulator depends on the entity, activity, jurisdiction and customer/service model.
Fintech founders should therefore establish the regulatory perimeter before choosing an architecture or corporate structure.
Underestimating Governance and Documentation Requirements
Many founders focus heavily on APIs and mobile screens while underestimating policies, governance structures, risk registers, incident procedures, access controls and regulatory documentation.
The CBUAE framework explicitly includes governance, risk management, compliance, internal audit, record keeping and reporting requirements.
Treating Consent Architecture as an Afterthought
Consent cannot simply be added to the application immediately before launch.
Imagine a customer connects three financial accounts and later withdraws permission for one of them. The system needs to understand exactly what access should stop, which tokens should be revoked and what records must remain for audit purposes.
That requires consent to be part of the core backend architecture.
How TechQware Builds Compliant Fintech Apps for the UAE Market
Our Approach to Secure API and Consent Architecture
TechQware approaches fintech development from both the user-experience and engineering perspective.
Our team can design mobile interfaces alongside secure backend services, API integrations, authentication workflows, consent management, transaction journeys, dashboards and administrative controls.
For an Open Finance project, this can include designing an architecture around the applicable CBUAE framework, secure API communication, audit logging, role-based access, encryption, consent records and scalable cloud infrastructure.
The objective is simple: make the financial experience intuitive for the customer while making the underlying system structured, secure and ready for regulatory scrutiny.
Working Alongside Legal and Regulatory Advisors
Technology teams should not attempt to interpret complex financial regulation in isolation.
TechQware can work alongside the client's legal, compliance and regulatory advisors so that the technical implementation reflects the approved business model.
This division of responsibility is particularly important because the CBUAE makes clear that using a Technical Service Provider does not transfer the regulated entity's legal or regulatory responsibility to that provider.
In practical terms, TechQware focuses on building the technology correctly while regulatory professionals validate the legal and licensing position.
Conclusion : Preparing Your Fintech App for a Regulated Open Finance Future
The UAE's Open Finance ecosystem represents a significant shift in how financial applications can access information and initiate transactions.
The CBUAE has created a formal framework based on secure APIs, participant trust, user consent, authentication and regulated access. It also introduces dedicated licensing for Open Finance Providers while providing a deemed-licensed route for certain existing CBUAE-regulated entities.
For fintech founders, the message is clear: compliance should not sit beside the product. It should be built into the product.
The most successful fintech applications will combine an intuitive customer experience with strong backend controls, secure API infrastructure, transparent consent mechanisms, appropriate authentication and continuous monitoring.
Whether you are developing a personal-finance platform, account aggregation application, embedded-finance product, payment solution or Open Finance service, the right technical architecture can make regulatory readiness significantly easier to manage.
Planning a CBUAE-compliant fintech app in Dubai? TechQware can help you design and develop the secure mobile, API and backend infrastructure required for a scalable UAE fintech product. Talk to Us about your fintech app idea, technical architecture and development roadmap.
FAQs
Do all fintech apps in the UAE need a CBUAE Open Finance license?
No, The requirement depends on what the fintech business actually does. A company providing only technical support to an Open Finance Provider may not require an Open Finance Licence if it does not itself perform regulated Open Finance activities. Certain existing CBUAE licensees are also treated as Persons Deemed Licensed. However, a fintech company directly providing Data Sharing or Service Initiation under the Open Finance Framework generally needs the appropriate CBUAE authorisation.
What's the difference between Data Sharing and Service Initiation licenses?
Data Sharing enables an authorised Open Finance Provider to access relevant customer information through the framework with appropriate consent. Service Initiation relates to initiating transactions on behalf of the customer. A provider can apply for either one or both options. The Open Finance Licence does not automatically permit unrelated regulated financial activities.
Is a DIFC or ADGM company exempt from CBUAE Open Finance rules?
Not automatically, DIFC and ADGM have separate regulatory frameworks and regulators, so the answer depends on the exact entity, activity, jurisdiction and customer/service structure. A business should establish its regulatory perimeter before assuming that incorporation in a financial free zone removes CBUAE requirements.
What are the minimum capital requirements for an Open Finance license?
Under the current CBUAE Open Finance Regulation, an Open Finance Provider must hold at least AED 1 million in minimum capital. The CBUAE can impose additional capital requirements based on the risk, size or complexity of the provider's activities. This is regulatory capital and should not be confused with the software development budget.
How long does the CBUAE licensing process take?
The current regulation states that the CBUAE will issue its decision on an Open Finance Licence application within a period not exceeding 60 working days from the date the applicant meets all licensing conditions and requirements. The overall project timeline can be longer because businesses first need to prepare their legal structure, documentation, governance, capital, technology and compliance arrangements.
How can TechQware help build a CBUAE-compliant fintech app?
TechQware can support the technology side of a fintech project, including mobile application development, backend architecture, secure API integrations, authentication, consent workflows, dashboards, transaction journeys, administration panels and scalable infrastructure. For regulated projects, we can work alongside your legal and compliance advisors to translate the approved regulatory and business requirements into a practical technical architecture. If you are planning a fintech application in Dubai and want to understand the development scope, technology architecture and approximate investment before starting, contact TechQware for a consultation and project discussion.