Security Testing for UAE Banks & Fintechs

In the UAE a bank or financial institution is expected to run independent security testing under the CBUAE regime, PCI DSS wherever card data is handled, and the SWIFT Customer Security Programme for anyone connected to the SWIFT network. Dubai government-linked entities also fall under the DESC ISR.

CBUAE

Licensed banks, finance companies, payment service providers and stored-value facilities must test periodically and after significant change, with findings tracked to closure. The engagement produces the scope rationale, findings, owners and retest evidence an examiner reads.

PCI DSS

Any environment that stores, processes or transmits cardholder data needs testing at defined intervals and after significant change. Scoping and segmentation decide the cost here more than anything else.

SWIFT CSP

Connectivity to SWIFT carries its own controls, several of which an assessment against the secure zone evidences directly. We scope the secure zone explicitly rather than folding it into the wider network.

An open finance API pentest covers authorisation at the object and function level, consent and token handling, and the limits that stop one accredited party reaching another party's data. In this region that is where the serious findings sit.

The most common high-severity finding we report on banking APIs is broken object level authorisation: change an identifier in a request and back comes an account, a statement or a payment that belongs to someone else. A scanner cannot reason about that, so we test it by hand, per role and per resource.

We scope the gateway, the identity provider and the services behind them separately, because a control enforced at the gateway is not the same as one enforced at the service, and an attacker reaches the service.

Yes. Production testing is agreed in writing first, denial-of-service techniques are excluded by default, and the rules of engagement fix the testing window, the excluded techniques and a deconfliction contact before any work starts, so nothing arrives as a surprise.

Where a test case would create real records or move real money, it runs against a production-equivalent environment instead. Where that environment differs materially from production, the report says so, because a test of a different configuration is a test of a different system.

A named contact on both sides handles the case where a tester finds an active compromise rather than a weakness. That path is settled before day one, not during the incident.

A UAE bank should test at least annually for anything internet-facing, before a significant release reaches production, and after any material change to authentication, authorisation or the payment path. Where a regulator names an interval, treat it as a floor rather than a schedule.

A new payment flow, a new open-finance integration or a rewritten login are the changes most likely to introduce the flaws that matter, and each is a reason to test the affected area rather than wait for the annual cycle.

We run the same phases on every engagement so two reports a year apart are comparable, and you can see what changed rather than reading two unrelated documents.

Yes. Every engagement produces the chain an examiner asks for: the scope and why it was drawn that way, the authorisation, the findings with severity and owners, the remediation order, and the retest report that turns a finding marked resolved into a finding with evidence behind it.

You also receive a signed attestation of testing for procurement and auditors. It states the scope, the dates, the standard applied and the outcome, which is what most examiners and tender teams actually require.

Findings are mapped to MITRE ATT&CK so your detection team can see which techniques were used and whether anything noticed.

Most financial institutions start with a web and API pentest of their banking channels, add a mobile app pentest for the customer apps, and run an internal infrastructure pentest across the network. An objective-based Red Team and a social engineering test follow once the basics are covered.

The right mix depends on what you are protecting and what a regulator has asked for. We scope it with you rather than selling a fixed bundle, and we say where something is not worth buying yet.

The people on your engagement are named, vetted operators measured against a published bar, not work quietly handed to an unnamed subcontractor. You get a direct line to whoever found a given issue, so a question about a finding goes to the person who proved it rather than through an account manager.

All work runs under a signed NDA and written rules of engagement agreed before anything starts. Those rules fix the scope, the testing window and the excluded techniques, and name a deconfliction contact on each side.

How long we keep the evidence and when we destroy it is stated in writing, not left to assumption. Findings are mapped to MITRE ATT&CK, so your detection team can match each one to a technique and check whether anything noticed.