Most compliance teams invest months in evaluating AML platforms and days in planning the deployment that follows. McKinsey and Oxford research across more than 5,400 large IT projects found that half blow their budgets and the average project runs 7% over schedule. In AML compliance, a delayed go-live carries a consequence that a delayed ERP rollout does not, because a system still in configuration provides no live AML coverage that regulators can point to.
A well-run implementation moves through multiple phases:
- The pre-integration work that determines if the project goes live on time
- The configuration and testing (usually separate phases) that determine how well it performs
- The post-launch calibration that maintains the right performance
Compressing or misconfiguring any one of them extends the timeline and creates compliance exposure that outlasts the project.
This guide gives compliance teams a phase-by-phase picture of what a realistic AML implementation timeline requires, so they can plan against an honest timeline rather than a vendor estimate.
Key takeaways:
- Vendor timelines cover only part of the implementation
Most go-live quotes reflect the integration phase alone, leaving out data preparation before it and post-launch calibration after it.
- Customer data quality is the most common source of delay
Incomplete or inconsistent customer records prevent configuration from proceeding, adding weeks before a single alert threshold can be set.
- Configuration decisions made during integration have long operational consequences
Thresholds, screening scope, and routing logic set to vendor defaults reliably generate alert volume problems in the first weeks after launch.
- A parallel running period is the difference between documented and undocumented transitions
Skipping it trades short-term speed for missing evidence that regulators in both the US and Europe now expect to see.
- Sigma360 is built to reduce the coverage risk that extended AML deployments create
With no-code configuration and go-live in as little as two weeks, Sigma360 shortens the distance between signing and a fully operational, audit-ready program.
The four phases of the AML implementation timeline
The implementation process follows a consistent sequence regardless of platform or deployment model. Each phase has a realistic duration range and a specific variable that most often extends it.
Phase 1: Pre-implementation preparation (2–4 weeks)
Pre-implementation preparation is the phase that vendor estimates typically leave out.
By the time a vendor is engaged and a project plan is signed, the work that determines if the project stays on schedule has often not started: Customer data is unaudited, stakeholders are unaligned, and the security review that will gate the integration has not been scheduled.
Three workstreams need to be completed before any technical work begins:
- Data readiness audit: AML platforms screen against customer records. If those records are missing date-of-birth fields, have inconsistent name formats, or lack registered entity identifiers for corporate customers, the configuration phase will reveal those problems at the worst possible time.
- Stakeholder alignment: Compliance, IT, legal, data governance, and the CISO function all need to be engaged before integration begins. Decisions about alert routing, data access, and configuration scope require sign-off from each group, and delays in alignment consistently push phase transitions back.
- Security review initiation: Institutions with formal third-party risk programs require vendors to complete a security assessment before integration can begin. Initiating this at contract signature keeps it off the critical path, as security reviews can add two to four weeks when started late.
Phase 2: Integration and configuration (3–6 weeks)
Vendors quote go-live estimates based on this phase alone. A cloud-based, API-first deployment with clean customer data and a documented risk appetite can move through integration in three weeks.
An institution migrating from a legacy on-premises system with multiple data sources and complex entity structures may take six weeks or more once rule tuning is factored in.
Match thresholds, screening scope, and alert routing logic need to reflect the institution’s own risk profile before go-live. Fixing misconfigured settings after launch is harder, slower, and more disruptive than getting them right during setup, and accepting vendor defaults is one of the most common sources of high false positive volumes in the first weeks after launch.
AML investigations workflows, sanctions and watchlist screening parameters, and adverse media screening filters each carry different risk tolerances and require separate configuration decisions.
Institutions that treat them as a single block consistently underestimate the tuning work that follows.
Phase 3: Testing and parallel running (2–4 weeks)
No AML system should go live without a parallel running period. This is the window during which the new platform and the existing system operate simultaneously, allowing alert outputs to be compared, match logic to be validated, and documentation to be confirmed before the old system is decommissioned.
Running both systems in parallel and documenting the comparison produces the testing evidence that validates the new platform before existing controls are retired. Institutions that skip this phase to accelerate go-live trade a few weeks now for missing documentation that might take much longer to reconstruct later.
Testing should include a representative sample of high-risk entities, known sanctions names, and historical adverse media cases to confirm the platform catches what legacy systems caught.
Issues surfaced during testing are expected and manageable, while the same issues surfaced after go-live become operational findings.
Phase 4: Go-live and post-launch calibration (ongoing)
Go-live marks the transition to the new system, not the end of the implementation. Alert volumes run higher than steady-state in the first 60 to 90 days as the system processes the full customer portfolio. Match thresholds that looked correct in testing often generate unexpected alert distributions at full volume.
False positive rates should be tracked from day one and reviewed against benchmarks at 30, 60, and 90 days. Perpetual KYC monitoring workflows often require threshold adjustments as the platform ingests live data and the institution’s actual risk profile becomes clear.
Quarterly data tuning sessions keep the program accurate, recalibrating alert logic, updating screening scope, and addressing data quality issues that emerge in production.
Deployment model comparison
Three deployment models cover most implementations, each with a different timeline and a different point where delays tend to occur.
| Deployment model | Typical timeline | Primary integration requirement | Where delays occur | Best for |
| API-first | 2–4 weeks | Developer resource and API documentation | Customer data format alignment | Fintechs, payments firms, embedded compliance workflows |
| UI / platform | 4–8 weeks | Data migration, user provisioning, configuration | Legacy data migration, CISO review | Banks, regulated corporates with large customer portfolios |
| Hybrid (API + platform) | 6–12 weeks | Both API integration and platform configuration | Stakeholder alignment, parallel scope management | Tier 1 institutions, multi-jurisdiction deployments |
API-first deployments are faster because they inherit the institution’s existing data architecture instead of requiring migration into a new environment.
Speed depends on what the institution brings to the integration, primarily clean, structured entity data and available development resources. Institutions with legacy data issues often find that API-first deployments expose those issues faster than platform deployments, which makes the pre-implementation data audit more consequential, not less.
What causes AML implementations to run long
Most implementation delays share a small set of causes. The following factors most commonly extend implementations past their initial estimates:
- Customer data quality issues surfaced mid-integration: Name-only records without secondary identifiers, duplicate entity entries across systems, and inconsistent transliteration of non-Latin script names each require remediation that cannot happen in parallel with configuration.
- CISO and security review cycles: Vendor security assessments for institutions with formal third-party risk programs take time that is avoidable when the review is initiated at contract signature, before the project plan is locked.
- Alert threshold misconfiguration requiring re-tuning: Default settings accepted at configuration produce alert volumes that cannot be managed without live re-tuning, adding weeks to the post-launch period that most project plans do not anticipate.
- Scope expansion during integration: Additional modules, geographies, or customer segments added after integration begins extend both the configuration phase and the testing window.
- Insufficient internal project resources: Implementations that rely on part-time internal contributors consistently miss phase transitions. A named internal project owner and dedicated compliance and IT resource are staffing requirements, not scheduling preferences.
- Legacy system decommission timing: Institutions that decommission their legacy system at go-live without maintaining a parallel running period risk leaving their AML program without continuous coverage.
Read more: How AI Cuts AML Delays and Regulatory Risk
What regulators expect to see from your implementation
Examiners expect to see documented evidence that your platform was properly configured, validated before going live, and grounded in the institution’s own risk assessment. Without that evidence, a well-functioning system and a poorly functioning one look identical on paper.
In the US, FinCEN’s proposed AML/CFT program rule, along with parallel proposals from the OCC, FDIC, NCUA, and a separate Federal Reserve’s corresponding proposal, requires programs to be effective and reasonably designed.
Institutions must be able to demonstrate that their program works. An implementation that cannot produce testing records, configuration rationale, or a parallel-running comparison does not meet that standard regardless of how well the live system performs.
The FFIEC BSA/AML Examination Manual provides examiners with procedures for assessing those records.
For institutions with European operations, AMLA’s supervisory framework sets expectations for auditability and documented decision logic in automated screening systems. Each screening decision must be reproducible from the underlying evidence, which means audit trail configuration must be validated during testing and confirmed before the system goes live.
Implementation documentation (testing records, configuration decisions, parallel-running comparisons, and sign-off trails) is a regulatory deliverable in both frameworks. The institutions that produce it under examination pressure are the ones that did not treat it as a project management artifact.
How Sigma360 reduces AML implementation risk
For the compliance teams Sigma360 serves (Tier 1 banks, global financial institutions, fintechs, payments firms, asset managers, and regulated corporates), a platform that takes six months to deploy creates six months of coverage risk.
Sigma360’s risk intelligence platform is built for deployment without extended engineering cycles. Clients can go live in as little as two weeks depending on integration path and data readiness, with threshold and screening scope decisions made directly by compliance staff through no-code configuration.
The implementation model extends past go-live. Dedicated onboarding support, data tuning at launch, and structured quarterly data reviews carry the calibration work into live operations, covering the post-launch phase that standard vendor engagements rarely include.
When a leading identity verification provider needed to launch a white-labeled KYC solution, Sigma360’s integration approach allowed them to go live in weeks without disrupting existing workflows or requiring additional engineering resources.
To discuss an AML implementation or assess how long a transition to a modern financial crime compliance framework will realistically take, speak with a Sigma360 risk intelligence specialist.
Read more: The Sigma360 Customer Experience
FAQ
Who owns an AML implementation internally?
Compliance owns the program requirements, IT owns the technical integration, and data governance owns the customer data that determines whether configuration can proceed. Without a named project lead coordinating all three, phase transitions consistently slip.
How do you know when an AML implementation has been successful?
A completed implementation produces calibrated alert thresholds, documented configuration rationale, a parallel-running comparison, and a false positive rate trending toward steady-state within 60 to 90 days. Alert volumes still rising at the three-month mark indicate the configuration phase was not finished.
Can you implement new AML software during a regulatory examination?
Yes, but institutions should inform their examiner of a planned platform change and document the transition more thoroughly than under normal conditions. Examiners will want to see the parallel-running approach and evidence that continuous coverage was maintained throughout.
What should you ask a vendor about implementation support?
Ask who the named implementation contact is, what the handoff to ongoing support looks like, and whether the contract includes post-launch threshold tuning. Vendors who hand off to a generic support queue at go-live leave alert calibration to the client team.
