An AML proof of concept should answer a small number of material questions that cannot be resolved reliably through documentation or a standard demonstration. If the PoC tries to test every feature, it becomes a miniature implementation programme and produces ambiguous results.
Start with hypotheses
Write each uncertainty as a testable statement. Examples: “The screening engine can identify our known test matches while reducing the current false-positive queue,” or “the API can support our onboarding flow with the required fields and error handling.”
Choose representative data
Use synthetic or appropriately controlled data that reflects the characteristics causing real operational difficulty: common names, Japanese original-script names, Romanised variants, incomplete dates of birth, corporate names, high-risk jurisdictions or representative transaction patterns. Protect personal and confidential data in accordance with internal requirements.
Keep the PoC narrow enough to be decisive
A useful PoC may test three to five hypotheses rather than fifty product features. Each hypothesis should have a named owner, test data, expected result, measure and decision rule. Features that are already proven by documentation, certification or a standard demonstration do not need to consume PoC time.
Build a test pack that reflects production difficulty
- Names with common transliteration or order variation.
- Japanese original-script names alongside Romanised records.
- Common names requiring date-of-birth or nationality disambiguation.
- Corporate records with subsidiaries, trading names or complex ownership.
- Records with intentionally missing optional attributes.
- Known non-matches designed to test false-positive behaviour.
- API requests that contain invalid, incomplete or duplicate data.
Test known positives and known negatives
A good screening test set contains cases that should match, cases that should not match and ambiguous cases that require investigator judgement. This reveals both sensitivity and operational noise.
Measure false positives as workload
Do not stop at match counts. Measure how many candidates require review, how long reviewers take, what secondary data is available and whether analysts can dismiss irrelevant matches consistently.
Test configuration changes
Change a threshold, matching scope or relevant rule and observe the effect. Confirm who can change the setting, how the change is logged and whether the institution can compare results before and after.
Test the investigation workflow
- Can an analyst record a due-diligence decision?
- Can rationale and supporting evidence be attached?
- Can work be escalated or reviewed?
- Can a later reviewer understand the original decision?
- Can monitored entities surface meaningful changes?
Test the integration, not just the endpoint
If an API is material, test authentication, data mapping, error responses, retries, identifiers, response handling and reconciliation. A successful 200 response does not prove the end-to-end business process works.
Test reporting and evidence
Ask the team to reconstruct a sample case from reporting and audit information. Confirm that operational users and auditors can retrieve the necessary history without relying on vendor staff.
Define acceptance criteria in advance
| Area | Example measure |
|---|---|
| Detection | All agreed high-priority known test cases are surfaced or differences are understood. |
| False positives | Review workload is measured against a baseline or agreed threshold. |
| Workflow | Analysts can complete the required decision and escalation path. |
| Integration | Required data fields and failure paths work end to end. |
| Evidence | A reviewer can reconstruct the test decision from system records. |
| Performance | Representative volume/latency meets agreed test conditions. |
Capture the evidence package
For each test, retain the input, configuration, system output, analyst decision, timings, screenshots or exports where appropriate and the conclusion. If a vendor changes a configuration mid-PoC, record the change and rerun the affected cases so the result remains interpretable.
Make the go/no-go decision explicit
At the end of the PoC, classify each hypothesis as passed, failed, conditionally passed or not proven. A conditional pass should identify the dependency that must be resolved in contracting or implementation. Avoid a vague “overall positive” conclusion that loses the evidence gathered during the test.
Do not change the scoring after seeing the result
Agree the weighting and pass/fail criteria before testing. Otherwise, teams naturally rationalise weak outcomes from preferred vendors or overvalue impressive but non-material features.
Document what the PoC did not prove
A short pilot will not prove long-term scalability, support quality, resilience or regulatory suitability. Record the limitations and close them through references, contractual commitments, security assurance or implementation testing.
Build a MemberCheck PoC around the AML risks and operational uncertainties that matter most to your institution, with success measures agreed before the test begins.
