Why Four Out of Five AML Implementations Fail the First SAMA Review (and What We Changed)
Across twelve remediation engagements with Saudi banks, payment service providers and finance companies, a consistent pattern emerges: institutions purchase capable AML technology, complete vendor implementation projects on schedule, and then discover during the first SAMA review that their controls do not meet regulatory expectations. The SAMA AML implementation common failures are rarely about software capability—they stem from a mismatch between vendor-led configuration and the risk-based, evidence-driven approach that SAMA AML/CTF rules demand.
This article describes the recurring gaps observed across these engagements, the regulatory expectations that institutions misunderstand, and the implementation sequence that produces defensible controls from the outset.
The Vendor Implementation Trap
Most AML technology projects follow a vendor-led path: the institution selects a platform, the vendor's implementation team arrives, and configuration begins according to the vendor's standard methodology. That methodology is designed to demonstrate software features, not to satisfy a specific regulator's risk-based requirements.
The result is a system that screens, scores and monitors transactions, but lacks the underlying logic, audit trails and governance documentation that SAMA expects. When the first regulatory review occurs—whether a thematic inspection, a full AML examination, or a follow-up to a suspicious activity report—the institution discovers that it cannot explain *why* a customer received a particular risk score, *how* a sanctions alert was resolved, or *what evidence* supported the decision to close a case without filing a report.
These are not minor documentation issues. They represent fundamental gaps in the control framework, and they trigger findings that require months of remediation work.
Recurring Gap One: Customer Risk Scoring Without Clear Logic
SAMA's AML/CTF rules require institutions to apply a risk-based approach to customer due diligence. That means assigning each customer a risk rating and tailoring ongoing monitoring to that rating. Most AML platforms include a customer risk scoring engine, and most vendor implementations configure it using the vendor's standard risk factors and weightings.
The recurring problem: institutions cannot articulate why those factors and weightings are appropriate for their specific customer base, product mix and geographic exposure. The risk model exists, but the rationale does not.
In one remediation engagement with a retail bank, the customer risk model assigned identical scores to a high-net-worth individual conducting frequent international wire transfers and a salaried employee with a single savings account. The model included factors for occupation, transaction volume and geographic risk, but the weightings had been copied from the vendor's template without adjustment for the institution's actual risk profile. When asked during a SAMA review why these two customers carried the same rating, the compliance team had no documented answer.
The gap is not the absence of a model—it is the absence of a documented, institution-specific risk assessment that justifies the model's design. SAMA expects to see evidence that the institution has considered its own risk environment and calibrated its scoring logic accordingly.
Recurring Gap Two: Sanctions Screening Without Complete Audit Trails
Sanctions screening is a binary control: either a name matches a listed individual or entity, or it does not. Yet the operational reality is more complex. Screening engines generate alerts based on partial name matches, phonetic similarities and transliteration variations. Compliance analysts must review each alert, gather additional information, and decide whether the match is genuine or a false positive.
SAMA and the FATF expect institutions to maintain a complete record of this decision-making process. That means capturing not only the alert and the final disposition, but also the information reviewed, the reasoning applied, and the identity of the analyst who made the decision.
Across multiple remediation engagements, the same pattern appears: the AML platform records that an alert was closed, but does not capture *why*. The analyst may have reviewed the customer's identification documents, compared the date of birth, or confirmed that the customer's nationality differed from the listed individual's—but none of that evidence was recorded in the system. When SAMA reviews a sample of closed alerts, the institution cannot reconstruct the basis for the decisions.
This gap often arises because the vendor's standard workflow does not enforce documentation at the point of decision. The platform allows an analyst to close an alert with a single click, without requiring a narrative explanation or attachment of supporting evidence. The institution assumes that the workflow is compliant because the vendor delivered it, but the workflow was designed for operational efficiency, not regulatory defensibility.
Recurring Gap Three: Weak Case-Closure Evidence
Transaction monitoring engines generate alerts when activity deviates from expected patterns. Analysts investigate those alerts, gather information from the customer or from internal records, and decide whether the activity is suspicious. If the activity has a legitimate explanation, the case is closed. If it cannot be explained, the institution files a suspicious activity report with the Saudi Financial Intelligence Unit.
SAMA expects the institution to document the investigation and the rationale for the decision. That documentation must be sufficient for a regulator—or an auditor, or a future analyst—to understand what was done and why.
In remediation engagements across retail banks, money service businesses and finance companies, the same weakness recurs: case files contain minimal narrative and little supporting evidence. An alert for unusual cash deposits might be closed with a one-line note—"Customer confirmed business income"—without any record of how that confirmation was obtained, what questions were asked, or what documents were reviewed.
This gap reflects a misunderstanding of the standard of evidence that SAMA requires. Institutions often treat case management as an operational queue—alerts come in, analysts clear them, and the focus is on reducing backlog. But SAMA treats each case as a test of the institution's ability to identify and escalate financial crime risk. A case file that cannot demonstrate reasonable inquiry and sound judgment is a control failure, regardless of whether the underlying activity was in fact suspicious.
The Implementation Sequence That Works
The common thread across these gaps is that they arise from configuration decisions made without reference to regulatory expectations. The remedy is not better software—it is a different implementation sequence, one that begins with regulatory requirements and uses those requirements to drive vendor configuration.
That sequence has four stages. Requirements across screening, monitoring and case management are defined first, before vendor selection. Those requirements specify not only what the system must do, but also what evidence it must capture and what governance documentation it must support. They are derived from SAMA AML/CTF rules, FATF Recommendations, and the institution's own risk assessment.
Next, vendor evaluation with proof of concept tests whether candidate platforms can meet those requirements. The evaluation is scored and documented, so the institution can demonstrate that its selection was deliberate and risk-informed.
Once a vendor is selected, data integration, scenarios and risk models are configured according to the requirements specification, not the vendor's template. Customer risk scoring logic is designed to reflect the institution's risk profile. Transaction monitoring scenarios are calibrated using the institution's transaction data. Sanctions screening workflows enforce the capture of decision-making evidence.
Finally, pre-go-live validation and model governance confirm that the configured system operates as intended and that the institution can explain and defend every material design choice. The validation report and governance pack become the institution's evidence that its AML controls are fit for purpose.
This sequence takes longer than a vendor-led implementation—typically four to nine months for the full project—but it produces controls that survive regulatory scrutiny from day one.
Who Implements the Software
A recurring question from institutions considering this approach: does the consultancy implement the software itself, or does the vendor retain that role?
The vendor implements. The consultancy defines requirements, oversees the vendor's work, and validates the result on the institution's behalf. This division of responsibility provides independent assurance that the configured system meets regulatory expectations, without creating a dependency on the consultancy for ongoing operation or support.
The Cost of Remediation Versus the Cost of Doing It Right
Remediation engagements begin after a regulatory finding. The institution must redesign its risk models, rebuild its workflows, re-document its governance, and often re-investigate a sample of past cases to demonstrate that the revised controls would have produced sound decisions. That work occurs under regulatory scrutiny, with deadlines imposed by SAMA and reputational risk that extends beyond the compliance function.
Institutions that invest in a requirements-driven implementation avoid that cycle. They may spend more time in the design and validation stages, but they go live with controls that are defensible, auditable and aligned with SAMA's expectations. When the first regulatory review occurs, the institution can produce the evidence that SAMA requires, because that evidence was built into the system from the beginning.
Moving Forward
If your institution is planning an AML technology implementation, or if you are operating a system that has not yet been tested by a SAMA review, the question to ask is not whether your platform has the right features—it is whether your implementation can produce the evidence that SAMA expects.
CISO Consulting delivers vendor-independent selection and implementation of AML technology, covering customer risk scoring, sanctions screening, transaction monitoring and case management. The process includes requirements specification, vendor evaluation with proof of concept, configuration oversight, and pre-go-live validation. Deliverables include a requirements specification, vendor evaluation report and recommendation, scenario and model design documents, and a validation report and governance pack.
For institutions seeking an independent assessment of an existing AML program, or requiring design or review of sanctions compliance controls, those services are also available.
Contact us to discuss your AML implementation or remediation requirements.
