Fintech and crypto
R&D tax credits
in the UAE
Developing payment systems, financial software or digital-asset infrastructure in the UAE? Your project may contain qualifying R&D if it investigates a scientific or technological uncertainty through planned, documented work.
R&D tax credits for fintech.
From DIFC and ADGM-licensed firms to crypto and digital-asset builders, UAE fintechs are pushing systems past their known limits on latency, scale and security. That work often qualifies for the R&D Tax Credit the discipline is proving precisely which part.
The assessment starts with what your team could not resolve using available knowledge, what it tested and what it learned. A new product, regulatory licence or use of blockchain does not establish eligibility on its own. The project, entity, expenditure and pre-approval conditions must also be met. [1, 2, 3]
How qualifying R&D shows up in fintech.
The UAE regime tests every project against the five OECD Frascati criteria. Here is what each looks like in a ledger, a settlement path, or a fraud model.
Novel
A settlement, cryptographic or consensus method not already available.
Creative
Original mechanisms, not the routine assembly of known components.
Uncertain
Whether it holds at required latency, scale or security is unknown.
Systematic
Planned load tests, proofs and iterations, properly documented.
Transferable
Results reproducible across environments and volumes.
Where fintech development may involve R&D
Qualifying work may sit within a larger commercial development programme. The useful starting point is a specific technical problem and the investigation undertaken to resolve it.
Payments and settlement
Did the team investigate unresolved transaction-ordering, consistency or recovery problems that available methods could not meet under the project’s constraints?
Connecting a published payment API, adding checkout options or configuring reconciliation rules.
Fraud and financial-crime systems
Did the team test a new technical approach to detecting patterns across fragmented data while preserving useful accuracy, privacy or response time?
Buying an AML tool, adjusting known rules or producing routine compliance reports.
Open Finance and identity
Did consent, credential or interoperability constraints create a demonstrable technical uncertainty that required experimentation?
Implementing documented consent flows, standard identity checks or required API access.
Custody and digital-asset infrastructure
Did the team investigate unresolved key-recovery, transaction-control, verification or distributed-system behaviour?
Deploying standard wallet software, existing smart-contract templates or ordinary custody controls.
The kind of work that qualifies.
Illustrative technical scenarios from the current Fintech page. Assess each against the project conditions above.
High-throughput settlement engine
A settlement or ledger system reaching throughput or finality that available databases cannot support.
Applied cryptography
Novel cryptographic or consensus mechanisms for a regulated digital-asset platform.
Cross-chain interoperability
Bridging or interoperability methods that resolve security and consistency problems with no proven answer.
Programmable compliance
Embedding regulatory logic into transaction flows in ways existing platforms cannot express.
Genuine R&D, not routine engineering.
The value we add is drawing this line correctly claiming what qualifies, and defending it, while leaving out what does not.
Typically qualifies
- Pushing a system beyond known limits of latency, scale or security.
- Developing novel cryptography, consensus or interoperability with uncertain outcomes.
- Modelling fraud or risk where a new technical approach is required.
- Systematic experimentation to resolve a genuine technological uncertainty.
typically doesn't
- Wiring up an existing payment gateway or KYC provider.
- Building standard CRUD screens, dashboards or reports.
- Configuring off-the-shelf ledger or exchange software.
- Commercial or regulatory analysis with no technical uncertainty.
Separate experimental development from routine delivery
The UAE rules require qualifying activity to be novel, creative, uncertain, systematic and transferable or reproducible. For software, the Frascati Manual distinguishes work involving scientific or technological advance from routine development and the application of established methods. [1, 2, 3]
An assessment should identify the existing technical baseline, explain its limitations and trace the alternatives tested. Product specifications and a list of features rarely answer those questions alone. A technically unsuccessful experiment may still be relevant to the assessment; success or failure by itself does not establish tax eligibility. [2, 3]
Routine integration, interface redesign, standard cloud migration, ordinary bug fixing, vendor configuration and regulatory reporting do not establish R&D by themselves. If a broader delivery programme contains a distinct qualifying investigation, identify its activities and costs separately from the rest of the programme.
The UAE tax-credit conditions that matter
First AED 1 million
2
Above AED 1 million to AED 2 million
6
Above AED 2 million to AED 5 million
14
The rates apply to the corresponding portions of expenditure, with both expenditure and staffing conditions relevant to the calculation. R&D staff means qualifying full-time or full-time-equivalent staff, calculated under the prescribed averaging rules. Applying all three bands gives a maximum AED 2 million credit on AED 5 million qualifying expenditure per qualifying entity or Tax Group in the relevant period, when the required conditions are met. This is not a flat 50% credit on all spending or a cash refund. [1, 2]
Each project must meet the AED 500,000 qualifying-expenditure minimum for the relevant period, excluding the staff-cost uplift. Only qualifying activities carried out in the UAE are included. Council pre-approval is required for each claimed project. Free-zone status, Small Business Relief elections, group arrangements and the entity’s entitlement to R&D returns can affect eligibility and must be reviewed. [1, 2]
Build the evidence around the investigation
Prepare a record that connects the technical work to the project and the expenditure. Useful assessment material includes:
The project objective, the existing technical approach and the uncertainty encountered.
Design alternatives, experimental plans, prototypes, test results and findings, including unsuccessful approaches.
The people who performed the work, their UAE location and an appropriate record of time or activity allocation.
Project-level staff costs, relevant consumables and qualifying subcontracting, separated from routine delivery and overseas work.
Contracts explaining financial responsibility, rights to results, subcontracting and any grant support.
Council pre-approval documentation and the financial records needed to support the claim.
Regulatory approval and R&D assessment answer different questions
CBUAE, FSRA, DFSA and VARA frameworks may shape a fintech project’s operating constraints and testing environment. A licence or sandbox participation can provide useful context, but it does not establish R&D tax eligibility or replace Emirates Research and Development Council pre-approval. [1, 2, 4, 5, 6, 7]
For example, current Open Finance requirements address API access, consent, authentication and secure communication. Implementing those requirements using established methods is a baseline compliance task. An R&D assessment needs evidence of the separate scientific or technological uncertainty investigated. The same distinction applies to custody controls, key management and smart-contract testing.
AED 396M+
ICAEW Chartered Accountants, AED 396M+ (£80M+) in R&D incentives secured in the UK 1,300+ R&D claims processed (UK practice) – including payments infrastructure, risk engines, ledgers and digital assets. The same chartered method now applies to the UAE.
“Very easy to use, great support and transparent pricing. The team guided us through every step of our claim.”
VoxSmart – financial technology client
A UAE fintech case study will feature here as claims complete under the new regime.
Questions fintech teams ask
Eligibility, project boundaries and the evidence behind a claim.
Does blockchain integration qualify?
Integrating an existing chain to spec usually does not. But developing novel consensus, cryptography or interoperability to solve a problem with no established solution frequently does. We assess each project on the technical uncertainty involved.
We build on existing rails. Can we claim?
Often, yes – where your team did genuine development to extend those rails beyond their known limits on latency, scale or security. Simply configuring proven components does not qualify.
Is fraud and AML work eligible?
It can be. Rule tuning is routine, but building detection methods where the modelling approach itself is uncertain and requires experimentation can qualify.
What evidence will we need?
Contemporaneous records: the technical uncertainty, the work done to resolve it, and project-level cost and staff-time allocation. We build this as the work happens – and pre-approval is mandatory before claiming.
Building fintech? Let’s find what qualifies.
We assess your projects against the five criteria, handle pre-approval, and build the evidence before a single figure is claimed.
Discuss your fintech R&D project
Bring a short description of the technical problem, what your team investigated, where the work took place and the expenditure involved. Those details provide a useful starting point for a project assessment and for identifying the evidence still needed.
Supporting references
1. Ministry of Finance, Cabinet Decision No 215 of 2025, particularly Articles 1, 3–6 and 9. Entity and project conditions, expenditure, use of credit and claim requirements.
2. Ministry of Finance, Ministerial Decision No 24 of 2026, particularly Articles 2–5, 8–12 and 17. Rates, staff thresholds, non-refundability, activities, pre-approval, costs and records.
3. OECD, Frascati Manual 2015, paragraphs 2.68–2.74. Software R&D and routine-development boundaries, read with the UAE statutory criteria.
4. Central Bank of the UAE, Open Finance Regulation C 03/2025, Introduction and Scope. Current framework, consent, authentication and secure communication.
5. Central Bank of the UAE, Sandbox Conditions Regulation C 6/2023. Regulatory testing conditions.
6. ADGM fintech and RegLab and DFSA innovation and testing licence. Official regulatory testing context.
7. VARA, Technology and Information Rulebook, Part I, and Custody Services Rulebook, Part III. Established technology, key-management and custody requirements.
8. NIST, Blockchain Technology Overview, sections 4 and 6. Established blockchain and smart-contract concepts; their use alone does not demonstrate qualifying R&D.