CBUAE Notice 3057: What UAE Banks Must Do Before 31 March 2026

If you run compliance, risk, or security at a UAE bank or fintech, you are almost certainly staring at one date right now: 31 March 2026. That is the enforcement deadline baked into CBUAE Notice FCMCP/2025/3057, and it is the single most time-boxed, UAE-specific compliance trigger in the payments space this year. The good news is that almost everything the notice asks for, you can knock out in one program that also closes your PCI DSS client-side gaps. The bad news is that the clock is genuinely short, and “we have a WAF” is not an answer that survives this notice.

This post is the plain-English explainer the regulator did not write for you. We cover what 3057 actually demands, how it maps onto PCI DSS Requirements 6.4.3 and 11.6.1, an 8-point checklist, and a week-by-week roadmap that works backward from the deadline. If you also move money over SWIFT, read our companion piece on SWIFT CSP and CBUAE compliance - this article stays focused on the client-side and payment-page layer.

What CBUAE Notice 3057 Actually Requires (Plain English)

Let’s name the thing precisely. CBUAE Notice FCMCP/2025/3057 is a directive from the Central Bank of the UAE that binds all Licensed Financial Institutions - retail and commercial banks, fintechs, payment service providers, and exchange houses. The enforcement date is 31 March 2026. There is no quiet grace period in the language; after that date, non-compliance becomes a supervisory matter.

The core demand is straightforward to state and harder to do: secure your client-side digital channels against script tampering, e-skimming, and unauthorized third-party scripts on payment and login pages. In other words, the regulator wants you to control and watch the JavaScript that runs in your customer’s browser when they pay or sign in.

Why now? Because the global Magecart and e-skimming wave has spent the last several years hitting financial digital channels through exactly this gap. Attackers do not need to breach your servers. They compromise a third-party script - an analytics tag, a chat widget, a tag manager, an ad pixel - and skim card numbers and credentials straight out of the browser before any of your server-side controls ever see the data. The Central Bank is responding to a real, active threat, not a theoretical one.

Here is the part that trips up most teams: client-side security is the layer your traditional defenses cannot see. Your WAF inspects requests hitting your servers. Your server-side logging records what your backend processes. Neither of them watches the code executing in the customer’s browser. A skimming script can quietly POST card data to an attacker’s domain and your WAF will never flag it, because the request never touches your infrastructure. That blind spot is exactly what Notice 3057 forces you to close.

CBUAE 3057 to PCI DSS Control Mapping (The Table That Saves You Weeks)

If your organization is already on a PCI DSS v4.0.1 journey, you have done more of this work than you think. The two payment-page requirements that landed with PCI DSS v4 - 6.4.3 and 11.6.1 - are essentially the same controls 3057 is asking for. Here is the side-by-side:

The headline takeaway, and the number worth writing on the whiteboard: a single client-side monitoring control set can satisfy roughly 80% of both CBUAE 3057 and PCI DSS 6.4.3/11.6.1 obligations. Do the work once, attest twice. Inventory, authorization, tamper detection, alerting - it is the same machinery for both regimes.

Where does 3057 go further than PCI DSS? Two places. First, scope: PCI DSS 6.4.3 and 11.6.1 only care about payment pages inside the cardholder data environment. CBUAE 3057 reaches login pages and non-card digital channels too, because credential theft is just as damaging to a bank as card skimming. Second, who you answer to: PCI DSS evidence goes to your QSA and acquirer; 3057 evidence goes to a national regulator with supervisory teeth. Same controls, broader surface, higher stakes.

The 8-Point CBUAE 3057 Compliance Checklist

Print this. Walk it down with your team. Each item is a deliverable, not a sentiment.

1. Inventory every script on payment and authentication pages. First-party code, analytics, chat widgets, tag managers, ad pixels, A/B testing tools - all of it. You cannot secure what you have not enumerated. Most teams are shocked by how many scripts they find, and by how many they cannot explain.

2. Authorize each script and keep a justification register. For every script in the inventory, record who owns it, what business purpose it serves, and the explicit decision to allow it. This is the heart of PCI DSS 6.4.3 and the documentary backbone of your 3057 attestation.

3. Deploy tamper and integrity detection. Choose your mechanism: Content Security Policy (CSP) reporting to catch unexpected script origins, Subresource Integrity (SRI) to block modified assets, or a commercial client-side monitoring tool for richer coverage. High-traffic banking channels usually need more than native controls alone.

4. Establish alerting and an incident response path. Detection without alerting is just logging nobody reads. Route unauthorized-change alerts to your SOC and document the response runbook - who triages, who pulls the script, who notifies the regulator if needed.

5. Map data flows on the page. Confirm that no cardholder data or credential ever leaves the page to an unauthorized endpoint. This is where you catch the skimmer that the inventory missed.

6. Document governance. Define ownership of the control set, a review cadence (scripts change; your register must keep up), and the evidence format you will hand to CBUAE.

7. Run a pre-deadline gap assessment. Independently validate the controls against both 3057 and PCI DSS 6.4.3/11.6.1 before the regulator does. Find the gaps while you still have runway to fix them.

8. Execute a remediation sprint to close what the assessment finds. Budget time for this. A gap assessment that lands on 30 March is a report, not compliance.

Remediation Roadmap: From Today to 31 March 2026

Work backward from the deadline. The exact dates flex depending on when you start, but the sequence does not. Here is a compressed plan that assumes you begin with roughly eight to ten weeks of runway:

On tooling, you have real choices. Native browser controls - CSP with reporting plus SRI - are free, standards-based, and genuinely sufficient for simpler sites with a tight, stable script set. For high-traffic banking channels with dozens of third-party scripts and frequent releases, a managed client-side security tool earns its keep. Named options worth evaluating include Jscrambler, Feroot, Otto-js, and Akamai Page Integrity Manager. The build-vs-buy call comes down to traffic, script volatility, and how much engineering time you can spare before March.

What happens if you miss the deadline? Licensed Financial Institutions that have not implemented and documented these controls face CBUAE supervisory action exposure - and “we were almost done” is a weak position in front of a national regulator. That said, partial progress still matters. A documented inventory, deployed detection, and a credible remediation plan in flight is a dramatically better posture than a blank file, both for the regulator conversation and for your actual risk. Start now, show momentum, and close the gap as fast as you can.

How pcidss.ae Closes CBUAE 3057 and PCI DSS Gaps in One Engagement

Here is where we earn our keep. Most consultancies speak either the CBUAE dialect or the PCI DSS dialect. We speak both, and we run them as one combined remediation sprint: a single client-side gap assessment, a single control set, and two attestations. You do not pay for the same script inventory twice.

The output is QSA-grade evidence packaging that satisfies your CBUAE supervisor and your acquiring bank from the same body of work - the justification register, the detection configuration, the alerting runbook, and the governance docs, all formatted for both audiences. If you are mid-journey on PCI DSS, we plug straight into it; see our PCI DSS gap analysis and remediation planning services, and our combined SWIFT and CBUAE compliance program if you also move funds over SWIFT.

We work across UAE banking and fintech clients, which means we have seen what CBUAE supervisors expect to see and what trips institutions up at the last mile.

Given that the deadline is live, the right next step is a fast scoping call. Book a free 30-minute CBUAE 3057 readiness call - we map your client-side gaps against both 3057 and PCI DSS 6.4.3/11.6.1 and hand you a deadline-backward remediation plan you can act on the same week. Get in touch and let’s beat the clock.

Related reading

• SWIFT CSP and CBUAE Compliance - the companion piece for institutions moving funds over SWIFT