The fastest way to make a poor AML technology decision is to start with a vendor demonstration. Demonstrations naturally emphasise what the product does well. A better process starts with the institution’s financial-crime risks, turns them into operating requirements and then asks every vendor the same difficult questions.
That discipline is increasingly important in Japan. The FSA’s current AML/CFT framework places emphasis on maintaining and enhancing risk-management frameworks and on understanding whether controls operate effectively. Technology selection should therefore test whether a platform can support the institution’s control design and evidence, not merely whether it has a long feature list.
1. Which financial-crime risks does the system actually support?
Ask the vendor to map its capabilities to your risks rather than to its product modules. For example, if your material risks include high-risk customers, cross-border payments, complex corporate ownership and unusual transaction patterns, require the vendor to show how those risks move from identification to control, alert, investigation and evidence.
2. Which parts of the customer lifecycle are covered?
Clarify whether the system supports onboarding only or also ongoing customer management. The evaluation should distinguish identity verification, business verification, PEP and sanctions screening, adverse media, customer risk assessment, ongoing monitoring and transaction monitoring. A platform can be strong in one area without replacing every other control.
3. How does the platform handle Japanese names and data?
Ask how the system handles names presented in Japanese script and Romanised forms, what matching controls are configurable and what information reviewers can use to resolve potential matches. The answer should be operational rather than simply “we support fuzzy matching”.
4. Which data sources are used and how are they governed?
Understand the screening data rather than treating “global coverage” as sufficient. Ask which PEP, sanctions, regulatory, law-enforcement and adverse-media sources are available, how updates are managed, whether different data sources can be selected and how source provenance is shown to investigators.
5. Can matching rules be configured without creating uncontrolled risk?
More sensitive matching can identify more candidates but also increase false positives. Ask what parameters can be configured, who can change them, whether changes are logged and how the institution can test a new setting before relying on it operationally.
6. How does ongoing monitoring work?
Ask what triggers a new review, how changes are surfaced, how existing due-diligence decisions are treated and how review queues are prioritised. Monitoring should produce actionable information, not simply another list of alerts.
7. How does transaction monitoring fit the customer-risk model?
If transaction monitoring is in scope, ask how rules or scenarios are configured, how alerts are routed, how analysts investigate them and whether customer risk information can be considered alongside transactional behaviour. If a separate monitoring system remains in place, ask how the two systems will exchange data and decisions.
8. What does the investigation and evidence trail look like?
Request a demonstration of the complete audit trail. Can an auditor understand what was screened, what matched, what evidence was reviewed, who made the decision, what changed later and why the final outcome was reached? If the answer requires assembling data manually from several screens or exports, include that operating cost in the evaluation.
9. How will the system integrate with our existing environment?
Ask for the API model, authentication approach, service regions, batch options, webhooks or notifications where available, data fields and rate/volume constraints relevant to the project. Confirm what requires custom development and what is available as standard.
10. What can administrators control after go-live?
A system that requires vendor intervention for every policy or workflow change can become slow and expensive. Ask which settings compliance administrators can manage directly, what permissions control those changes and how configuration changes are recorded.
11. How will we prove the system is working?
Define the evidence needed for ongoing effectiveness testing before purchase. Possible measures include alert volumes, false-positive rates, investigation outcomes, overdue reviews, monitoring changes, rule performance, data-quality exceptions and time to disposition. The appropriate metrics depend on the control and risk.
12. What happens during implementation, support and exit?
Ask about data migration, configuration, testing, user training, production cutover, support, upgrades and how your data can be retrieved if you later change providers. Exit planning is part of procurement because AML evidence and customer history may remain important after the vendor relationship ends.
Turn the answers into a shortlist
Score each vendor against the same mandatory requirements before adding subjective preferences. A strong shortlist is not necessarily the three vendors with the most features. It is the group that can demonstrate that their technology fits your risk, workflow, integration and evidence requirements.
Use these 12 questions in your next MemberCheck discovery session and ask the team to demonstrate the relevant workflow rather than a generic product tour.
