AML technology projects fail when implementation is treated as configuration work rather than control implementation. The system may go live on time while users rely on spreadsheets, alerts route incorrectly or the institution cannot explain how a requirement became a production setting.
A stronger implementation connects four things throughout the project: risk, requirement, configuration and evidence.
Stage 1: define the control scope
State which processes are in scope and which remain elsewhere. Examples include individual screening, corporate screening, identity verification, KYB, customer risk assessment, monitoring and transaction monitoring. Identify the business owner and control objective for each.
Stage 2: turn policy into testable requirements
Avoid requirements such as “support sanctions screening”. Specify the customer types, fields, lists, matching approach, review steps, escalation, monitoring frequency, reporting and integration behaviour required. Every material requirement should be testable.
Stage 3: map the data
Identify source systems, required fields, identifiers, data quality issues, ownership and update frequency. For Japan, consider original-script names, Romanised names, company identifiers and jurisdiction information where relevant.
Stage 4: design the operating model
Define who performs screening, who reviews potential matches, who changes configuration, who approves escalations and who monitors the control. Configure user roles around those responsibilities rather than giving broad access for convenience.
Stage 5: configure and document
Record the reason for important settings. Matching scope, risk categories, data sources, monitoring choices and workflow rules should connect back to approved requirements or risk decisions.
Stage 6: build and test integrations
Test both directions of data flow. Confirm what happens when the upstream record is incomplete, when the AML service returns an error, when a customer is updated, and when a monitoring event needs to be routed back into the institution’s workflow.
Stage 7: test with realistic cases
| Test type | Purpose |
|---|---|
| Functional | Does each requirement work as designed? |
| Data quality | Are the right fields and identifiers being sent? |
| Match/alert behaviour | Do representative true and false-positive scenarios behave as understood? |
| Workflow | Can users disposition, escalate and evidence cases? |
| Permissions | Can each role do only what it should? |
| Reporting | Can operations, management and audit retrieve required evidence? |
| Failure handling | What happens when integrations, data or services fail? |
Assign implementation ownership with a RACI
At minimum, define who is responsible and accountable for requirements, source data, configuration, integration, security review, test evidence, training, cutover and control acceptance. The MLRO or control owner should not be asked to approve a technical go-live without evidence that the control requirements have passed.
Common implementation failure modes
- Requirements are copied from the old system instead of derived from current risk.
- Test data is too clean and does not reproduce real matching or data-quality problems.
- Configuration decisions are made in workshops but not documented.
- API testing covers happy paths only.
- Operational users join the project after the workflow is already fixed.
- Go-live success is measured by system availability rather than control performance.
Stage 8: train by workflow
Train analysts on the decisions they need to make, not just where buttons are located. Include examples of match review, escalation, documenting rationale and handling monitoring changes.
Stage 9: cut over with clear ownership
Define the production start time, monitoring of errors, incident ownership and fallback path. Reconcile early production activity against expected volumes to identify missing feeds or configuration issues.
Use hypercare metrics that reveal control issues
During the first weeks of production, track more than incident tickets. Review expected versus actual screening volumes, unmatched or rejected records, alert volumes, average review time, user workarounds, integration retries, overdue cases and data-quality exceptions. These indicators help separate normal adoption issues from material control defects.
Stage 10: validate after go-live
Implementation is not complete on launch day. Review alert volumes, match quality, incomplete records, user workarounds, overdue reviews and integration failures. Confirm that the implemented control is operating as intended and adjust through the approved change process.
MemberCheck implementation considerations
MemberCheck provides web access and API integration, with current documentation covering user roles, screening settings, monitoring, risk assessment, reports and API v3. Implementation should map those capabilities to the institution’s specific control requirements and service region.
Use these stages as the implementation workplan for a MemberCheck deployment and convert each material requirement into a test case before go-live.
