Payment service providers face unique cybersecurity challenges under CBUAE regulation. This article covers the security architecture, fraud prevention, and operational resilience controls PSPs must implement to meet regulatory expectations.
The UAE's fintech ecosystem has grown rapidly, with payment service providers and stored value facility operators now handling significant transaction volumes. The CBUAE's Retail Payment Services and Card Schemes Regulation places clear cybersecurity obligations on these entities that mirror — and in some areas exceed — the expectations placed on traditional banks. ITSEC works with PSPs across the UAE to build security programs that satisfy regulatory requirements while supporting the speed and agility that fintech businesses depend on.
While banks operate within mature technology environments with decades of security investment, established governance structures, and large security teams, many PSPs are built on modern cloud-native architectures with rapid development cycles and lean operational teams. This creates both advantages and risks.
Modern architectures can be more secure by design — containerized workloads, immutable infrastructure, and infrastructure-as-code practices eliminate entire categories of vulnerabilities that plague legacy banking systems. But the speed of feature deployment can outpace security controls if governance is not embedded in the development lifecycle. A PSP releasing code multiple times per day without security gates in the pipeline is accumulating technical debt that will eventually manifest as a security incident.
PSPs also face concentrated risk that traditional banks distribute across multiple systems. A single payment processing platform may handle millions of transactions daily across thousands of merchants. A security compromise does not affect a single branch or product line — it potentially affects every merchant and customer using the platform simultaneously. This concentration makes PSPs high-value targets for attackers who can maximize the return on a single successful intrusion.
Additionally, PSPs often handle card data, which subjects them to PCI DSS requirements alongside CBUAE obligations. Managing compliance with both frameworks requires careful architectural planning to avoid duplicating controls while ensuring no gaps exist between the two sets of requirements.
CBUAE expects PSPs to embed security into their software development processes from design through deployment. For organizations shipping code frequently, this means security must be automated and integrated into the CI/CD pipeline rather than applied as a manual gate that slows delivery.
Threat modeling during the design phase must evaluate the security implications of new features before code is written. For payment systems, threat modeling must specifically address payment flow manipulation where attackers alter transaction amounts, redirect funds, or replay completed transactions. Authentication and authorization bypass must be evaluated for every API endpoint. Data exposure risks must be assessed for any feature that creates, stores, or transmits sensitive data. Business logic abuse must be considered — how could this feature be exploited by a malicious merchant, a compromised customer device, or an insider?
Secure coding standards must be enforced through automated tooling rather than relying on developer discipline alone. Static application security testing must run on every commit, with the pipeline configured to fail on critical and high-severity findings. The SAST tool must be configured with rules specific to payment processing — generic rulesets miss payment-specific vulnerabilities such as race conditions in balance checking, insufficient precision in currency calculations, and inadequate idempotency controls.
Dynamic application security testing must run against deployed builds in staging environments that mirror production architecture. DAST testing must include authenticated scanning that exercises payment workflows end-to-end, not just unauthenticated crawling of public endpoints. Interactive application security testing that combines SAST and DAST provides additional coverage by monitoring application behavior during testing.
Code review processes must include security-focused review for all changes to critical components — payment processing logic, authentication mechanisms, cryptographic implementations, and administrative functions. Reviewers must be trained in secure development practices and payment-specific attack techniques.
Dependency management must address supply chain risk. PSPs typically rely on numerous third-party libraries, and a single compromised dependency can introduce vulnerabilities across the entire platform. Software composition analysis must run continuously, flagging dependencies with known vulnerabilities and alerting on newly disclosed issues affecting libraries in use. ITSEC recommends maintaining a software bill of materials for all production deployments and implementing automated alerts when CVEs are published affecting any listed component.
PSPs are API-first businesses. Merchant integrations, mobile applications, partner connections, and internal services all communicate through APIs. The security of these APIs is not just a technical requirement — it is the security of the business itself.
Authentication must implement OAuth 2.0 with client credentials for server-to-server integrations and authorization code flow with PKCE for mobile and browser-based applications. API keys alone are insufficient — they cannot be easily rotated, they do not expire, and they are frequently leaked in code repositories, log files, and support communications. ITSEC has found production API keys in public GitHub repositories during assessments of PSPs who were unaware of the exposure.
Authorization must enforce the principle of least privilege at the API level. Each merchant or partner should have access only to the endpoints and data relevant to their integration. A merchant processing payments should not have access to settlement APIs, reporting APIs for other merchants, or administrative endpoints. Authorization policies should be centralized and testable — ITSEC recommends implementing authorization as a policy engine rather than distributed logic across individual services.
Rate limiting and throttling must protect against both abuse and accidental overload. Payment APIs face unique challenges because legitimate traffic spikes — during sales events, payroll processing, or end-of-month reconciliation — can resemble attack patterns. Rate limiting must be intelligent enough to distinguish between legitimate spikes and genuine attacks, using per-merchant baselines rather than global thresholds.
Input validation must prevent injection attacks across all endpoints. For payment APIs specifically, validation must enforce amount range checks preventing negative or impossibly large transaction amounts, currency code validation against ISO 4217, merchant and terminal identifier format validation, and card number format validation using the Luhn algorithm at the API gateway level before card data reaches processing systems.
API monitoring must provide real-time visibility into traffic patterns, error rates, and security events. ITSEC recommends implementing API-specific threat detection that monitors for credential stuffing against authentication endpoints, systematic enumeration of merchant or customer identifiers, unusual patterns in transaction amounts or frequencies, geographic anomalies in API access patterns, and timing attacks against cryptographic operations.
Real-time fraud detection is both a business requirement and a cybersecurity obligation for PSPs. CBUAE expects PSPs to implement controls proportionate to the transaction volumes and risk profiles they handle.
Transaction-level fraud detection must operate in real-time with sub-second latency to avoid degrading the payment experience. Detection should combine rule-based controls that catch known fraud patterns with machine learning models that identify anomalous behavior that does not match established patterns. Effective detection requires device fingerprinting that identifies the hardware, software, and configuration characteristics of the device initiating the transaction — going beyond IP addresses which are easily spoofed. Behavioral biometrics that analyze how the user interacts with the application — typing patterns, navigation behavior, touch pressure on mobile devices — can distinguish legitimate users from automated tools and account takeover attempts. Velocity checks must monitor transaction frequency and amounts across multiple dimensions including per-card, per-merchant, per-device, and per-IP address. Geographic analysis for card-not-present transactions must correlate the customer's known location, the merchant's location, and the device's location to identify impossible travel patterns.
Network-level fraud detection must identify coordinated attacks across multiple merchants or accounts. A single fraudulent transaction may not trigger alerts, but a pattern of small transactions across multiple merchants using cards from the same BIN range, initiated from the same device fingerprint, represents a coordinated attack that only network-level analysis can detect.
Fraud detection models must be continuously trained on emerging patterns. Criminal techniques evolve rapidly, and models trained on historical data alone will miss novel attack methods. ITSEC recommends implementing feedback loops where confirmed fraud cases are used to retrain models within defined timeframes, and where model performance is measured against key metrics including detection rate, false positive rate, and time-to-detection.
PSPs handling card data must maintain PCI DSS compliance. While PCI DSS is an industry standard rather than a CBUAE-specific requirement, the central bank expects licensed PSPs to demonstrate current PCI DSS certification and to integrate PCI requirements into their broader cybersecurity program.
The most effective approach to PCI DSS compliance for modern PSPs is to minimize the cardholder data environment through tokenization. By replacing card numbers with tokens at the earliest possible point in the transaction flow, PSPs dramatically reduce the scope of systems that must meet PCI DSS requirements. ITSEC recommends network-level tokenization where card data is tokenized at the point of entry — either at the merchant terminal or within the PSP's API gateway — and never stored in its original form within the PSP's systems.
Where card data must be processed, encryption must protect it at every stage. Point-to-point encryption should protect data from the point of interaction through to the processing environment. Data at rest must be encrypted using AES-256 with key management that complies with PCI DSS requirements including split knowledge and dual control for encryption key components. Key rotation must occur at defined intervals with procedures for re-encrypting stored data under new keys.
Network segmentation must isolate the cardholder data environment from general corporate networks, development environments, and non-payment systems. ITSEC conducts segmentation testing as part of PCI DSS assessments, verifying that segmentation controls are effective and that no unauthorized pathways exist between the CDE and out-of-scope networks.
Payment infrastructure is critical to the UAE economy, and CBUAE expects PSPs to maintain availability and resilience commensurate with the transaction volumes they handle. Operational resilience for PSPs encompasses high availability architecture with no single points of failure for critical payment processing paths. Automated failover between processing nodes, data centers, or cloud availability zones must be tested regularly and must complete within defined recovery time objectives. Capacity planning must account for peak transaction volumes with headroom for unexpected spikes — payment platforms that degrade during peak periods create both business and regulatory risk. DDoS protection must be implemented at the network edge with the capacity to absorb volumetric attacks without affecting legitimate transaction processing.
Business continuity testing must include payment-specific scenarios including loss of connectivity to card scheme networks, failure of primary fraud detection systems requiring fallback to secondary controls, corruption of transaction databases requiring recovery from backup, and simultaneous failure of primary and secondary processing infrastructure.
ITSEC works with payment service providers and fintechs across the UAE to build security programs that satisfy CBUAE requirements while supporting innovation and growth. Our services include PCI DSS gap assessment and certification support, API security architecture review and penetration testing, secure development lifecycle implementation and CI/CD security integration, fraud detection architecture assessment, cloud security review for payment infrastructure, and ongoing vulnerability management. We understand the unique position PSPs occupy — regulated like banks but operating like technology companies. Contact ITSEC for a fintech security consultation.
Get a comprehensive security assessment from our expert team. Protecting businesses since 2011.