Performance and Load Testing for High-Traffic UAE Applications: Banking, E-Commerce, and Smart Government

Performance and load testing for high-traffic UAE applications involves simulating real-world concurrency against production-like environments to identify bottlenecks, verify SLAs, and validate compliance before launch. The UAE's regulatory environment, with the CBUAE Open Finance Circular 03/2025 mandating API conformance certification for all licensed banks and insurers, and peak commerce events generating 68% conversion surges during White Friday 2025 (according to AppsFlyer, December 2025), has pushed performance engineering from a nice-to-have to a contractual and competitive necessity. For a broader comparison of the tools used in these environments, the guide to best load testing tools in 2026 covers the full tool landscape, including JMeter, k6, Gatling, and more. This article drills into the UAE-specific scenario: what sectors need load testing, what the benchmarks look like, how to test hybrid legacy-to-modern architectures, and how to choose a testing partner that understands both the technical and regulatory terrain.

What You'll Learn

• Why UAE banking applications face mandated API performance requirements under CBUAE Open Finance Circular 03/2025

• How to plan load testing for UAE peak events including White Friday, Ramadan, and Dubai Shopping Festival

• Which tools and protocols handle hybrid pipelines combining SOAP legacy services with modern REST and gRPC APIs

• What API performance benchmarks to target for financial and government applications

• How to evaluate and select a UAE performance testing partner that handles PDPL data-residency concerns

Why Do UAE Banking Applications Need Load Testing Now More Than Ever?

The CBUAE Open Finance Circular 03/2025 came into force on 10 July 2025 and applies to all licensed banks, including foreign-bank branches operating in the UAE, as well as insurance companies. The regulation mandates that each institution establish and maintain dedicated API interfaces, and that third-party providers (TPPs) obtain FAPI 2.0, Functional, and CX certifications through the API Hub Sandbox before they can access production data. These are not aspirational targets: they are mandatory exit requirements set by the CBUAE Rulebook.

The practical consequence for QA and engineering teams is that load and performance validation of those Open Finance APIs is now a regulatory checkpoint, rather than a development milestone. FAPI 2.0 (Financial-grade API, maintained by the OpenID Foundation) imposes strict security and transport requirements that place additional processing overhead on every API call compared to a standard REST endpoint. Testing an FAPI-compliant endpoint under production concurrency, verifying that it holds P99 latencies under 300ms during peak authentication bursts, and confirming that token issuance and refresh flows do not degrade under concurrent TPP connections, these are the specific scenarios that banks need evidence for before they can pass certification.

Beyond the certification gate, the operational risk profile of UAE banking infrastructure justifies continuous performance monitoring. The UAE IT services market was valued at approximately USD 6.4 billion in 2025, according to IMARC Group, with an 8.76% projected CAGR to 2034. Financial services technology forms a significant portion of that spend. As digital banking adoption accelerates under D33, the Dubai Economic Agenda that targets doubling Dubai's economy by 2033 with a major digital economy pillar, the transaction volumes passing through core banking systems and their connected APIs are rising sharply.

Key Finding: CBUAE Open Finance Circular 03/2025 requires FAPI 2.0 conformance certification as a mandatory exit requirement before TPP production access. This converts API performance testing from a development best practice into a regulatory obligation for every bank and insurer operating in the UAE. CBUAE Rulebook, 2025

The testing architecture for UAE banking applications typically involves three layers. The first layer covers the Open Finance API endpoints themselves, testing authentication flows, consent management, and account data retrieval under concurrent TPP load. The second layer covers the core banking system responses behind those APIs, including the legacy integration middleware that most UAE banks still operate. The third layer covers the end-user mobile and web channels that consume the same data, ensuring that the combined load from direct customers and TPP-driven requests does not cause resource contention at the database or middleware layer. Skipping any of these layers produces a false sense of readiness.

What Load and Performance Testing Approach Works for UAE E-Commerce Peak Events?

UAE e-commerce operates on a distinct seasonal calendar that differs from the Black Friday and Cyber Monday cycle common in Western markets. The three critical peak windows are White Friday (typically in November, aligned with the global Black Friday period), Ramadan (when shopping patterns shift to post-iftar evening hours with peak activity between 10 PM and 2 AM), and Dubai Shopping Festival (DSF, typically January to February). Each window has different concurrency profiles, device mixes, and geographic traffic sources.

White Friday 2025 illustrated the scale of the challenge clearly. According to data from AppsFlyer, reported by Khaleej Times in December 2025, shopping app installs rose 38% year-over-year during the event, while total conversions surged 68%, with iOS seeing a 95% spike. Remarketing-driven traffic grew 75% overall. These figures translate directly into infrastructure requirements: a platform that handles 100 concurrent checkout sessions on a Tuesday may need to sustain 1,000 to 2,000 sessions during peak White Friday hours, with checkout latency held under 500ms to avoid cart abandonment.

The Ramadan window has a different shape. Retail sales in the UAE were projected to reach USD 10 billion during Ramadan 2025, according to Redseer Strategy Consultants via consultancy-me.com. Fashion purchases grew 46% and cosmetics surged 64% during the holy month, concentrated in narrow post-iftar windows. This creates a steep spike profile rather than a sustained high-load scenario. Spike testing, simulating a rapid ramp from baseline to peak within minutes rather than hours, is the appropriate load model for Ramadan traffic.

Pro Tip: Build three distinct load profiles for UAE e-commerce: a sustained high-load profile for White Friday (hours of elevated traffic), a spike profile for Ramadan (rapid bursts post-iftar), and an endurance profile for DSF (multi-week elevated baseline). Each profile exposes different failure modes and requires different infrastructure responses.

The technical areas that UAE e-commerce load tests should always validate include checkout flow performance under concurrent sessions, payment gateway latency and timeout handling (particularly for integrations with UAE payment networks and card processors), inventory lock contention under simultaneous add-to-cart actions, session management at scale, and CDN edge caching behavior. Many UAE platforms serve a multilingual customer base, with Arabic and English often rendering different assets from different CDN paths. A load test that only simulates English-language traffic may miss performance degradation specific to the Arabic content layer.

For platform selection, k6 version 1.3.0 (released September 2025) handles the scripting requirements for most UAE e-commerce scenarios well. It natively supports HTTP/1.1, HTTP/2, WebSocket, gRPC, and browser-based testing through its Chrome DevTools Protocol integration, introduced at GrafanaCON 2025 with the k6 1.0 release. Grafana k6 1.0 added native TypeScript support, which eliminates the bundler step that previously slowed teams working on complex multi-scenario test suites. For teams with existing JMeter test libraries, the current Apache JMeter version 5.6.3 remains fully capable, particularly for SOAP and legacy protocol coverage.

How Should Teams Approach Performance Testing for UAE Government and Smart-City Platforms?

Government and smart-city platforms in the UAE operate at scales that create genuine performance engineering challenges. The DubaiNow unified government platform, which provides access to services from more than 50 government and private entities, recorded 5.7 million payment transactions in 2025 and serves a user base of 2.2 million people, according to Gulf News (2025). Abu Dhabi's TAMM superapp serves 3.6 million users across more than 1,100 services. These platforms are not internal tools: they are critical public infrastructure.

The D33 strategy targets 100 transformative digital projects for Dubai by 2033, and the "We the UAE 2031" national agenda aims to double GDP with digital infrastructure as a central pillar. The regulatory and reputational cost of a government platform outage is substantially higher than a comparable commercial platform outage. A citizen who cannot renew a residence visa or pay a utility bill through a government portal has no alternative, and media coverage of government service disruptions in the UAE carries political visibility.

Performance testing for government platforms requires attention to several factors that differ from commercial application testing. First, the concurrency model is different: government platforms experience demand spikes tied to fee payment deadlines, visa renewal dates, and seasonal registration events rather than commercial promotions. The spike profile is often more concentrated (a large fraction of a population hitting the same deadline simultaneously) and harder to predict with commercial traffic data. Second, the service mix is more heterogeneous: a single citizen interaction may span six backend services (identity verification, document management, payment, notification, audit logging, and external agency integration), creating complex dependency chains where a single slow service degrades the entire user experience.

Third, government platforms in the UAE typically carry older technology layers. Many e-government platforms built in the early 2010s under the Smart Government initiative run on SOAP web services, Oracle middleware, and on-premises infrastructure, often integrated with modern REST APIs and cloud functions through gateway layers. This hybrid architecture requires load testing tools capable of handling both protocol types in a single test plan. Apache JMeter remains the most common choice for this scenario because its sampler library supports SOAP/XML, REST/JSON, JDBC, and FTP in a single test plan. For teams that need code-based test scripting with CI/CD integration, Gatling 3.x with its Java, Scala, Kotlin, or JavaScript/TypeScript SDKs provides comparable multi-protocol coverage with a more modern developer experience.

Watch Out: Testing a government platform's front-end API layer without testing the backend service chain is a common gap. If the identity verification service, which is often a shared middleware component serving multiple applications, degrades under combined load from two applications running concurrent promotions, that failure will not appear in a test that only hits the outer gateway.

When scoping performance tests for UAE government platforms, teams should identify the specific citizen transactions that carry the highest volume and the highest consequence for failure. Visa and residency services, utility payments, and traffic fine payments consistently show the highest transaction volumes. These should be the primary load scenarios, run against production-like environments with production-representative data volumes. Government data residency requirements add a specific constraint: test data must be anonymized or synthetically generated, because running load tests against real personal data of UAE residents has implications under the PDPL.

Which Tools Are Best for Hybrid Performance Testing Pipelines With Legacy Dependencies?

Many UAE enterprise applications, particularly in banking, government, and telecommunications, combine modern REST and gRPC microservices with legacy SOAP or proprietary protocol services that have not been migrated. Selecting a load testing tool for these hybrid environments requires different evaluation criteria than a greenfield microservices stack.

For UAE banking environments where FAPI 2.0 compliance testing is required alongside SOAP-based core banking integration testing, JMeter is the most pragmatic choice for the legacy layer, while k6 or Gatling handles the modern API layer. Many teams run a dual-tool strategy: JMeter tests cover SOAP and JDBC interactions, while k6 handles the Open Finance API endpoints, with results aggregated in a shared monitoring stack (Grafana, Datadog, or Dynatrace). This approach avoids the limitations of any single tool while keeping each layer tested with the most appropriate scripting model.

For pure modern stacks (REST and gRPC only, no legacy SOAP), k6 v1.3.0 is generally the preferred choice among UAE fintech startups and newer government digital teams because of its TypeScript support, lightweight scripting model, and strong integration with Grafana Cloud for results visualization.

Key Finding: Apache JMeter's sampler library supporting SOAP/XML, REST/JSON, JDBC, FTP, and JMS in a single test plan makes it the most practical choice for UAE enterprise environments with hybrid legacy-to-modern architectures. k6 v1.3.0 with native TypeScript and browser support leads for greenfield REST/gRPC-only pipelines. Grafana k6 release notes, May 2025

What API Performance Benchmarks Should UAE Financial and Government Applications Target?

Establishing concrete, measurable performance benchmarks is a prerequisite for meaningful load testing. Without agreed SLA thresholds, a load test produces numbers without actionable meaning. For UAE financial services and government applications, the relevant benchmarks differ by API type and criticality tier.

For real-time financial APIs, including payment processing, balance inquiries, and Open Finance account data endpoints, the target thresholds that engineering and operations teams commonly adopt are P50 (median) under 50ms, P90 under 100ms, and P99 under 300ms for server-side latency, according to Nurbak's API response time standards guide (2026). These are server-side figures: add 20 to 150ms for network transit depending on geography and whether the client is on mobile or fixed line. UAE mobile network latency from major operators on 5G is generally lower than European averages, but test environments should account for peak-period radio congestion in dense urban areas like Dubai Marina, Downtown Dubai, and Abu Dhabi's business districts.

For government e-service transactions, acceptable response-time targets are generally less strict than real-time finance, but the tolerance for tail latency (P99 and P99.9) is lower because citizen-facing services carry accessibility obligations. A P99 of 3 seconds for a form-submission endpoint is often tolerable; a P99.9 of 15 seconds is not, because it affects a measurable fraction of every high-volume transaction window. Government platforms should also track Apdex scores (Application Performance Index) rather than raw latency percentiles alone, because Apdex normalizes user experience across different transaction types.

These benchmarks should be defined in a performance requirements document before test execution begins, ideally during the sprint or iteration where the endpoint is first designed. The benchmarks become the pass/fail criteria for load test runs, not post-hoc observations. When results show that a P99 is 3x the target threshold, that is a clear failing condition that drives engineering action, not a trend to monitor.

End-to-end performance validation adds a third dimension beyond API latency: the full user journey time from browser or mobile app request through all backend hops to rendered response. For UAE e-commerce, the checkout journey typically spans 8 to 12 API calls, including session validation, cart retrieval, stock check, payment gateway initiation, order confirmation, and notification dispatch. Validating each API in isolation does not reveal serialization effects or connection-pool exhaustion that only appear when all 12 calls execute concurrently from 500 users.

How Do UAE-Specific Compliance Requirements Shape Performance Test Design?

Compliance requirements in the UAE directly influence how performance tests must be designed, beyond the question of which APIs are tested. Three regulations have the most direct impact: the PDPL, the CBUAE Open Finance Circular 03/2025, and the ADHICS v2 framework (for healthcare applications).

The UAE Personal Data Protection Law, Federal Decree-Law No. 45/2021, carries extraterritorial scope under Article 2: any entity outside the UAE that processes personal data of individuals residing in the UAE falls within the law's scope, regardless of where the processing physically occurs. This is the PDPL's most significant implication for performance testing teams using offshore engineers or cloud-based load generation infrastructure. A load test that injects real user records from a production database to generate realistic traffic patterns is processing personal data, and if that processing occurs on servers outside the UAE or is orchestrated by engineers based outside the UAE, Article 2 applies.

The practical response for most teams is synthetic data generation. Realistic load profiles can be built using synthetically generated data that mirrors the statistical distribution of real data (name formats, UAE phone number patterns, Emirates ID structures) without using actual personal records. This eliminates the PDPL exposure without sacrificing test realism. Cross-border data transfer restrictions under PDPL Articles 22 to 23 also apply to test data movement, requiring adequacy decisions or contractual safeguards when sending data to testing partners in third countries.

For the CBUAE Open Finance framework, the API conformance testing requirements mean that performance tests must run against the API Hub Sandbox environment using FAPI 2.0-compliant request formats. Performance tests that use simplified authentication flows or non-compliant token structures will pass load tests but fail conformance certification. Aligning load test scripts with the precise FAPI 2.0 specifications from the outset, including PKCE (Proof Key for Code Exchange), PAR (Pushed Authorization Requests), and mTLS client authentication, is essential.

For healthtech applications in Abu Dhabi, the ADHICS v2 framework (DOH/SD/ICSO/ADHICS/V2/2024, effective August 2024, with next review due May 2027) mandates yearly vulnerability assessments and penetration testing of web applications, mobile applications, and connected medical devices under control CO 7.1. Performance testing in this context is typically paired with security testing: load testing identifies response-time degradation patterns under concurrent access, while penetration testing at similar load levels identifies whether security controls (rate limiting, anomaly detection) remain effective under pressure or degrade in ways that create exploitable windows.

What Does Soak, Stress, and Spike Testing Reveal for UAE Applications Specifically?

Performance testing encompasses several distinct test types, each revealing different failure modes. For UAE applications, the right combination depends on the sector and the specific risk being managed.

Soak testing, also called endurance testing, runs a sustained moderate load for extended periods, typically 4 to 72 hours, to identify memory leaks, connection pool exhaustion, and gradual performance degradation that only manifests after prolonged operation. UAE government platforms are particularly vulnerable to the class of failures that soak testing uncovers because they often run on older Java application server stacks where memory management is manual and garbage collection pauses accumulate over multi-day uptime cycles. A government platform that performs acceptably under a 30-minute load test may degrade significantly after 48 hours of continuous operation at 60% capacity.

Stress testing intentionally pushes systems beyond expected capacity to find the breaking point and characterize failure behavior. For UAE banking applications, stress testing should verify that the system degrades gracefully under overload rather than failing catastrophically. A core banking API that returns queue-timeout errors under 3x normal load is preferable to one that returns corrupted data or silent failures, which could create downstream reconciliation problems. The CBUAE's operational resilience expectations for financial institutions set a context where demonstrating controlled failure behavior is a component of the overall reliability posture.

Spike testing simulates a sudden, steep increase in traffic over a short time window, which is the most relevant load profile for UAE Ramadan e-commerce events and for government platforms around major fee payment deadlines. The test verifies that auto-scaling infrastructure provisions capacity quickly enough to absorb the spike without the initial surge triggering cascading timeouts. For cloud-deployed UAE applications, the specific metrics to validate during spike tests are scale-out latency (how long it takes from traffic spike to new compute capacity being active), connection draining behavior during scale-in, and database connection pool behavior when the number of application instances jumps rapidly.

Volume testing deserves specific mention for UAE applications dealing with Arabic text. Arabic is a right-to-left language with a complex character set, and applications handling Arabic names, addresses, and document content often carry higher database storage requirements per record than equivalent Latin-alphabet data. Volume tests should use Arabic-character test data where the application handles Arabic content, because character encoding, sort operations, and full-text search queries can behave very differently with Arabic strings than with ASCII test data. This is an often-missed dimension of performance testing for UAE-localized applications.

How Should UAE Teams Select and Evaluate a Performance Testing Partner?

Selecting a performance testing partner for UAE applications involves a different set of evaluation criteria than a generic technology procurement. The intersection of technical depth, regulatory familiarity, and data-handling practices narrows the field considerably.

Technical competence is the baseline. A credible performance testing partner for UAE financial services should demonstrate experience with FAPI 2.0 conformance testing environments, beyond standard REST load testing. They should be able to produce test scripts that accurately replicate FAPI 2.0 authentication flows, including mTLS client certificates and PAR, rather than simplified bearer-token authentication that will not reflect production behavior. For government and smart-city platforms, they should understand multi-protocol test architecture (SOAP, REST, and possibly proprietary messaging protocols coexisting in the same test plan) and be able to instrument the test to measure backend service chain latency, beyond the outer API layer alone.

Regulatory familiarity is a meaningful differentiator for UAE engagements specifically. A partner that understands the CBUAE Open Finance framework can align load test scenarios directly with the conformance certification requirements, so that test results serve a dual purpose: engineering validation and regulatory evidence. A partner unfamiliar with ADHICS CO 7.1 will not know that healthcare application performance tests should be paired with a concurrent security posture review. This domain knowledge shortens the scoping phase of a performance testing engagement significantly.

Data handling and PDPL compliance is not optional. Any partner using production-derived test data, or handling test data on infrastructure outside the UAE, needs to have documented practices for PDPL compliance under Article 2's extraterritorial scope. Asking for evidence of this during the evaluation stage, not after contract signature, is the right approach. Partners with established data anonymization workflows and the ability to generate UAE-realistic synthetic data (Arabic names, UAE phone formats, Emirates ID structures) reduce the PDPL risk while maintaining test realism.

For teams evaluating UAE-specific options, Vervali's UAE performance testing service covers load, stress, soak, and spike testing for UAE financial, government, and e-commerce applications, with teams across India and the UAE operating under the India-UAE CEPA framework (in force May 2022, covering IT and computer services). The CEPA provides a formal sovereign trade basis for cross-border IT service delivery, with the UAE committed to 100% foreign ownership in computer services for qualifying firms. Indian QA partners operating under CEPA are 1.5 hours ahead of UAE time in India Standard Time, providing near-complete working-day overlap for collaborative test execution.

Pro Tip: When evaluating a performance testing partner for UAE financial applications, ask specifically whether they have run load tests against FAPI 2.0-compliant sandbox environments, beyond general REST APIs. The authentication flows, token structures, and consent management mechanisms in FAPI 2.0 differ substantially from standard OAuth 2.0, and a test suite that shortcuts these flows produces misleading results.

For teams comparing providers who offer related API testing services, the performance dimension of API testing (latency, throughput, error rates under concurrency) should be explicitly included in the scope discussion, because some providers treat API testing and performance testing as separate service lines with different teams. Combined API functional and performance validation, using contract testing to verify functional correctness alongside load testing for performance characteristics, is more efficient than two separate engagements.

What Results Can Organizations Expect from Systematic Performance Testing Programs?

Organizations that approach performance testing as a continuous program rather than a one-time pre-launch activity consistently achieve better outcomes than those that run load tests only before major releases. For UAE applications specifically, the measurable outcomes cluster around three dimensions: incident prevention, regulatory readiness, and release velocity.

Incident prevention is the most direct outcome. A UAE e-commerce platform that runs spike tests simulating White Friday traffic patterns in October will identify bottlenecks before the actual event. If the test reveals that the checkout flow fails above 800 concurrent sessions due to a connection pool limit in the payment gateway integration, the fix requires a configuration change costing hours of engineering time. The alternative, discovering the same constraint during the actual White Friday peak, costs hours of transaction failures, customer support escalations, and reputational damage in a market where alternative platforms are one tap away.

Regulatory readiness is increasingly measurable for UAE financial services. Teams running continuous load tests against their Open Finance API endpoints, as part of a CI/CD pipeline that validates performance on every API change, can maintain a living record of performance characteristics across build versions. When CBUAE conformance certification requires evidence that the API meets performance standards under concurrent load, this continuous test record provides the evidence base. Teams without this record may need to run a full performance validation program from scratch when the certification deadline approaches, at substantially higher cost and risk.

Release velocity is the less obvious but often the most significant commercial outcome. Teams that run performance tests in CI/CD pipelines identify regressions immediately, at the point of code change, rather than discovering them in integration testing or production. A 200ms latency regression in an FAPI 2.0 authentication endpoint caught in a developer's pull request takes minutes to fix and causes zero user impact. The same regression discovered in production during a Ramadan peak window is a severity-1 incident. For UAE government technology teams, where release cycles often span months due to change management requirements, finding performance regressions in the development phase prevents the costly delay of a post-deployment emergency patch requiring re-approval through the change management process.

For sibling coverage of the cloud infrastructure dimension of load testing for e-commerce applications, the analysis of cloud load testing for e-commerce covers AWS, Azure, and GCP environments with specific Black Friday simulation frameworks.

TL;DR: Performance testing for UAE applications is now shaped by three forces: the CBUAE Open Finance Circular 03/2025 making API conformance testing a regulatory requirement for banks, peak commerce events (White Friday, Ramadan, DSF) creating spike-load demands that require advance simulation, and government smart-city platforms scaling to millions of concurrent citizen transactions. The right tool depends on the protocol mix: JMeter for hybrid SOAP-REST environments, k6 v1.3.0 for modern REST/gRPC stacks. The right benchmark framework uses P50/P90/P99 latency targets by API category. The right partner understands PDPL extraterritoriality and can align load test evidence with CBUAE conformance certification requirements.

Ready to Validate Your UAE Application's Performance Before the Next Peak Event?

Engineering teams at UAE banks, e-commerce platforms, and government technology departments can reduce the risk of peak-event failures through structured load and performance testing programs aligned with both technical benchmarks and UAE regulatory requirements. Explore Vervali's UAE performance testing service for load, stress, soak, and spike testing tailored to UAE financial, government, and retail applications.

Sources

1. AppsFlyer via Khaleej Times (December 2025). "White Friday 2025 sees UAE shopping app installs jump 38%." https://www.khaleejtimes.com/business/white-friday-2025-sees-uae-shopping-app-installs-jump-38

2. Gulf News (2025). "DubaiNow hits 5.7 million payments in 2025 as 70 new services added." https://gulfnews.com/business/banking/dubainow-hits-57-million-payments-in-2025-as-70-new-services-added-1.500450120

3. CBUAE Rulebook (2025). "Open Finance Regulation." https://rulebook.centralbank.ae/en/rulebook/open-finance-regulation

4. Mordor Intelligence (2025). "UAE E-Commerce Market." https://www.mordorintelligence.com/industry-reports/united-arab-emirates-ecommerce-market

5. IMARC Group (2025). "UAE IT Services Market." https://www.imarcgroup.com/uae-it-services-market

6. Nurbak (2026). "API Response Time: Standards and Benchmarks." https://nurbak.com/en/blog/api-response-time/

7. Consultancy ME via Redseer (2025). "Ramadan retail sales in UAE to eclipse $10 billion this year." https://www.consultancy-me.com/news/10378/ramadan-retail-sales-in-uae-to-eclipse-10-billion-this-year

8. Grafana k6 (2025). "k6 1.0 release notes and version history." https://k6.io/

9. Grafana / GitHub k6 repository (2025). "k6 v1.3.0 release, September 2025." https://github.com/grafana/k6

10. Apache Software Foundation (2024). "Apache JMeter changes." https://jmeter.apache.org/changes.html

11. Gatling (2025). "Gatling documentation and download." https://gatling.io/

12. Pinsent Masons (2025). "Open finance in the UAE: laws and regulation." https://www.pinsentmasons.com/out-law/guides/uae-open-finance

13. UAE Ministry of Economy (2022). "India-UAE CEPA." https://www.moec.gov.ae/en/free-trade-agreements/india.html

14. UAE Federal Decree-Law No. 45/2021 (PDPL). "Personal Data Protection Law." https://u.ae/en/about-the-uae/digital-uae/data/personal-data-protection-laws