The evidence examiners expect from automated risk monitoring: a 10-item evidence table, good vs poor practice, SAR timelines, RFIs, and a 30-day plan.
Regulators expect proof that automated risk monitoring fits your risks and actually works. In practice that means a written AML policy, a customer risk rating method, a documented reason for every rule and threshold, tuning records, independent testing, timestamped case trails, SAR decision records, sanctions list update logs, management reporting, and records kept for five years.
This article is general information, not legal advice. Exam scope differs by regulator and license, so confirm yours with counsel.
Key takeaways
They expect a program that is risk based, documented, tested, and able to show its own work. Automation doesn't change the standard. It changes the evidence, because every decision now leaves a record.
The global baseline is FATF Recommendation 1, the risk-based approach: identify and assess your money laundering and terrorist financing risks, then apply controls proportionate to them. FATF Recommendation 20 adds prompt reporting of suspicious transactions. The automated risk monitoring explainer covers the components that sit under those obligations.
For a US money services business (MSB), the requirement is concrete. 31 CFR 1022.210 sets four minimum pillars for the AML program:
FinCEN and the IRS publish the Bank Secrecy Act/AML Examination Manual for Money Services Businesses. It dates from 2008, but the method holds: scope the risk, read the program, test transactions against it.
Because a default rule was tuned for someone else's customers. When an examiner asks why a velocity rule fires at five transfers a day for a freelancer segment, the answer has to come from your risk assessment, not from a vendor's setup guide.
FinCEN said this directly in its October 2025 SAR FAQs: monitoring parameters should be commensurate with the money laundering and terrorist financing risk of the specific institution, considering its products, locations, and customers. The UK's FCA Financial Crime Guide lists, as poor practice, threshold-based systems that are poorly calibrated, where the firm struggles to explain why a particular rule exists.
So the default isn't the problem. The undocumented default is. The 12 red flags rule library is a useful starting point for that inventory.
Examiners ask for artifacts that prove each control exists, runs, and gets reviewed. The table below covers the ten items that come up most in reviews of automated monitoring.
| Evidence item | What examiners look for | Example artifact | Owner |
|---|---|---|---|
| Written AML policy | Approved, current, and matching what the system does | Policy with version history and approval date | Compliance officer |
| Customer risk rating methodology | Clear factors, how ratings change, who can override | Methodology document plus rating distribution | Compliance |
| Rule and threshold rationale | Each rule tied to a risk and a customer segment | Rule inventory with typology, threshold, rationale | Compliance with engineering |
| Calibration and tuning records | Changes tested before release and approved | Change log with before and after alert counts | Compliance with engineering |
| Independent testing results | Scope matched to risk, findings tracked to closure | Review report and remediation tracker | Independent reviewer |
| Alert to closure case trails | Timestamps, reviewer, evidence, and a reason | Case export for a sample period | Compliance analysts |
| SAR decision records | Filed on time, consistent reasoning | SAR log with detection, decision, and filing dates | Compliance officer |
| Sanctions list update logs | Lists loaded promptly and rescreening ran | List version log and rescreen job output | Engineering with compliance |
| Management information and board reporting | Leadership sees volumes, backlog, SARs, findings | Monthly report pack and meeting minutes | Compliance officer |
| Record retention | Five years, and retrievable on request | Retention policy plus a retrieval test | Operations |
Two rows go missing most. Sanctions list logs, because list refreshes run as a background job nobody watches (the ongoing sanctions screening guide covers what to log). And tuning records, because rule changes ship like ordinary code. Route both through one approval step.
Good practice shows the program understands its own output. The table below is drawn from the FCA Financial Crime Guide's good and poor practice examples on monitoring, paraphrased.
| Area | Good practice | Poor practice |
|---|---|---|
| Monitoring design | Looks at customer behavior as a whole, at several levels of aggregation | Single-transaction thresholds used where they don't fit the risk |
| Rule calibration | The firm can explain the rationale for each rule | Rules are poorly calibrated and their rationale is unclear |
| New approaches | New monitoring methods are piloted and tested before replacing old ones | Systems are swapped without comparing alert quality |
| Control framework | Management oversees performance and resolves issues | The control framework around automated monitoring is weak |
| Customer explanations | Staff test explanations against evidence | Staff accept a customer's explanation at face value |
| Use of results | Monitoring results show whether due diligence is still adequate | Little evidence that unusual transactions reach the compliance officer |
One more contrast that isn't from the FCA guide, but that examiners everywhere probe: a customer risk rating that refreshes on triggers (new corridor, volume jump, ownership change) versus a rating set once at onboarding and never touched. The second is a snapshot, not a control.
Under 31 CFR 1022.320, a US MSB must report suspicious transactions that involve or aggregate at least USD 2,000, no later than 30 calendar days after initial detection. It keeps the SAR and supporting documents for five years from filing. Timelines differ in other jurisdictions, so check the local rule for each license.
The 30-day clock is where programs get caught. Examiners compare three dates in every sampled case: when the alert fired, when someone decided it was suspicious, and when the SAR was filed. Long unexplained gaps between them are findings even if the filing itself was "on time."
FinCEN's October 2025 FAQs clarified two points that many programs over-engineered:
When an internal deadline slips, escalate it, don't hide it:
A 30-day plan turns "we think we're ready" into an indexed evidence folder. Run it before a scheduled exam, a partner bank review, or a funding round's compliance diligence.
Illustrative example. A fintech pulls 40 closed alerts from the last quarter as a mock exam sample. Six have no closure reason, three were closed by the analyst who also tuned the rule, and one SAR shows 41 days between alert and filing with no note. That's ten findings from one sample, and all ten are documentation gaps a regulator would find in the first week. The fix took two weeks: a mandatory closure reason field, a separation rule for tuning and review, and an aging alert on open cases. These numbers are illustrative, not drawn from a real program.
Answer completely, once, with documents rather than assertions. A request for information (RFI) from a regulator, partner bank, or payment provider usually covers a customer or a transaction, and a partial answer invites a second round.
Prepare these before you need them:
Response windows are set by whoever asks, and they vary from hours to weeks. BlindPay, for example, gives partners 27 days to answer a customer KYC or KYB request for information before the customer is automatically rejected. The window is printed on the request. Read it on day one, not day twenty. Travel Rule data gaps follow their own hold and return logic, covered in the travel rule workflow guide.
The common mistakes are records that don't explain decisions and controls that nobody re-checks.
BlindPay is registered with FinCEN as a money services business and lists its registrations on the licenses page. KYC, KYB, sanctions screening, travel rule compliance, and transaction monitoring run inside the API before money moves, so each customer and payment carries a status rather than a decision buried in email.
For partners, that means the evidence trail starts in the data. Customers move through documented statuses such as verifying, approved, compliance_request, and rejected, described in the KYC reference. RFIs can be handled through the RFI API, which returns the deadline as expires_at. Flagged payments land on hold for manual review, as described in on-hold transactions. Your own AML program remains yours to document; these records make that easier to evidence.
Pull 25 closed alerts from last month and try to rebuild each decision from the records alone. Every case you can't rebuild is a finding waiting for an examiner. Start the 30-day plan with those.
This article is general information, not legal advice.
Blockchain payments are legal for businesses in the US, EU, UK, Brazil, and Mexico, under different rules. What each country regulates, as of October 2026.
Stablecoin transfers settle final in minutes and cannot be reversed. That finality proves custody at every step, but it also opens a fraud gap on the fiat side of the payment.
A side-by-side comparison of automated and manual KYC/KYB for fintechs: onboarding time, false-positive rates, cost per verification, scaling across jurisdictions, and audit-trail quality, plus the cases where a human reviewer is still required.