The difference between an AML platform that strengthens your compliance programme and one that creates a new layer of operational risk sits in the questions you ask before the contract is signed. Most vendor demonstrations show the same screens: a dashboard, a rule builder, an alert queue. What separates a platform that will survive its first regulatory examination from one that will not is whether the compliance team can operate, configure, and explain it under pressure.
This guide is built for the evaluation that matters: the one your Chief Compliance Officer, CTO, and CFO run together, after the demo, before the purchase order. It covers transaction monitoring software, name screening, AML case management software, regulatory reporting, AI capabilities, integration, and vendor accountability. Twenty-five questions, each with the reasoning behind it and the answer that should give you confidence.
If you are still working through what regulatory technology can and cannot do for your institution, start with What RegTech Actually Does — and What It Can't Do For You. That piece covers the foundational principle this guide assumes: your institution remains accountable to the regulator regardless of the technology it deploys. BSP Circular 899 makes this explicit. The board and senior management stay responsible for outsourced activities. Core compliance judgement cannot be delegated.
The questions below test whether a platform earns that accountability or undermines it.
Transaction monitoring
1. Can compliance staff create, edit, and deploy detection rules without an engineering ticket?
A no-code rule engine is not a nice-to-have. It is the difference between a compliance team that owns its transaction monitoring programme and one that files change requests with a vendor's development queue. When the BSP asks why a specific typology is not covered, "we submitted a ticket three weeks ago" is not an answer an examiner will accept.
Look for: a visual rule builder where compliance analysts define conditions, thresholds, time windows, and aggregation logic directly. Every change should carry a timestamped audit trail showing who made it and when.
2. Can you test a new rule against historical data before it goes live?
A rule that has never been tested against real transaction patterns is a liability. It will either generate thousands of false positives in its first week or miss the activity it was designed to catch.
Look for: a dry-run capability that lets you replay a rule against 30, 60, or 90 days of historical transactions. You should see exactly which alerts it would have generated before the rule touches a single live transaction.
3. Can you validate a rule against live transactions without activating it?
Dry runs test against history. Shadow mode tests against the present. A rule that performed well on last quarter's data may behave differently against current transaction volumes, new products, or seasonal patterns.
Look for: a parallel-validation mode that runs the candidate rule alongside your live rule set and generates simulated alerts for review, without triggering the operational alert queue.
4. How does the system prevent duplicate alerts for a customer already under investigation?
Without suppression logic, an analyst investigating a customer for structuring will receive new alerts on the same customer, under the same rule, for every transaction that breaches the threshold during the investigation. This inflates alert volumes, fragments case records, and forces analysts to spend time closing duplicates.
Look for: a configurable suppression window that blocks duplicate alerts for a customer under the same rule while an investigation is open. Well-designed suppression can reduce duplicate alert volume by up to 75%.
5. Does the system show the full reasoning behind every alert on one screen?
When an examiner asks an analyst to explain why a specific alert was generated, the analyst should not have to navigate between five screens or export data to a spreadsheet. Explainability is a regulatory expectation, not a reporting convenience.
Look for: a single alert view that displays the rule that triggered, the breach amount, the variable logic applied, the customer's transaction history over the relevant period, and the aggregation window. All on one screen.
Name screening
6. Does screening happen at onboarding, or only afterward?
A platform that screens customers only in batch runs after onboarding creates a window where a sanctioned individual can open an account, transact, and disappear before the first alert fires. Real-time API-based screening at the point of onboarding closes that window.
Look for: API-driven screening that returns results before the onboarding workflow completes, with coverage across sanctions lists, PEP databases, and adverse media sources. Strong AML tools typically match against five or more identity fields: name, date of birth, gender, citizenship, and address.
7. Does the platform support continuous monitoring against new watchlist additions?
Batch screening on a fixed schedule means your institution is exposed between runs. If a customer is added to a sanctions list on Tuesday and your batch runs on Friday, you have three days of unmonitored transactions.
Look for: delta screening. This means automated re-screening at configurable intervals (daily, weekly, monthly) that checks your existing customer base against only the new additions to watchlists since the last run, not the entire list every time. It keeps the process efficient while closing the monitoring gap.
8. Can the compliance team adjust match-score weightings without vendor involvement?
Every institution's customer base has different characteristics. A bank with a large diaspora customer base needs different name-matching sensitivity than one serving primarily domestic corporate clients. If adjusting match weightings requires a vendor support ticket and a two-week turnaround, your screening programme is not calibrated. It is defaulted.
Look for: a configuration interface where compliance staff adjust field weightings directly, with every change logged in an auditable trail.
9. Does the platform surface associated individuals and linked entities within the same alert?
A screening alert that identifies a match but does not show the matched individual's known associates, linked entities, or corporate relationships forces the analyst to conduct that research manually. A separate system, a separate search, minutes added to every disposition.
Look for: associate linkage that pulls every associated individual and linked entity from the watchlist record into the same alert view. The analyst should be able to assess the full network without leaving the screen.
Case management
10. Can the system consolidate alerts from different modules into a single case per customer?
A customer who triggers a transaction monitoring alert and a screening alert simultaneously should not generate two separate cases handled by two different analysts. Fragmented case records create fragmented investigations. Fragmented investigations produce incomplete filings.
Look for: multi-alert consolidation that groups alerts by customer regardless of the originating module (screening, transaction monitoring, or manual referral) into a single case record with a unified timeline.
11. Can you link cases across related entities to investigate coordinated schemes?
Money laundering rarely involves a single account. Structuring, layering, and mule networks involve multiple customers acting in coordination. If your AML case management software treats each customer as an island, your analysts cannot see the scheme.
Look for: cross-entity linking that lets an analyst merge or associate cases across customers, with a shared evidence pool and a unified view of the relationships.
12. Is the full case record locked and immutable once a case is closed?
A case record that can be edited after closure is a case record that cannot be trusted in a regulatory examination. The audit trail must be chronological, immutable, and complete. Every action, every note, every document attachment, every status change, from case creation to closure.
Look for: an automatic lock at case closure that prevents any modification to the case record, with the full chronological audit trail preserved and exportable.
13. Can administrators control which AI-assisted actions are available to which teams?
Not every team should have access to every capability. A junior analyst team may benefit from AI-generated case summaries but should not have access to auto-suggested dispositions. A senior investigations team may want the full suite. Granular control prevents over-reliance and ensures the compliance programme, not the software, determines how AI is used.
Look for: an admin control centre where team leaders toggle individual AI actions on or off per team, with changes logged.
Regulatory reporting
14. Does the platform generate STR narratives from case data, or does the analyst start from a blank page?
The STR narrative is the single most time-consuming step in the filing process. An analyst who must re-read every transaction record, case note, and piece of evidence to write a coherent narrative from scratch will either miss the filing deadline or produce a narrative that omits material facts.
Look for: AI-assisted narrative generation that drafts the STR from accumulated case content (transaction summaries, alert details, analyst notes, and supporting documents) for the analyst to review, edit, and approve. The analyst's judgement remains the final gate. The platform eliminates the blank-page problem.
15. Does the system track filing deadlines and escalate automatically?
An STR filed one working day late is a compliance failure regardless of the quality of the investigation. A CTR filed outside the five-working-day window is the same. Manual deadline tracking in spreadsheets is how deadlines are missed. BSP Circular 1193 introduced even tighter reporting windows for risk events.
Look for: in-platform deadline tracking with configurable escalation rules. Automatic notifications to supervisors when a filing approaches its deadline, and hard visibility at the team and organisational level.
16. Does the platform export in the regulator's required format natively?
A platform that requires manual CSV conversion or field mapping before submission introduces a point of failure between the system of record and the regulator's system. Every manual conversion step is a potential data-integrity issue.
Look for: native export in the regulator's prescribed format. For BSP-supervised institutions, this means GoTRACS-compatible CSV output with no intermediate conversion.
17. Does the filing workflow connect to the case record, or is it a separate module?
A filing that is disconnected from the case that generated it creates a documentation gap. The examiner should be able to trace the path from alert to case to filing in a continuous, auditable chain.
Look for: an integrated workflow where the alert generates the case, the case generates the filing, and the filing references the case. AI pre-populates the report from CDD, transaction, and case data accumulated along the way.
AI and automation
18. Can the AI explain its reasoning in terms an examiner can follow?
An AI that triages an alert as low-risk but cannot explain why creates regulatory risk, not efficiency. Model explainability is a supervisory expectation in every major jurisdiction. "The model said so" is not defensible.
Look for: plain-language explanations of every AI-generated recommendation. Why was the alert triaged to a specific risk level? What data points drove the suggestion? What should the analyst verify before accepting it?
19. Does the AI suggest dispositions, or does it decide them?
The distinction matters. An AI that suggests a disposition and presents the reasoning for analyst review is an efficiency tool. An AI that auto-closes alerts without human review is an uncontrolled decision-maker operating inside your compliance programme.
Look for: auto-suggest disposition with explicit analyst approval required before any case action is taken. The AI recommends; the human decides.
20. Can the AI generate closure narratives that meet regulatory documentation standards?
A closure narrative that reads like it was generated by a machine (generic, formulaic, disconnected from the specific facts of the case) will draw examiner scrutiny. The narrative must reflect the actual investigation, reference the actual evidence, and explain the actual reasoning.
Look for: AI-generated closure narratives that incorporate case-specific details. The specific transactions reviewed, the screening results considered, the timeline of the investigation, and the rationale for the disposition. Drafted for analyst review and editing before finalisation.
Integration and deployment
21. What is the realistic deployment timeline, and what does it depend on?
A vendor that quotes twelve weeks without asking about your core banking system, data formats, existing rule library, or team size is quoting a number, not a timeline. Deployment timelines depend on data migration complexity, integration architecture, rule configuration, and user training. A credible vendor will scope each one.
Look for: a phased deployment plan with explicit milestones, defined dependencies, and a pilot period where the platform runs in parallel with your existing process before full cutover.
22. Does the platform integrate via API, batch file, or both?
Your core banking system, CDD repository, and transaction database each have their own data architecture. AML compliance software that supports only one integration method forces your infrastructure to conform to the vendor's constraints.
Look for: flexible integration that supports real-time API connections for screening and alerting, batch ingestion for historical data and bulk operations, and configurable data-mapping tools that accommodate your existing schema.
23. What happens to your data if you terminate the contract?
Vendor lock-in is a compliance risk, not just a commercial one. If your case records, filing history, and audit trails cannot be exported in a usable format, your institution loses its regulatory documentation when it changes vendors.
Look for: contractual data-portability provisions, standard export formats for all records, and a defined data-retention and return period in the service agreement.
Vendor accountability and governance
24. Will the vendor provide audit-ready documentation of its own controls?
Under BSP Circular 899, your institution must conduct due diligence on outsourcing providers covering reputation, financial health, internal controls, security, and regulatory compliance. A vendor that cannot provide a SOC 2 report, a penetration-test summary, or a business-continuity plan is a vendor you cannot demonstrate due diligence for. This accountability will be tested directly in the 2027 FATF mutual evaluation.
Look for: current SOC 2 Type II reports, documented information-security policies, business-continuity and disaster-recovery plans, and a willingness to participate in your institution's vendor-audit process.
25. Does the contract assign accountability clearly, or does it default to the vendor's standard terms?
The vendor provides the technology. Your institution provides the judgement. The contract must reflect that division clearly, covering incident-notification obligations, liability for data breaches, SLA commitments with measurable penalties, and the right to terminate if the vendor fails to meet regulatory standards.
BSP Circular 899 is explicit: if clients are harmed by a provider's errors, omissions, or fraud, the institution must provide remedies or compensation. Your institution keeps its right to seek recourse from the provider, but the regulatory obligation stays with you.
Look for: contracts that define SLAs with measurable remedies, data-breach notification timelines, audit-access provisions, and termination rights tied to regulatory compliance.
How to use this checklist
Print it. Bring it to the next vendor demonstration. Score each question on a three-point scale: the vendor answers clearly and demonstrates the capability live, the vendor describes the capability but cannot demonstrate it, or the vendor does not address it. Any question scored in the third category is a gap. Three or more gaps in a single section is a disqualifying pattern.
The questions in this guide test what matters after the demo ends: whether the AML software gives your compliance team ownership of the programme, whether it produces evidence an examiner can follow, and whether the vendor's accountability framework matches your regulator's expectations.
If you want to see how these twenty-five capabilities work inside a single platform, book a walkthrough of Fyscal ARCX and bring this checklist with you.