Setup of AML Software

No. Federal Decree-Law No. 20 of 2018 and its Cabinet Decision implementing regulations are technology-neutral — they require that screening, monitoring, and record-keeping obligations are actually met, not that a specific vendor's product is used. In practice, meeting those obligations consistently and at scale is very difficult without software once an entity has more than a handful of customers, but the choice of tool is the entity's own, subject to it actually covering the entity's risk profile.

Having a subscription and having a correctly configured tool are different things. The most common gap PNPC finds when reviewing an existing screening tool is that it only checks at onboarding with no periodic re-screening scheduled, or that its thresholds were left at generic vendor defaults never calibrated to the entity's actual customer base and transaction sizes. A setup or reconfiguration engagement reviews what the tool is actually doing against what your written AML policy says it should be doing.

Sanctions and PEP screening checks a customer's or counterparty's identity against reference lists — the UN Consolidated Sanctions List, the UAE Local Terrorist List, and PEP databases — typically at onboarding and periodically thereafter, to confirm you are not dealing with a designated or high-risk individual. Transaction monitoring is a separate, ongoing function that watches the pattern of a customer's actual activity — transaction size, frequency, and structuring — against their expected profile, to flag behaviour inconsistent with what was expected at onboarding, regardless of whether the customer's identity screens clean.

At minimum, screening should run at onboarding and then on a periodic re-screening cycle thereafter, since sanctions and PEP designations change and a name that was clean at onboarding can be listed later. The appropriate cadence depends on the entity's risk assessment — higher-risk customer categories may warrant more frequent re-screening than lower-risk ones — but onboarding-only screening with no ongoing cycle is a recognised gap.

It depends on the entity's activity and risk profile rather than headcount alone. A corporate service provider with a modest customer base may reasonably rely on sanctions/PEP screening plus manual review of the limited transaction volume it actually sees, while a financial institution, exchange house, or high-volume DNFBP handling client funds typically needs configured transaction-monitoring rules because manual review of volume at that scale is not realistically consistent. PNPC scopes this based on the entity's documented risk assessment, not a fixed rule.

No. Screening and monitoring software generates alerts — potential matches or unusual patterns — but a human, typically the Compliance Officer or a delegated reviewer, must investigate each alert, determine whether it is a genuine match or a false positive, and record the disposition. Software flags; it does not decide. The investigation and documented decision are what a supervisory authority actually reviews.

False-positive volume is usually a calibration problem, not an inherent feature of screening software — overly broad name-matching thresholds, screening against irrelevant list categories, or monitoring rules set without reference to actual transaction sizes all inflate false positives. Proper calibration to the entity's real customer base and transaction profile, combined with periodic recalibration as volumes and patterns change, keeps the alert queue manageable enough that genuine reviews actually happen.

No. Screening and monitoring software identifies and helps investigate potential concerns, but the actual STR or SAR filing is submitted through the FIU's goAML platform by the entity's designated Compliance Officer, based on a human judgement that reasonable grounds for suspicion exist. PNPC configures the internal workflow so that a confirmed suspicious alert has a clear, documented path to goAML filing, but the filing decision and submission remain the Compliance Officer's responsibility.

At minimum, the UN Security Council Consolidated Sanctions List and the UAE Local Terrorist List. Depending on the entity's cross-border customer or transaction exposure, additional coverage of other major international sanctions regimes may form part of a properly risk-calibrated setup. The right combination depends on the entity's actual customer geography, not a fixed universal list.

PNPC advises on selection criteria — list-source coverage, screening cadence capability, monitoring rule flexibility, case-management and audit-trail functionality, and cost proportionate to the entity's volume — and can coordinate with vendors during implementation, but final vendor selection and contracting is the entity's own commercial decision. We are not a technology reseller and do not receive vendor commissions on any recommendation.

The written AML/CFT policy states, in narrative form, what screening and monitoring the entity performs, at what frequency, and how alerts are escalated. The software configuration is the technical implementation of that same narrative. When the two are built together, an inspector reviewing the policy document and then testing the actual system finds them consistent; when they are built separately — often because the policy was drafted by one adviser and the software configured independently, or years apart — the mismatch is a recurring and easily identified inspection finding.

Keep a configuration record describing which list sources are active, the screening cadence, the transaction-monitoring rules and thresholds applied and why, staff training records on the configured system, and a sample of alert investigation logs demonstrating the triage workflow in practice. This sits alongside, and should cross-reference, the broader AML risk assessment and policy documentation.

PNPC recommends an initial review at 60–90 days post-go-live to catch early miscalibration (excessive false positives or an unexpectedly quiet alert queue), followed by at least an annual review aligned with the broader AML/CFT risk assessment refresh, and an ad hoc review whenever there is a material change in transaction volume, customer mix, or applicable list-source guidance.

For a genuinely very small entity with a small, stable, low-risk customer base, a documented manual process can be defensible if it is actually followed consistently, evidenced, and re-run at an appropriate cadence — the law does not mandate software specifically. In practice, manual processes degrade quickly as volume grows or staff turn over, and the evidentiary burden of proving consistent manual checks were performed is harder to satisfy on inspection than a system-generated log.

PNPC's engagement is the advisory, selection-support, and configuration work — assessing needs, advising on vendor options, calibrating settings to the entity's risk profile, designing the alert-triage and goAML escalation workflow, and training staff. The software subscription itself is contracted directly between the entity and the chosen vendor; PNPC is not the software provider.

The core technology substance is the same — reliable screening, proportionate monitoring, a retrievable audit trail — but the documentation has to speak the right supervisor's language. A DIFC entity is supervised by the DFSA and an ADGM entity by the FSRA, each with its own AML rulebook layered on top of the federal AML/CFT Law, while a mainland or general-free-zone (JAFZA, DMCC, RAKEZ, IFZA, and similar) DNFBP is supervised by the Ministry of Economy under the same federal law. The configuration file's language and cross-referencing should track whichever rulebook actually governs the entity.

Generally yes. Beyond standard sanctions, PEP, and adverse-media screening of customers and beneficial owners, a VASP typically needs wallet-address and counterparty-VASP screening capability so that virtual-asset transfers are assessed for sanctions exposure and jurisdictional risk before they proceed, not just the identity of the account holder at onboarding.

Not necessarily, but it has to be planned rather than assumed. Most vendors allow export of historical screening and alert records, but the format, completeness, and ease of migrating that history into a new system's case-management module varies considerably by vendor. A migration undertaken without a data-continuity plan risks a visible gap in the audit trail exactly where an inspector might later ask to see it.

It can, depending on the vendor's licensing terms, but a shared subscription does not remove the need for each entity to have its own accountable alert-triage arrangement and its own documented configuration decisions. A group sharing a tool centrally still needs each UAE entity's Compliance Officer to retain real triage authority and a clear, entity-specific record of how alerts touching that entity were handled.

Investigate it, record the reasoning that distinguishes the customer from the listed match (date of birth, nationality, additional identifiers), and log the disposition as cleared with the supporting rationale — the same as any genuine hit. A false positive that is dismissed without a documented investigation trail looks, on inspection, identical to a hit that was never reviewed at all.

Integration is not a legal requirement — a standalone screening and monitoring tool with its own case-management module can satisfy the underlying obligations on its own. Where it is available and affordable, integration with a CRM or accounting platform reduces manual re-entry and the risk that a customer added in one system is never mirrored into the screening tool, but a well-run standalone process is a legitimate and common setup, particularly for smaller entities.

The risk assessment should exist, at least in substantially complete draft form, before final calibration of screening cadence and monitoring thresholds, because those settings are supposed to reflect the risk assessment's conclusions rather than the other way around. Requirements-gathering and vendor selection can reasonably run in parallel with the final stages of the risk assessment, but the calibration step itself should follow, not precede, a settled risk methodology.

It can be, particularly where PEP reference databases match on name similarity rather than a full identity profile, and a common surname within a limited PEP-relevant population generates a high raw match rate. This is a calibration and disambiguation issue — refining the matching logic and adding secondary identifiers (nationality, date of birth, known role) to the review process reduces the noise without weakening genuine PEP detection.

It depends on the entity's actual activity and risk profile rather than volume alone — a lower-volume DNFBP with straightforward, low-risk transactions may reasonably rely on sanctions/PEP screening plus manual review of the limited activity it sees, while an entity handling client funds, cash-intensive transactions, or cross-border payments may need configured monitoring even at modest volumes because the risk profile, not the headcount, is what drives the requirement.

The screening tool's own system logs — timestamped records of each screening run, the list sources checked, and the outcome — are the evidence. A configuration setting showing re-screening is scheduled is not, on its own, proof it executed; the run log for the relevant period is what an inspector actually wants to see.

Mechanically, most vendors provide a setup manual that a reasonably technical staff member can follow to switch settings on. What that manual does not provide is the calibration decisions — which list sources your specific exposure actually requires, what re-screening cadence your risk tiers justify, what thresholds fit your real transaction sizes — which come from the entity's own risk assessment and policy, not the vendor's documentation.

Generally no, directly — Corporate Tax under Federal Decree-Law No. 47 of 2022 and AML/CFT under Federal Decree-Law No. 20 of 2018 are separate regimes administered by different authorities (the Federal Tax Authority and the Ministry of Economy/Central Bank/FIU respectively), and an FTA audit does not typically examine AML screening configuration. Where an entity's underlying transaction records are relevant to both a tax audit and an AML review, keeping consistent, well-organised records across both functions avoids inconsistencies surfacing awkwardly if both are ever reviewed close together.

No. UAE AML/CFT law is technology-neutral and does not maintain an approved-vendor list or certify specific screening products. The obligation is that screening, monitoring, and record-keeping actually happen at an appropriate standard — the entity chooses the tool that achieves that, subject to it genuinely covering the entity's risk profile.

Yes, where that single transaction is itself a specified activity that brings CDD and screening obligations into play — for example, a one-off high-value real estate transaction or precious-metals sale above the relevant threshold. The screening obligation attaches to the transaction and the customer's identity at that point, not to whether the relationship continues afterward.

Yes. Even where the underlying policy and risk methodology remain the same, a new tool typically changes the screen layout, the alert workflow, and how staff record a disposition — all of which affect how consistently and correctly the policy is actually executed day to day. Training on the system as configured, not just the policy in the abstract, is what makes the two line up in practice.

Inconsistent disposition of similar alerts is itself a recognised inspection finding — it suggests the triage workflow is not genuinely following a documented standard but instead depends on whoever happens to review a given alert. A defined triage procedure, with clear criteria for what counts as cleared versus escalated, reduces this variation and gives the entity a consistent, defensible standard to point to.

For a properly risk-calibrated setup, adverse-media and sanctions/PEP screening should extend to the beneficial owners and, for higher-risk relationships, key directors and controllers of a corporate customer — not just the corporate entity's registered name. Screening only the company name while ignoring the individuals who actually control it misses exactly the risk the underlying due-diligence obligation is designed to catch.

No, they are unrelated obligations. Economic Substance Regulations notification and reporting was discontinued for financial years starting on or after 1 June 2023 under Cabinet Decision No. 98 of 2024, and Corporate Tax record-keeping under Federal Decree-Law No. 47 of 2022 is a separate FTA-administered requirement covering financial and tax records. AML screening software addresses sanctions, PEP, and transaction-monitoring obligations under the AML/CFT Law specifically and does not substitute for either.

Confirm the current list-source coverage and whether it matches the combined entity's actual exposure, the screening cadence actually configured (not just what the vendor's default settings claim), the history of alerts and how they were dispositioned, and whether the Compliance Officer registered on the tool is still the correct, active individual post-acquisition. An inherited configuration built for a different risk profile is a common source of undetected gaps after a deal closes.

Plan the migration to a new tool before support actually ends, with a clear timeline for data continuity and staff retraining, so there is no gap in screening or monitoring coverage during the changeover. Continuing to run an unsupported tool past its discontinuation risks stale list sources and unpatched issues that a supported product would not have.

There is no fixed formula — calibration is a risk-based judgement that should err toward catching genuine risk while keeping the alert queue manageable enough that staff can genuinely review every alert rather than clearing them in bulk out of volume fatigue. A threshold set purely to minimise false positives risks missing genuine anomalies; one set purely to maximise sensitivity risks an unmanageable queue that degrades review quality across the board.

No — these are Ministry of Economy-supervised free zones for AML/CFT purposes, not separate financial-services free zones with their own AML rulebook the way DIFC and ADGM are. A DNFBP licensed in JAFZA or DMCC sits under the same federal AML/CFT Law and the same Ministry of Economy supervision as a mainland entity, so its screening and monitoring configuration expectations track the mainland approach rather than a free-zone-specific variant.

The configuration itself does not need to change on a Compliance Officer transition, but the tool's administrator access, alert-notification routing, and any named-owner fields in the triage workflow do need to be updated promptly so the new Compliance Officer has genuine, active control of the system rather than a predecessor's access lingering unused or, worse, still receiving alerts nobody is monitoring.