Implementation
From discovery to a controlled go-live, with the gates written down
An AML implementation is not a software installation with a training day attached. It is a sequence of acceptances — infrastructure, security, compliance configuration, integration, user acceptance and operations — each of which produces evidence the institution will be asked for later.
The fourteen-week shape below is the plan we work to, not a promise. Three things move it and none of them are engineering: the lead time on an independent penetration test, when the authoritative regulator artifacts arrive, and whether a provider licence has been settled. Every one of those is on the dependency register in week one for that reason.
The problem
AML programmes slip for the same three reasons
None of them are the software. All three are visible in week one if somebody writes them down.
A dependency nobody owned
The authoritative schema, the sanctions licence, the identity provider client, the penetration test slot. Each is somebody else's decision, each has a lead time measured in weeks, and each becomes a critical path item the moment it is discovered late instead of registered early.Configuration treated as training
CDD forms, risk factors, monitoring thresholds and report mappings are compliance decisions that need a maker, a checker and a rationale. Scheduling them as a week of workshops before go-live compresses the most consequential work in the programme into the least available time.Acceptance without evidence
A test run that produced screenshots and a spreadsheet satisfies a project plan and fails an examination. The artefacts an examiner wants — the audit record, the digest, the exported response, the signed restore timing — have to be collected as the work happens, not reconstructed afterwards.
The plan
Nine phases, and what has to be true to leave each one
Four of them run in parallel through the middle of the programme, which is where the schedule is either won or lost. Every phase has an exit gate rather than a completion percentage, because a gate is falsifiable and a percentage is not.
Weeks 1–2
Discovery and scope
Led by Product owner with the MLRO
- Map the institution's obligations to the capability set — which returns are filed, on what cycle, by whom, and against which authority artifacts.
- Identify the personas that will exist on day one and the permissions each will hold, including which roles are deliberately excluded from what.
- Inventory the source systems: core banking, switches, any existing case or screening tooling, and who owns each mapping.
- Open the dependency register: which provider licences, regulator artifacts and legal decisions are outstanding, who owns each, and what is blocked until they land.
Exit gate — A written scope naming every capability in play, every external dependency, and the specific items that will be deliberately fail-closed at launch.
Weeks 2–3
Infrastructure decisions and preflight
Led by The institution's infrastructure team
- Choose the deployment shape first — single node or Kubernetes. Object storage, replica counts, DNS and backup design all follow from it.
- Provision PostgreSQL 16 with its extensions and separate logins for separate jobs: a runtime role that is not the table owner and holds no bypass on row-level security, a platform role for estate metadata, and a migration owner scoped to the migration job.
- Stand up the identity provider client, TLS termination, DNS and, unless the site is air-gapped, an image registry the runtime nodes can pull from.
- Prove the evidence store honours a conditional write before selecting it — a store that silently permits an overwrite is not acceptable for regulatory evidence.
- Agree the outbound network policy and the metrics scrape, and decide the backup and point-in-time recovery design against the recovery objective the business will sign.
Exit gate — The preflight checklist passes, including the object-store acceptance test, and its result is recorded in the go-live evidence pack.
Weeks 3–5
Staging foundation
Led by Platform operator with the security lead
- Build and pin the API and web images by digest, and run the migrator against the staging database under its advisory lock.
- Generate the root key offline, place it in the external secret manager, and rehearse the escrow procedure — a database dump without it is unreadable, so an unescrowed key means there is no backup.
- Install and verify the signed content pack, and confirm that production configuration refuses to boot when anything unsafe is present.
- Bootstrap the tenant and the first administrator, and confirm health, readiness and metrics endpoints, queue heartbeat included.
Exit gate — A staging environment that boots only on safe configuration, with a verified signed pack and a rehearsed key-escrow recovery.
Weeks 4–7
Database and security acceptance
Led by Security lead with the platform operator
- Run the migrations against a sanitised, production-shaped clone as the supported owner role, without any bypass on row-level security.
- Run the tenant isolation suite and the cross-tenant negative tests against that clone, not against a developer database.
- Run the persona, service-account, workflow, screening and report-provenance permission tests, and record route, actor, tenant, expected status and audit evidence for each.
- Commission the independent security review and penetration test — this is the long-lead item on most programmes, and it is worth starting the procurement in week one.
Exit gate — No open tenant-isolation, authorisation or data-loss finding, and every waived test carries an owner, a compensating control and an expiry date.
Weeks 5–9
Compliance configuration
Led by Compliance administrator with the MLRO
- Author the CDD forms per customer type and tier, with every field bound to a supported storage location and validated before proposal.
- Define the risk model: factors, value scores, weights, bands, review cycles and the categorical enhanced due-diligence triggers that operate independently of the score.
- Author the monitoring rules against the typed vocabulary, simulate each one over seeded history, and approve activation with a second reviewer.
- Register the internal watchlists, import the entries, publish the first versions, and record what is deliberately not being screened against.
- Register the report schemas and field mappings that are available, and record explicitly which report kinds remain fail-closed pending authoritative artifacts.
- Set the retention policy per evidence family, the workflow approval policy, the case routing queues and the board layout.
Exit gate — Every configuration in force is an approved immutable version with a named maker and a different named checker, and the dormant-rule count is zero or explained.
Weeks 6–10
Integration build and replay
Led by Integration lead with the source system owner
- Agree the field mapping, the clock that is the source of truth, currency minor-unit rules, duplicate semantics, the correction and reversal model, peak volume and the maintenance contact.
- Issue a service account with ingest-only permissions and confirm it is refused every customer, case and report read even with a valid credential.
- Map the core banking export onto the canonical columns and process real historical files, reviewing the quarantine rather than only the accepted count.
- Run the sandbox replay: the same external reference must be idempotent, and out-of-order events must neither fabricate an alert nor lose a trace.
- Reconcile accepted, duplicate and quarantined counts against the source ledger, and agree the reconciliation report that will run in production.
Exit gate — A reconciled ingest run over a representative period, with the replay and out-of-order tests evidenced.
Weeks 9–12
User acceptance testing
Led by Product owner with every persona represented
- Work the scenario catalogue end to end: onboarding and its refusals, duplicate transactions, rule evaluation and trace, watchlist import and publish, hit adjudication, cross-subject case correlation, mixed-currency reports, executive small-cell suppression and retention under hold.
- Run the negative tests deliberately: expired user, wrong tenant, wrong actor type, missing second factor, replayed idempotency key, stale version, malformed input, unsupported country code, provider timeout and unavailable analytics stream.
- Record preconditions, actor, tenant, correlation identifier, expected result, actual result and evidence links for every case — the database audit, the digest and the exported response are authoritative, and screenshots are supplementary.
- Run the accessibility pass on the primary workflows: keyboard navigation, visible focus, labelling, contrast and a screen-reader smoke test.
Exit gate — All priority-zero and priority-one scenarios pass, the MLRO accepts the business outcomes, and no conditional acceptance permits filing, screening or identity verification to be represented as available when its dependency is not live.
Weeks 11–13
Operational acceptance and identity onboarding
Led by Platform operator with the system administrator
- Run the drills and time them: database restore, evidence-store restore, key escrow recovery, queue outage and recovery, and — where relevant — the air-gap install from a transferred bundle.
- Measure latency and throughput under the agreed transaction and analyst load, and record the result as the first real capacity evidence this build has.
- Configure alerting on the worker heartbeat, queue age, audit divergence, storage failures and database pool exhaustion, and prove each alert fires.
- Provision the real user accounts as one closed, versioned batch with multi-factor enrolment mandatory, activate them in controlled waves, and accept each account individually against its expected persona: correct local actor, correct tenant, one persona role, a positive authorisation that succeeds and a negative one that is refused.
- Train each persona on their own workflow, and hand over the operator runbook, the incident procedure and the support contacts.
Exit gate — Signed restore and recovery evidence with measured timings, alerting proven to fire, and every user account individually accepted with fresh multi-factor evidence.
Week 14
Controlled launch
Led by Institution sponsor with the MLRO
- Start with one tenant and run monitoring in shadow or parallel against the existing process, comparing what each produces.
- Keep filing submission fail-closed until compliance acceptance of the authoritative artifacts is recorded — the platform enforces this, and the launch plan should not treat it as an obstacle.
- Review audit, queue depth, screening coverage, ingestion counts and storage metrics daily for the first cycle.
- Record the release: build digest, migration set, test run, known exceptions with owners and expiry dates, and the signatures that authorised production.
Exit gate — A release record linking build, migrations, tests, exceptions and signatures — and a written list of what remains deliberately unavailable and who owns closing it.
Who does what
The programme needs six named people, not six teams
Each of these owns a decision that blocks somebody else. Naming them in week one is the single highest-return hour of the whole engagement.
MLRO
Accepts the risk model, the rule set, the screening policy and the report mappings; owns the regulator relationship and the authoritative artifacts; signs the business acceptance. Nothing goes live against a compliance control they have not accepted.Compliance administrator
Authors the configuration: CDD forms, risk factors, monitoring rules, watchlists, retention policy and workflow approval policy. Proposes; does not approve their own work.Platform operator
Owns the deployment, the database roles, the secret manager, the backups and the drills. Holds the recovery objective the business signed and has to demonstrate it with a measured restore.Security lead
Owns the isolation acceptance run, the penetration test procurement, the egress policy and the residual-risk acceptance. Signs off what the institution is choosing to live with, with expiry dates.System administrator
Owns the identity provider integration, the role assignments, the organisational units, the service accounts and the account provisioning ceremony — including that no user is enabled by an ad-hoc console action.Integration lead
Owns the source system contracts, the mapping, the replay evidence and the reconciliation report. Also owns every adapter conversation with a provider, including the licence question before the technical one.
One phase worth expanding
Account provisioning is a controlled ceremony, not a spreadsheet import
It runs late in the programme and is routinely underestimated. Getting it wrong maps a real person to the wrong persona, the wrong organisational unit or the wrong tenant — which invalidates every persona test that came before it.
Before a single account is created
- A change ticket names the batch and its expiry.
- Identity provider and application backups exist, are encrypted, checksummed and restore-addressable.
- Case-insensitive username and email searches return no collisions on either side.
- Every role key and organisational-unit code already exists in the tenant.
- The identity provider, its database, the API, the application database, the worker and the web service are all healthy, with monitoring covering authentication failures and certificate validity.
- A change freeze names one authorised operator and one independent reviewer, and separate operation locks stop a second operator running any part of the ceremony.
How the accounts come alive
- Accounts are staged as one closed, versioned batch against a committed roster with a pinned digest — disabled, with password replacement and second-factor enrolment mandatory.
- Activation runs as a restartable ceremony in small waves, reading every account back after each wave and stopping on any identity, state or audit-control failure.
- An interruption is resumed with the same command from the verified point, never by enabling an individual account by hand.
- Participants enrol in supervised waves: one-time credentials handed over individually, the enrolment session completed, then signed out and a fresh session started — because the session that configures a second factor is enrolment, not proof that a second factor ran.
- Each account is accepted individually: correct identity, exactly one second-factor credential, old sessions revoked, a fresh token carrying both authentication factors, the right persona workspace, one representative operation that succeeds and one sensitive operation that is refused.
In the product
What the configuration work looks like
Most of the compliance phase happens on one family of screens: schema-driven editors that validate a proposal, route it to a checker, and activate an immutable version.
Placeholder — TODO: capture the rule library and risk model configuration screen (/config/rules) from a seeded demonstration tenant — no screenshot of it exists yet. Replace with sourced, approved content before this page is made public.
/config/rulesrule library and risk model configuration
Screenshot slot. Capture from a seeded demonstration tenant with synthetic data and replace this frame. Do not substitute a mock-up of the interface.
What the capture must show
- Live versus dormantHow many rules are in the library, how many are live, and how many have no active version at all — reported as counts rather than a coverage percentage.
- Provenance per ruleWhether the rule arrived in a signed content pack or was authored by the institution, so a configuration review can tell which is which.
- The active risk modelVersion, activation date, aggregation method, enabled factor count, score bands and the categorical enhanced due-diligence triggers.
- The refusal when nothing is activeWhere no risk model is active the screen says so in the strongest terms available: nothing can rate a customer in that state, and the risk band every monitoring rule reads stays unset.
- Simulation before proposalThe replay result — how many alerts a candidate version would have raised over how many transactions, and whether the scan was truncated.
- Approval routingThe activation proposal, its rationale, and the link into the approval queue where a second, different person decides it.
Where the edges are
What this plan assumes, and what it cannot compress
Read this before you take the fourteen weeks to a steering committee.
What the plan covers
- A single institution and a single deployment shape, decided in week two and not revisited.
- Configuration of CDD forms, risk model, monitoring rules, watchlists, retention, routing and report mappings by the institution's own compliance function, with our support.
- One inbound transaction integration built and reconciled, with the replay and out-of-order evidence recorded.
- A full user acceptance pass across every persona, including the negative tests, with evidence captured as the work happens.
- Operational drills with measured timings, alerting proven to fire, and per-account identity acceptance.
What it depends on and cannot shorten
- The independent penetration test. It is procured externally and its lead time is frequently longer than any phase in this plan, which is why the procurement starts in week one rather than when the phase does.
- The authoritative regulator artifacts. Until the goAML schema, code lists and filing channel procedure are supplied and accepted, filing stays fail-closed — enforced by the platform, not by the plan.
- Any licensed provider feed or identity verification adapter. Those are separate procurements with their own contracts, data-protection assessments and acceptance tests, and neither is inside this fourteen weeks.
- Legal determinations on erasure against the retention floor, and on the acceptance and release rules for an authority hold.
- Kubernetes first-install shake-out. The chart has been rendered and linted but never applied to a live cluster, so a Kubernetes deployment should budget time the single-node path does not need.
Keep reading
Related capabilities
The infrastructure the plan provisions, the integrations it builds, and the acceptance that keeps filing closed until it is genuinely ready.
Plan it properly
Bring your dependencies. We will tell you which ones set the date.
Half a day with your MLRO, your platform lead and your integration owner produces a dependency register and a realistic sequence. It is the cheapest way to find out whether fourteen weeks is optimistic for your programme or conservative.