How to use this AML transaction monitoring requirements checklist before choosing a platform
A compliance or platform leader choosing between self-hosted Jube and yente or a commercial AML suite needs a defensible requirements baseline before any vendor demonstration. This checklist is that baseline. It groups requirements into functional, security, integration, operational and compliance categories, and each item should be closed with evidence: a test run on representative data, a written document, or a configuration record. An item that only appears in a sales deck or a team member's memory is not yet a requirement you can defend to an examiner or a partner. The same list can be reused almost unchanged as the requirements section of a request for proposal, which keeps vendor responses comparable and makes gaps visible early.
Assign an owner to every line before evaluation starts. Compliance should own typologies, alert and case handling, suspicious activity decisions and examiner documentation. Security should own access control, encryption, logging and the handling of screened personal data. Engineering should own throughput, latency, availability, upgrades and integration points. Each owner signs off on their section, so a later gap cannot be dismissed as someone else's concern. US and EU rules also differ on several items, including reporting clocks, record retention periods and the scope of the single EU rulebook, so the reader should confirm which regime applies to each business line and jurisdiction before assigning a requirement's threshold. Where the team is unsure, the answer belongs in the checklist as an open question for counsel, not as an assumption in the architecture.
Start with the items that most often decide the platform choice: expected transaction volume at peak, the latency budget for real-time scoring in the payment flow, the list sources and data licenses needed for sanctions and PEP screening, and the retention period for alerts, cases and supporting records. Record each figure with its source and the date it was measured, and ask every bidder to state how its numbers were produced. Then confirm the integration points with the core banking, payments and customer onboarding systems. A requirement that cannot be tested against a real data flow, or that depends on an undocumented vendor feature, should be flagged as a risk and carried into the RFP questions rather than accepted on trust.
Which functional requirements must an AML monitoring platform meet?
This table lists the functional requirements to define before choosing Jube, yente or a commercial AML suite, with why each matters and how to verify it. Read each row as a question to answer from your own payment flows and compliance program, not from vendor material. The main takeaway is that every requirement should be proven with your own historical data and documented scenarios before any platform is selected.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Transaction volume and latency | Peak throughput and the time allowed for a real-time decision set the cluster size and whether scoring can sit in the payment flow or must run in batch. | Measure peak and average transactions per second from your own payment logs, then replay that load against the candidate platform and record scoring latency at the 99th percentile. |
| Typology and rule coverage | Each typology your risk assessment identifies needs a detection rule or model, and gaps here are the most common examiner finding. | Map every typology in your institutional risk assessment to a named rule or model, and confirm each mapping with test cases that should trigger it. |
| Rules versus models | Rules give transparent logic that staff can explain, while models can find patterns rules miss but need more documentation and validation. | Ask which detections are deterministic rules, which are statistical or machine learning models, and what documentation exists for each before accepting either in production. |
| Scenario and backtesting | Changes to thresholds or models can silently shift alert volumes and miss suspicious activity, so each change needs evidence of its effect. | Run a replay of a labeled historical transaction set, compare alert counts and known suspicious cases before and after each change, and keep the results with the change record. |
| Alert generation and triage | Alert quality determines analyst workload, and poor prioritization delays review of the highest-risk cases. | Measure the share of alerts that analysts close as false positives on a sample, and confirm the platform can rank, group and assign alerts by risk and queue. |
| Case management and audit trail | Investigations must show who reviewed an alert, what evidence was gathered and why a decision was made, in a record that can be produced later. | Walk through one closed case from alert to decision and confirm every action, user and timestamp is captured and can be exported without manual reconstruction. |
| Sanctions list matching and fuzzy thresholds | Name matching settings control both missed true matches and the volume of false positives that staff must clear. | Test known names, transliterations and aliases against the chosen threshold, record the match rate and false positive rate, and document who approved the setting. |
| Regulatory reporting outputs | Suspicious activity and sanctions blocking or reporting obligations depend on fields, deadlines and formats that the platform must support or export. | Confirm with your compliance team which report fields and formats are required, then generate a sample report from a test case and check it against that requirement. |
What security controls should an AML stack prove on day one?
An AML stack holds customer identities, transaction data and investigation files, so examiners and auditors will ask how it is protected before they ask how well it detects. The cards below cover the controls to evidence at go-live, and the FTC Safeguards Rule is the starting reference for non-bank institutions under FTC jurisdiction.
Encryption in transit and at rest
The FTC Safeguards Rule at 16 CFR 314.4 requires covered institutions to encrypt customer information in transit over external networks and at rest. For a self-hosted Jube or yente deployment, that covers the transaction feeds, the API calls from payment systems, database volumes, backups, and the copies of watchlist data. Ask the implementation partner to document which keys protect each store, who holds them, and how keys rotate. Confirm that internal traffic between Jube, yente and the case tool is encrypted too, not only traffic that crosses the network edge.
Multi-factor authentication for all access
The same section requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing under 16 CFR 314.4(c)(5). In an AML stack this covers analysts working cases, rule authors, administrators, database operators and service accounts that hold elevated rights. Check whether the approval exception is in writing, who signed it, and whether it is reviewed. Confirm that MFA also applies to the administrative consoles of the case management and infrastructure layers.
Change management for rules and models
The Safeguards Rule requires institutions to adopt change management procedures. For AML, a changed threshold, a new typology rule or a retrained model alters which alerts are raised and which are suppressed, so it is a control change, not a routine software update. Require a versioned record for each rule and model release, with the approver, the test evidence, the date it went live and the rule it replaced. Ask how a rollback is performed and how past alerts are linked to the version that generated them.
Activity logging of authorized users
The rule requires institutions to log the activity of authorized users. For an AML stack, logs should record who viewed, changed or closed an alert or case, who edited a rule or list, who exported data, and which administrative actions were taken on the platform. Logs need to be protected from alteration and retained long enough to support investigations and examinations. Ask the partner where logs are stored, who can read them, and how they are reviewed, and confirm that log retention is set against the institution's own record-keeping obligations.
Penetration testing and vulnerability assessment cadence
Under 16 CFR 314.4(d)(2), an institution without effective continuous monitoring must run annual penetration testing and vulnerability assessments at least every six months. Decide early whether continuous monitoring will be in place, because that choice sets the testing cadence. Ask for the scope to include the monitoring engine, screening service, data pipelines and the case interface, and for results to feed the change management record. Ask who performs the testing and whether the findings are tracked to closure.
PCI DSS scope where card data flows
PCI DSS applies to any entity that stores, processes or transmits cardholder data, or that could affect the security of the cardholder data environment. If card numbers or sensitive authentication data pass through the monitored systems, for example in card transaction feeds, those systems may fall inside scope. Map the data flows before design, decide whether tokenization removes card data from the monitoring path, and ask the partner to document how segmentation is tested. The current active version is PCI DSS v4.0.1.
What operational and compliance requirements must be in writing?
This table lists the operational and compliance terms to put in writing before selecting Jube, yente or a commercial AML suite, with the verification method for each. Use it as a contract and design checklist: if a requirement cannot be verified in a test, a sample or a document, it is not yet ready to sign off. The main takeaway is that retention, model change evidence, list licensing and EU ICT contract terms are the points most often left vague.
| Requirement | What to write down | How to verify it |
|---|---|---|
| Retention of alerts, cases and audit trails | Retention period for alerts, case notes, decisions, supporting documents and audit logs, set by the applicable US or EU rules. The sibling topic on BSA SAR reporting notes a five-year retention for SARs and supporting documents, so confirm the period with your compliance counsel. | Pull a closed case from a test environment after the set retention window and confirm the full record, including attachments and decision history, is still accessible and unaltered. |
| Audit trail completeness | Which events are logged (alert creation, rule hits, analyst actions, overrides, exports, admin changes), who can read logs, and how long they are kept separately from the application data. | Perform a walkthrough where a test alert is handled end to end and confirm each action appears in the log with user, timestamp and before and after values. |
| Rule and model change control | Approval workflow for every rule or model change, versioning, rollback procedure and the named approver. Under the FTC Safeguards Rule, change management procedures are a stated requirement for covered institutions, so align the change log to that expectation where it applies. | Sample three recent rule changes and confirm each has a request, test results, approver sign-off, deployment record and a rollback path. |
| Model and rule validation evidence | Documentation of the typologies each rule covers, the data used, threshold rationale, backtesting results, known limitations and the validation cadence, written so an examiner can follow it without the implementer present. | Ask for the most recent validation package and check that each rule ID maps to a typology, a test dataset and an owner. Confirm the independent validator is not the team that built the rule. |
| Sanctions and PEP list sources and licensing | Named list sources, the license terms for internal commercial use, the permitted redistribution scope, the refresh cadence for each list and the fallback if a refresh fails. | Obtain the written data license from the list provider, compare it against intended use, and run a test refresh to confirm the timestamp and version of loaded data are recorded. |
| High availability and backup | Target recovery objectives agreed in writing, failover design for the scoring path and the screening service, backup frequency, encryption of backups and an off-site or separate-zone copy. | Run a scheduled failover test and a full restore into a clean environment, then compare record counts and check that screening results match the pre-test baseline. |
| Upgrade and patch windows | Notice period for upgrades, maintenance windows, test requirements before production changes, and how security patches are prioritized outside normal windows. Confirm whether the vendor or implementer carries this under a retainer. | Review the last two upgrade records, confirm staging test evidence exists, and confirm a rollback was documented for each release. |
| Regulator reporting outputs | Which reports must be produced (for example, case exports and suspicious activity filing data), the fields they contain, the format and the person responsible for submitting them. | Generate a sample report from test data and check every required field against the regulator's current specification with the compliance lead. |
| DORA-style ICT contract terms (EU entities) | Register of information entry for each ICT service, documented and tested exit strategy, transition plan, the stated locations where services are provided and data processed, advance notice of location changes and data return on termination or insolvency. | Check that the contract states the data locations and exit terms, that the register entry exists, and that the exit plan has been tested or has a scheduled test date. |
How should model governance and rule tuning be documented before selection?
A rule is a condition written by people, such as flagging cash deposits just under a reporting threshold within a set period. A model is a statistical or machine learning method that assigns a score based on patterns learned from data. Examiners treat the two differently because a rule's logic can be read and tested directly, while a model's logic must be explained, validated and monitored for drift. Before choosing Jube, yente or a commercial suite, the requirements document should state which typologies will be covered by rules, which (if any) will use models, and what the institution expects to do with each output. The vendor's ability to run either is a separate question from whether the institution can govern it.
Examiners ask for the typology rationale behind each rule or model: the money laundering or terrorist financing risk it addresses, the business lines and customer segments it applies to, and the reason the thresholds were set where they are. They also ask for tuning history, meaning what changed, when, why, and what alert volumes and hit rates looked like before and after. Back-testing against historical activity and independent validation by staff who did not build the scenario are the standard way to show that tuning did not quietly suppress suspicious activity. The requirements should ask each candidate how it records parameter versions and whether the evidence can be exported for an examination.
The requirements document should name an owner for every rule and model, a change approver separate from the person proposing the change, and a change control process with testing before deployment and a rollback path. For each version it should specify what evidence is retained: the parameter set, the rationale, the back-test results, the validation sign-off, the approval record, the deployment date and the alert outcomes during the period it was live. Confirm with each candidate and with your own model risk or compliance function how long these records must be kept under your regulator's expectations, because retention periods differ by jurisdiction and by record type.
How do US and EU requirements change the checklist?
US institutions subject to Bank Secrecy Act suspicious activity reporting need the checklist to start from the filing workflow, not only from alert volume. Typologies, thresholds and case reasons must map to the decisions your analysts actually record, and the reporting clock determines how long an alert can sit in a queue.
- Filing clock: Ask how alerts age, who owns the decision to file and when your process treats activity as identified. The 30-day filing clock for SARs sets the service level your queue design must meet.
- Retention: Specify the five-year retention period for SARs and supporting documents as a requirement for case storage, audit logs and backup policy.
- OFAC blocking and reporting: Sanctions hits need a blocking workflow separate from ordinary alert handling, plus a reporting path that meets the 10-business-day reporting rule.
- Typology mapping: Record which rules and models address which typology, so a detection can be traced back to your risk assessment.
Confirm with counsel which institution types and reporting obligations apply to you, because filing duties differ across bank, money services business and other categories.
US examiners look for evidence that monitoring rules and models were designed, tested and changed under control. The checklist therefore needs governance and record-keeping items that most open-source deployments will not supply by default, and these items should be written into requirements before any platform is shortlisted.
- Model and rule documentation: Require a written rationale, data inputs, thresholds and known limitations for each rule and model, with a named owner and review date.
- Change management: Require approval records and version history for every rule, threshold and configuration change, linked to the production release.
- Access and logging: Where your institution is a non-bank financial institution under FTC jurisdiction, the Safeguards Rule requires multi-factor authentication for anyone accessing information systems, unless the Qualified Individual approves an equivalent control in writing, and requires logging of authorized user activity.
- Broker-dealer records: If you are a broker-dealer, SEC Rule 17a-4(b) sets a minimum of three years for certain records, with the first two easily accessible. Confirm whether monitoring outputs fall within that scope.
Confirm with your examiner or counsel which record types, retention periods and independent validation expectations apply to your charter before you write the retention and validation sections of the checklist.
EU institutions face a single AML rulebook from Regulation (EU) 2024/1624, which applies from 2027 and is supervised through AMLA. The checklist needs to show how customer due diligence and monitoring duties will be evidenced to supervisors across member states, not only to a single national authority.
- Customer due diligence: Add requirements for how risk-based due diligence data is captured, refreshed and linked to monitoring alerts, so that a supervisor can trace the chain from onboarding to alert.
- Monitoring documentation: Require documented rationale for typologies, scenario coverage and tuning decisions in a form that supervisors can read without the implementation team present.
- Cross-border data: If you operate in several member states, list which national rules affect data fields, retention and reporting, and assign an owner to each.
- Supervisory readiness: Define the evidence pack for each monitoring control, including test results, change records and exception handling, and keep it current with your implementation.
Confirm with EU counsel and your national competent authority how the 2027 timing, transitional arrangements and supervisory expectations apply to your entity, because this checklist should not assume them.
EU institutions that run monitoring and screening on their own infrastructure also fall under operational resilience and data protection rules. DORA has applied since 17 January 2025, and it changes how ICT contracts, exit plans and data location must be written into the checklist, while GDPR governs the screened personal data itself.
- DORA contract register: Article 28(3) requires a register of information on all ICT contractual arrangements, so every open-source support, hosting and data provider must be recorded with its service role.
- Exit strategy: Article 28(8) requires documented, tested exit strategies and transition plans for ICT services that support critical or important functions, so the checklist needs a migration and exit requirement for the monitoring stack.
- Contract terms: Article 30(2) requires every ICT services contract to state where services are provided and data processed, with advance notice of changes and data return on termination. Add these to the vendor requirements.
- GDPR for screened data: Define lawful basis, minimization, retention and access controls for names and identifiers that are screened, and check whether your screening data flows create transfers outside the EU.
- NIS2 scope: Confirm with counsel whether Directive (EU) 2022/2555 applies to your entity and whether any monitoring system is in scope.
Confirm with your data protection officer and legal team how DORA, GDPR and NIS2 apply to your entity before you finalize contract and data sections.
What do buyers ask before hiring an AML implementation partner?
How much effort does defining AML requirements take, and what drives it?
Requirements effort depends mostly on how many business lines, products, payment channels and jurisdictions the monitoring must cover, and on how much of the existing rule logic is documented. A single-product lender with one entity and a clear customer base usually has a shorter definition phase than a multi-entity group with cards, cross-border payments and correspondent flows. Other drivers are the volume of historical alerts available for analysis, the number of list sources to be licensed, and how many approvers must sign off on typologies and thresholds. Ask the partner for a written list of workshops, the documents they will review, and the sign-offs they expect from compliance before any build starts.
Can our team define AML requirements without an outside partner?
Often yes, provided the team has compliance staff who understand typologies and an engineer who can translate them into data fields, rule logic and integration points. Internal teams usually struggle with the parts that are easy to miss: mapping every transaction source, deciding how alerts are scored and retained, and documenting why each threshold was chosen. A partner can run the discovery, draft the requirements document and challenge gaps, while your compliance function keeps ownership of the risk decisions. Whichever route you take, the final requirements should be approved by the people who will answer to examiners.
What does the work need from compliance and IT teams?
Compliance must supply the risk assessment, current typologies, alert and case procedures, and the people who will approve rules and model changes. IT must supply architecture diagrams, data source inventories, access and identity standards, hosting constraints and change management rules. Both teams should agree early who owns data quality, because monitoring is only as good as the transaction feed. Expect scheduled working sessions in each phase and a named decision-maker for disputes between risk appetite and technical limits. Ask the partner to list these inputs in the written scope so that gaps show up before delivery, not during testing.
How long does a requirements phase usually run?
No duration can be stated here without a supplied source, and the length varies with the scope described above. Ask any partner for a written timeline that separates discovery, requirements sign-off, data mapping and the point where build work starts, with the dependencies on your team's availability written into it. A credible plan names the decisions that could extend the schedule, such as a late list licensing agreement or unresolved threshold debates. Treat a timeline without named dependencies as an estimate, not a commitment.
Is watchlist data licensing included in an implementation engagement?
Do not assume it is. Sanctions and PEP data come from list sources with their own terms, and the licence needed for internal commercial use depends on how you use the data and which sources you choose. Implementation work can include configuring yente and loading data, but the data licence itself is an agreement between your organization and the data provider. Ask the partner to state in writing which sources are assumed, who signs the licence, whether internal use or redistribution is covered, and what happens when a source changes its terms. Confirm these points with the data provider and your legal team.
How should we compare a self-hosted stack with a commercial AML suite?
Compare total ownership, not licence fees alone. For a self-hosted stack, the recurring costs usually include infrastructure, data licences, rule and model tuning, upgrades, security testing and internal staff time, while a commercial suite adds vendor subscription and support terms. Score both options against your own requirements: volume and latency, model governance, case management, retention, reporting and integration points. Ask each vendor, and each partner, how they document rule changes for examiners, how they handle false positive reduction, and who is responsible for data quality. A written comparison that uses your own requirements is more useful than a feature checklist from either side.
What evidence should a partner deliver for examiners?
A partner should deliver the documentation your examiners will ask for: the requirements and risk assessment, the rule and model inventory with rationale and approvals, change records, test results for each rule set, data lineage for the transaction and list feeds, and access and logging configuration. Evidence also covers operating procedures for alert triage, case files, escalation and record retention periods set by your legal and compliance teams. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations, and independent examiners make their own determinations. Ask the partner to list every artifact in the written scope.
Which questions separate one AML platform from another?
The fastest way to separate one AML platform from another is to ask how rules and models change over time. Ask each vendor or partner how a rule or model version is created, approved, deployed and rolled back, and who signs off each step. Ask whether the platform keeps the exact logic that produced every past alert, so an examiner can see which version scored a given transaction on a given date. A platform that can only show the current configuration cannot answer that question. Ask for a demonstration in which a threshold is changed, published, and then reverted, and check that the audit log records each step with the user, the timestamp and the reason.
Next, test replay. Before a new rule goes live, the team should be able to run it against historical transactions and see how many alerts it would have created, which customers it would have touched, and how that compares with the current logic. Ask whether replay runs on the same data pipeline as production, how long a replay of a full month takes on the volumes you expect, and whether replayed alerts are kept separate from live case queues. For list data, ask how sanctions and PEP sources are licensed for your intended use, how often updates arrive, and whether a failed refresh stops screening or silently keeps stale data. Confirm these answers with the data provider, since terms depend on your use case.
Finally, ask about high availability and evidence export. Request the failover design in writing, including what happens to in-flight transactions if a node fails, and how the platform behaves during a database or message queue outage. Then ask for a sample examiner package built from your own test data: case files, alert history, rule version history, screening decisions and the records of who reviewed them. Check whether the export is machine readable and whether it can be produced without a vendor engineer. Use your own sample data for every demonstration, because a polished demo on the vendor's dataset will not show how the platform handles your formats, volumes and edge cases.
How DeployOpen scopes and delivers an AML requirements and selection engagement
DeployOpen approaches AML transaction monitoring requirements as a written, fixed-scope engagement inside your own infrastructure. We document what the monitoring, screening and case stack must do before any platform is chosen, then test candidate open-source components and commercial suites against that written baseline. DeployOpen is a Chainscore Labs company and does not issue audit reports or attestations.
How we scope
- Agree a written scope covering volumes, latency targets, typologies, list sources and retention before work starts.
- Map which regulatory obligations apply to your entities and jurisdictions, and record which ones you must confirm with counsel.
- Inventory existing systems, data sources and integration points, such as core banking, payments and KYC tools, that the AML stack must connect to.
How we build
- Draft the requirements catalog, including typology-to-rule mapping and model governance expectations, for review by your compliance team.
- Build a comparison workbook that scores Jube, yente and commercial suites against each requirement, with evidence for every score.
- Run a proof-of-concept against sample, anonymized or synthetic transaction data agreed in the scope, and record measured results.
How we hand over
- Deliver the signed-off requirements document, selection rationale, architecture sketch and open items with named owners.
- Provide documentation of data flows, list licensing questions and data retention decisions in a form examiners can review.
- Transfer the project files and recommendations to your team so the selection decision can be audited later.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the selection decision is made.
- Review requirement changes when regulations, sanctions lists or business lines change, under a separate written change scope.
- Confirm with your implementation partner and vendors which support terms, release cadence and licenses apply to the chosen platform.
