Most UAE banks, exchange houses, and DNFBPs that have purchased a global compliance platform in the past decade share a recognisable pattern in their post-implementation experience. The platform was selected through a competitive procurement, evaluated against feature matrices that looked comprehensive, and procured with implementation services that promised UAE configuration. After go-live, the same gap surfaces consistently: the platform does the generic 80% of the AML and screening workload reasonably well, and the remaining 20% (the part that is UAE-specific) requires custom build work that was either underestimated, scoped out of the original engagement, or quietly handled through manual workarounds that accumulate over time.
This piece is a perspective on why that gap exists, where it shows up most consistently in the UAE market, and what the custom build work actually involves when done properly. The argument is opinionated. We are not arguing that global compliance platforms are wrong for the UAE; many of them are excellent products and the right starting point for a serious AML programme. We are arguing that the custom work between the global platform and the UAE regulatory reality is real, predictable, and consistently underestimated in original procurement scoping. Forensic accounting and compliance advisory teams running implementations and post-implementation programmes encounter the same custom work shapes engagement after engagement, and the build partner who can deliver that work efficiently is a meaningful enabler of the overall programme.
The audience for this analysis is two-sided. Forensic accounting and compliance partners running AML implementation, remediation, or supervisory response engagements at UAE banks, exchange houses, and DNFBPs - who routinely need build capacity to close the gap between platform capability and UAE requirement. And technology leaders inside UAE financial institutions who have lived through the gap personally and want a clearer view of what the custom work actually is. The most useful diagnostic question for both audiences is the same: of the seven custom work areas this piece describes, how many have been formally addressed, how many are being handled through workarounds, and how many are simply unscoped.
The Seven UAE Custom Work Areas
Below is a representation of the seven recurring areas where global AML and compliance platforms consistently require UAE-specific custom build work. The point is not that any single platform is weak across all seven, or that any UAE deployment encounters all seven equally; the actual gap profile varies by platform and customer base. The point is that these seven areas show up across the UAE market with enough consistency that a forensic or compliance engagement scoping a platform implementation should price for them explicitly rather than treating them as configuration. Tap any area to see what global platforms typically ship, what the UAE market actually requires, and what the custom build work involves.
Seven recurring custom work areas in UAE AML platform deployments
Tap any area to see the platform default, the UAE requirement, and the typical custom build
Why the Gap Is Structural, Not Vendor-Specific
The recurring custom work pattern is not the fault of any specific platform vendor. It reflects the structural reality of how global compliance platforms are built and how the UAE regulatory environment differs from the markets the platforms were primarily designed for. Three structural dynamics produce the gap consistently.
The first is product economics. Global compliance platforms serve customer bases across dozens of jurisdictions. The product roadmap allocates engineering effort to features that benefit the largest share of the customer base, which means UAE-specific capabilities (Arabic name matching, goAML integration, free zone regimes, VARA, DNFBP and exchange house workflows) compete for engineering attention against features that benefit larger customer bases elsewhere. The platform vendors are commercially rational; the consequence for UAE customers is that platform-native depth on UAE specifics tends to lag the local regulatory reality.
The second is regulatory specificity. The UAE regulatory environment has a distinctive shape that is not just "general AML rules with UAE branding." goAML as the primary reporting infrastructure, the joint guidelines from CBUAE/SCA/DFSA/FSRA, the parallel free zone regimes (DFSA, FSRA), the recent VARA framework, the DNFBP supervision focus, the local sanctions and terrorist lists, and the inspection-driven supervisory style all combine to produce regulatory specifics that platforms designed for other primary markets handle awkwardly. The specifics are not optional in the UAE deployment; they are the regulated reality.
The third is the recency and ongoing evolution of UAE compliance regimes. UAE financial crime regulation has matured rapidly over the past several years, with material framework updates, expansion of supervised entities, additional reporting requirements, and new sectoral regimes (most visibly virtual assets) becoming material in the past 24-36 months. Platforms that captured the regulatory state two years ago are not capturing the current state; the gap that custom work has to fill is moving rather than fixed.
The shift in one observation
The custom work between a global compliance platform and the UAE regulatory reality is not a bug in any specific platform; it is a structural feature of operating compliance technology in this market. The advisory firms running AML and forensic engagements that build durable client relationships are increasingly those who scope the custom work explicitly upfront rather than treating it as something the platform vendor will handle. The build partner who delivers that custom work is the leverage point for the engagement.
Where the Gap Costs Most Acutely
The structural gap matters because the cost of operating compliance technology with unfilled gaps has risen materially in the UAE over the past several years. Four cost categories show up consistently for institutions whose platform deployments have been treated as configuration rather than as configuration plus custom build.
Supervisory findings
CBUAE and free zone regulator inspection cycles have tightened materially. Findings related to AML programme effectiveness, screening adequacy, and reporting timeliness accumulate at institutions whose platforms do not handle UAE specifics natively. The findings record itself becomes an institutional reputation issue and can affect the supervisory posture for future cycles.
Operational manual workload
Gaps that are not closed through custom build are typically closed through manual workarounds: name screening exceptions handled in spreadsheets, goAML reports assembled by hand, free zone entities monitored on parallel processes, exchange house and DNFBP segments reviewed offline. The manual load grows as the customer base grows, and at some point becomes more expensive than the original platform.
Programme effectiveness
Compliance programmes assessed against effectiveness metrics (false positive rates, alert investigation cycle times, suspicious activity escalation timeliness) under-perform on UAE-specific dimensions when the platform is not tuned to them. Institutions invest in compliance teams that spend disproportionate effort on workarounds rather than on actual investigation work.
Audit and evidence chain
Inspection-ready evidence is harder to produce when the data sits across the platform plus multiple workaround systems. Audit trail reconstruction becomes a forensic exercise in itself, which is time the institution would rather spend on actual compliance work. Cross-referencing the platform with the workaround systems is where institutions are typically most exposed during inspection cycles.
The Numbers
Two Implementation Postures, Two Cost Trajectories
The structural alternative to absorbing the custom work through manual processes is to scope the custom build explicitly during platform implementation, with a build partner brought in alongside the advisory firm and the platform vendor. The model produces materially different cost trajectories over the life of the platform.
| Dimension | Configuration-only implementation | Configuration plus scoped custom build |
|---|---|---|
| Original implementation cost | Platform licence plus configuration services. UAE custom areas treated as out of scope or "to be addressed later." | Platform licence plus configuration plus explicit custom build for the UAE-specific areas. Higher upfront cost. |
| Year 1 operational state | Platform live for the generic 80% of workload. UAE-specific areas handled through manual workarounds or partial coverage. | Platform live with UAE-specific custom layers integrated. Operational coverage broadly aligned with regulatory requirement. |
| Manual workload trajectory | Manual workarounds grow with customer base growth. By year 3, often a substantial parallel operation alongside the platform. | Manual workload contained to genuinely manual review work rather than platform gap-filling. Growth tracks customer base, not exception handling. |
| Supervisory exposure | Inspection findings related to UAE specifics accumulate. Remediation projects often follow inspection cycles. | UAE-specific inspection findings substantially reduced. Remediation effort focused on genuine programme issues rather than platform gaps. |
| Total cost over 3-5 years | Lower upfront; higher operational and remediation cost. Frequently culminates in a major remediation programme. | Higher upfront; substantially lower operational and remediation cost. Total cost typically lower over the platform lifecycle. |
The custom work between a global compliance platform and the UAE regulatory reality is real, predictable, and where forensic and compliance engagements either compound into durable systems or quietly leak engagement margin into integration debt. The question is not whether the work happens; it is whether it happens upfront with proper engineering or in arrears through manual workarounds and remediation programmes.
How This Integrates with Forensic and Compliance Advisory Work
The model that produces durable AML platform deployments in the UAE - where the advisory engagement compounds into ongoing client trust rather than running into post-implementation friction - is increasingly recognisable. Forensic and compliance advisory firms hold the strategic and regulatory engagement: AML programme design, supervisory response, regulatory interpretation, governance, and the long-term advisory relationship. Software build partners hold the technical custom work alongside the platform vendor: the Arabic name matching layer, the goAML integration, the free zone multi-regime configuration, the VARA modules, and the inspection-ready evidence chains. The two work in parallel during implementation so that the platform delivered to the institution covers UAE specifics from day one, rather than requiring a remediation programme 18 months later.
This is the model BY BANKS is positioned for. We are a UAE-based software engineering team, not a forensic firm and not a compliance advisor. We do not hold regulatory advisory accreditation or licensed compliance positions. The advisory firm leads on regulatory interpretation, programme design, and the client's compliance posture. We deliver the software work that translates the advisory direction into operational platform capability. The configuration produces compliance technology engagements where the build component is delivered with UAE-specific depth without competing for the regulatory advisory relationship.
Where Structural Visibility Actually Helps
The conversations where this analysis is most useful are at three moments: a forensic or compliance advisory firm scoping a platform implementation engagement and wanting to price the custom build properly; a financial institution reviewing the gap between their existing platform and their actual regulatory requirement; or a transformation director with multiple compliance technology programmes who has seen the same custom work patterns repeat across deployments. The honest analysis usually points to the same conclusion: the UAE custom work is structural, the seven areas described here capture most of it, and the engagement model that produces durable outcomes brings build capacity into the implementation rather than treating it as configuration.
For broader related work, see our CBUAE regulatory reporting and AML/CFT platform capabilities, our perspective on specialist engineering partners in UAE advisory engagements, and our perspective on how discovery has become a sales phase. The applied work sits across our banking software, operational platforms, and technical consultancy capabilities. Get in touch if a 45-minute conversation about a specific platform implementation or remediation programme would be useful.
Frequently Asked Questions
No, and this matters for how engagements are structured. We are a UAE-based software engineering team. We design and build software systems, integrations, and platform extensions. We do not hold compliance advisory licences, AML accreditations, or regulated financial services authorisations. On any compliance technology engagement, the regulatory advisory firm holds the regulated relationship, makes the regulatory determinations, and carries the compliance responsibility. We deliver the software work that the advisory firm and the institution have determined is needed. The configuration is the same one we operate across non-compliance engagements: the regulated party leads, we build to their direction.
No. Many global compliance platforms are excellent products and represent the right starting point for a serious AML programme in the UAE. The argument we are making is narrower: that the gap between the global platform's out-of-the-box capability and the UAE regulatory reality is real and predictable, and that pricing implementations as configuration alone systematically underestimates the work required. The platform choice is a separate decision; the custom work is needed across most of the major global platforms and is part of the cost of operating compliance technology in this market.
The platform vendor's professional services typically lead on platform configuration, native module deployment, and the platform-side of integrations. The build partner handles the custom layers between the platform and the UAE-specific operational reality - the Arabic name matching layer, the goAML reporting integration, the multi-regime configuration for free zones, the VARA-specific modules, and similar work. The boundary is usually clear in practice: anything in the platform's native capability is the vendor's; anything that bridges between the platform and a UAE-specific requirement that the platform does not handle natively is the build partner's. The advisory firm coordinates between the two and ensures the regulatory direction is consistent across both pieces of work.
Sometimes, depending on the institution's internal capability. Larger institutions with mature in-house engineering organisations sometimes deliver this work internally with good results. The patterns where external build partners typically add value are: when the internal team is configured for run-the-bank operations rather than build-and-extend work; when the implementation timeline is compressed and the internal team cannot allocate sufficient capacity without disrupting other priorities; when specific specialist skills (Arabic name matching, goAML integration patterns, multi-regime regulatory configuration) are not resident in the internal team; or when the engagement is a remediation following findings and the institution wants the implementation work to happen alongside ongoing operations rather than competing with them. The choice is institution-specific. The work itself is the same regardless of who delivers it.
The principle holds; the regulatory specifics differ. DFSA and FSRA operate independent frameworks with their own AML, screening, and reporting regimes. Institutions in DIFC or ADGM face their own version of the platform-to-regulator gap, and global compliance platforms typically have the same shape of issue (configurable for DIFC or ADGM as locations, less mature on the regulatory framework specifics). The custom work areas are similar in shape but tuned to DFSA or FSRA rather than CBUAE. Institutions with activity across CBUAE-supervised onshore operations and DIFC or ADGM activity face the multi-regime version of the problem, where the platform needs to handle parallel regulatory frameworks correctly rather than treating them as variations of the same regime. The build work for this multi-regime configuration is one of the more substantial UAE-specific custom areas.
Global compliance platforms serve UAE financial institutions reasonably well on the generic 80% of AML and screening workload, and predictably under-serve the UAE-specific 20% that determines whether the programme actually meets local regulatory expectations. The custom work between platform and reality is structural rather than vendor-specific, the seven areas described here capture most of it, and the engagement model that produces durable outcomes prices the custom build into the original implementation rather than absorbing it through manual workarounds that accumulate into a remediation programme later. The advisory firms whose AML implementation engagements compound into long-term client trust are increasingly those who scope this custom work properly upfront and bring in build capacity to deliver it alongside the platform vendor's professional services, rather than treating compliance technology as a configuration exercise.
References to compliance and AML platforms, advisory firms, and UAE regulatory frameworks (CBUAE, SCA, DFSA, FSRA, VARA, the UAE FIU goAML system, the Joint Guidelines for Financial Institutions Adopting Enabling Technologies, and related frameworks) are descriptive of publicly available regulatory frameworks and may evolve. Patterns and observations in this article reflect our perspective on how UAE AML platform deployments typically encounter UAE-specific custom work. BY BANKS is a software engineering service provider; we are not a regulated compliance vendor, AML advisor, or licensed financial services firm, and we do not provide compliance advisory or regulatory determinations. On any compliance technology engagement we work on, the regulatory advisory firm and the financial institution hold the compliance responsibility, the regulatory determinations, and the supervisory relationship. Public sources used in this piece are listed on our Sources and Data page.
Ready to Build Something?
If this resonated, let's talk about how we can apply these ideas to your business.
Start a Conversation