# Transaction Monitoring Scenario Specification: [Scenario ID and name] > Specification for one transaction monitoring (TM) scenario: the > typology it targets, how it maps to the AML/CFT risk assessment, its > business logic, parameters and thresholds, data inputs and lineage, > population and segmentation, threshold calibration with > above-the-line and below-the-line testing, expected alert volumes, > alert handling, validation, tuning history and approval. It supports > the scenario documentation that New York 3 NYCRR Part 504 (section > 504.3) requires of regulated institutions, the ongoing monitoring > duty under current EU national law and, from 2027-07-10, Article 26 > of Regulation (EU) 2024/1624 (AMLR), suspicious activity reporting > under 31 CFR 1020.320, and model risk governance under SR 26-2 > (2026-04-17). Replace every `[bracketed]` value and every row marked > *Example*. Obtain the regulations for the normative text and check > the consolidated versions. This is a document format, not legal, > compliance or financial advice. ## Document control | Field | Value | |---|---| | Document ID | [TM-SPEC-014] | | Scenario ID | [TM-SCN-014] | | Scenario name | [Rapid movement of funds (pass-through)] | | Monitoring system and version | [System name, version] | | Entities and branches in scope | [List] | | Version | [2.0] | | Status | [Draft / In review / Approved / In production / Retired] | | Owner | [@head-of-fcc-analytics] | | Approvers/reviewers | [@mlro], [@bsa-officer-us-branch], [@model-risk-management], [@data-owner], [@internal-audit] | | Model risk tier | [Tier 1 / 2 / 3, per MRM policy] | | Go-live date of this version | YYYY-MM-DD | | Last updated | YYYY-MM-DD | | Next scheduled tuning review | YYYY-MM-DD | | Classification | [Confidential: restricted, scenario logic must not be disclosed outside need-to-know] | ### Approvals | Role | Name | Decision | Date | |---|---|---|---| | MLRO (EU) | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD | | BSA/AML officer (US branch) | [@name] | [Decision] | YYYY-MM-DD | | Model risk management (independent review) | [@name] | [Validation outcome] | YYYY-MM-DD | | Head of financial crime operations (capacity sign-off) | [@name] | [Decision] | YYYY-MM-DD | ### Revision history | Version | Date | Author | Change | |---|---|---|---| | 1.0 | YYYY-MM-DD | [@name] | *Example:* Scenario introduced for retail and SME segments | | 2.0 | YYYY-MM-DD | [@name] | *Example:* Retail credit threshold lowered from EUR 10,000 to EUR 9,000 after below-the-line testing (section 8.4) | ## Contents - [1. Scenario summary and risk mapping](#1-scenario-summary-and-risk-mapping) - [2. Regulatory basis](#2-regulatory-basis) - [3. Typology and red flags](#3-typology-and-red-flags) - [4. Business logic](#4-business-logic) - [5. Parameters and thresholds](#5-parameters-and-thresholds) - [6. Population and segmentation](#6-population-and-segmentation) - [7. Data inputs and lineage](#7-data-inputs-and-lineage) - [8. Calibration and tuning](#8-calibration-and-tuning) - [9. Expected alert volumes and capacity](#9-expected-alert-volumes-and-capacity) - [10. Alert handling and investigation](#10-alert-handling-and-investigation) - [11. Testing and validation](#11-testing-and-validation) - [12. Performance monitoring](#12-performance-monitoring) - [13. Tuning history](#13-tuning-history) - [14. Approval and certification evidence](#14-approval-and-certification-evidence) - [15. Traceability matrix](#15-traceability-matrix) - [16. Glossary and references](#16-glossary-and-references) - [Standard and licence note](#standard-and-licence-note) ## 1. Scenario summary and risk mapping | Field | Value | |---|---| | Scenario ID | TM-SCN-014 *(Example)* | | Typology | Rapid movement of funds through an account (pass-through), typical of money mule accounts, funnel accounts and layering | | Risk assessment link | *Example:* AML business risk assessment 2026, risks ML-R-07 (money mules in retail current accounts, residual High) and ML-R-11 (SME accounts used for layering, residual Medium) | | Detection type | Rule-based, post-execution, daily batch | | Segments | Retail personal current accounts; SME business accounts | | Coverage gap it closes | *Example:* Real-time fraud controls stop some authorised push payment fraud at the victim's bank, but do not detect the receiving mule account's pattern over several days | | Related scenarios | TM-SCN-009 (cash structuring), TM-SCN-021 (high-risk country flows) | TM-SCN-014 looks for accounts where money arrives from several sources and leaves again quickly, leaving little balance behind. That pattern is common in mule accounts used to receive proceeds of fraud, in accounts used to collect funds for a third party, and in layering through business accounts that have no matching trading activity. The scenario does not decide that the activity is suspicious; it selects accounts for a human investigator to review against the customer's profile. ## 2. Regulatory basis | Jurisdiction | Requirement | Reference | Status (as of 2026-10, check local law) | |---|---|---|---| | FATF | Ongoing due diligence on the business relationship; reporting of suspicious transactions | Recommendation 10; Recommendation 20 (names only) | Standard | | EU (current) | Ongoing monitoring of the business relationship and transactions; reporting suspicions to the FIU | Directive (EU) 2015/849 Articles 13(1)(d) and 33, as transposed in [Member State] law | In force until replaced | | EU (from 2027-07-10) | Ongoing monitoring and transaction scrutiny; reporting of suspicions; prohibition of disclosure | Regulation (EU) 2024/1624 Articles 26, 69 and 73 | Applies from 2027-07-10 | | US (federal) | SAR filing within 30 calendar days of initial detection of facts that may constitute a basis for filing, that is, the determination after prompt review that activity may be suspicious (up to 60 days if no suspect is identified) | 31 CFR 1020.320(b)(3) | In force | | US (federal) | AML programme with internal controls | 31 CFR 1020.210 | In force; FinCEN programme rule NPRM of 2026-04-07 is a proposal only | | US (federal) | SAR practice clarifications, including no requirement to document a decision not to file and no fixed continuing activity review cadence | FinCEN and agencies SAR FAQs, 2025-10-09 | Guidance | | New York | Transaction monitoring programme: risk-based scenarios with thresholds, end-to-end testing, documentation of assumptions, parameters and thresholds, alert protocols, ongoing analysis; data and governance elements; annual compliance finding by 15 April | 3 NYCRR 504.3(a), 504.3(c), 504.4 | In force since 2017-01-01 | | US (model risk) | Revised Guidance on Model Risk Management; supersedes SR 11-7 and SR 21-8; OCC Bulletin 2026-13 also rescinds OCC Bulletin 2021-19 on model risk for BSA/AML systems | SR 26-2 (2026-04-17); OCC Bulletin 2026-13 | Guidance; TM tools are classified under the bank's own MRM policy | ## 3. Typology and red flags A pass-through account receives funds from people or businesses the account holder has no clear relationship with, and sends them on, often within hours, to other accounts, crypto-asset service providers, money remitters or cash withdrawals. Mules may be recruited through job adverts or social media, may be victims themselves, or may be complicit. In business accounts, the same pattern appears when a company receives and forwards funds without the purchases, payroll and supplier payments a real business would show. | Indicator ID | Indicator | Used in logic | Data source | |---|---|---|---| | IND-01 *(Example)* | Credits from several unrelated originators in a short window | Yes (P3) | Payments, counterparty resolution | | IND-02 *(Example)* | Most credited funds debited again within the window | Yes (P2) | Payments, balances | | IND-03 *(Example)* | Short holding time between credit and debit | Yes (P4) | Payments with timestamps | | IND-04 *(Example)* | Debits to crypto-asset service providers, remitters or cash | Score uplift | Merchant category, beneficiary type | | IND-05 *(Example)* | Activity far above the declared expected turnover | Score uplift | KYC profile | | IND-06 *(Example)* | Recently opened account or recently changed contact details | Score uplift | Account and CRM data | | IND-07 *(Example)* | Credits flagged by other banks as fraud recalls | Investigation step | Recall messages, fraud team | ## 4. Business logic For each account in scope, the scenario runs daily over a rolling window that ends on the run date. It sums the qualifying credits and debits in the window, counts distinct originators, computes the share of credits that left the account, and measures the value-weighted holding time. It raises an alert when all mandatory conditions are true, and adds a risk score that orders the alert queue. ```text FOR each account a IN population(segment s) ON run_date d: window = [d - W(s) + 1, d] credits = SUM(amount of qualifying credits to a in window) debits = SUM(amount of qualifying debits from a in window) originators = COUNT DISTINCT(resolved originator of credits in window) out_ratio = debits / credits (only if credits > 0) hold_hours = value-weighted mean hours between each credit and the debits that consume it (first in, first out) IF credits >= P1(s) AND out_ratio >= P2(s) AND originators >= P3(s) AND hold_hours <= P4(s) AND NOT suppressed(a, d) THEN raise alert with score = base + uplifts(IND-04, IND-05, IND-06) ``` Qualifying credits and debits exclude transfers between accounts of the same customer, loan disbursements and repayments with the bank, reversals and returned payments, and salary credits from employers on the payroll whitelist. Debits include outgoing transfers, card payments to crypto-asset service providers and remitters, and cash withdrawals. Amounts are in EUR; non-EUR transactions are converted at the booking-date reference rate. The holding time uses first in, first out matching: each debit consumes the oldest unconsumed credit. The value-weighted mean is the sum of matched amount times hours held, divided by the total matched amount. Suppression prevents a repeat alert on the same account within 30 days unless credits in the new window exceed those of the last alerted window by 50% or more. ## 5. Parameters and thresholds | Parameter | Meaning | Retail personal | SME business | Basis | |---|---|---|---|---| | W | Rolling window (calendar days) | 7 | 7 | *Example:* Investigated cases show 80% of pass-through cycles complete within 7 days | | P1 | Minimum qualifying credits (EUR) | 9,000 (was 10,000) | 50,000 | *Example:* Below-the-line test, section 8.4 | | P2 | Minimum out/in ratio | 0.80 | 0.85 | *Example:* SME accounts keep working balances; ratio raised to cut false positives | | P3 | Minimum distinct originators | 3 | 5 | *Example:* Single-source salary or rent flows excluded | | P4 | Maximum value-weighted holding time (hours) | 48 | 72 | *Example:* Calibrated on 2025 confirmed mule cases | | Suppression | Days before a repeat alert | 30 | 30 | Avoid duplicates of an open case | | Uplift IND-04 | Added to score | +20 | +15 | Expert judgement, reviewed in tuning | | Uplift IND-05 | Added to score when window credits exceed 3 times expected monthly turnover | +15 | +15 | KYC data | | Uplift IND-06 | Added to score when account is under 90 days old or contact details changed in the last 30 days | +10 | +10 | Account data | Assumptions *(Example)*: expected turnover in the KYC profile is current for at least 90% of accounts; originator resolution groups payments from the same IBAN and normalised name; reference rates are available for all booked currencies. If an assumption fails, record it in section 12 and assess the impact on coverage. ## 6. Population and segmentation The population is every open retail personal current account and every SME business account (annual turnover below EUR 10 million) at Fernhollow Bank's EU entities. Corporate, correspondent and private banking accounts are covered by other scenarios. The New York branch runs the same scenario on its retail deposit accounts with USD parameters set by its own calibration. | Segment ID | Segment | Accounts *(Example)* | Monthly qualifying credits, median (EUR) | Thresholds | |---|---|---|---|---| | SEG-R1 | Retail personal current accounts | 372,000 | 2,650 | Retail column | | SEG-S1 | SME business accounts | 9,600 | 41,000 | SME column | The example segments sit within Fernhollow Bank's 412,000 customers (400,000 retail and 12,000 corporate, of which 11,200 SME and commercial, 500 non-profit organisations, trusts and other, and 300 financial institution respondents): 372,000 retail customers hold a personal current account, and 9,600 of the 11,200 SME and commercial customers are SMEs under the turnover limit, one business account each. Segments are reviewed at each annual tuning. A new segment is needed when a group of customers behaves differently enough that a shared threshold either floods the queue or misses activity, for example student accounts or accounts of payment institutions using the bank for safeguarding. Segment boundaries need the same care as thresholds. An SME customer recorded as a retail customer is tested against the retail thresholds and will alert on ordinary trading; a retail customer recorded as SME hides behind higher thresholds. Run a quarterly check that segment codes in the KYC system match the product held and the turnover band, and report mismatches as a data quality issue under section 7. ## 7. Data inputs and lineage | Data ID | Source system | Fields | Transformation | Quality check | |---|---|---|---|---| | DAT-01 *(Example)* | Core banking postings | Account, amount, currency, booking date, time, transaction code | Mapping of transaction codes to credit and debit types | Daily count and sum reconciliation to the general ledger | | DAT-02 *(Example)* | Payments hub (ISO 20022 pacs.008, pacs.004) | Debtor and creditor name and account, agent BIC, remittance text | Originator resolution (IBAN plus normalised name) | Fill-rate check for debtor account above 99% | | DAT-03 *(Example)* | Card processing | Merchant category code, merchant name | Flag crypto-asset service providers and remitters | Reference list review quarterly | | DAT-04 *(Example)* | KYC system | Segment, expected monthly turnover, account open date, contact change date | Latest values per account | Staleness report: turnover older than review cycle | | DAT-05 *(Example)* | Market data | EUR reference rates | Conversion at booking date | Missing-rate alert | | DAT-06 *(Example)* | Payroll whitelist | Employer account identifiers | Exclusion | Quarterly review by Compliance | ```mermaid flowchart LR A[Core banking] --> E[Staging] B[Payments hub] --> E C[Card processing] --> E D[KYC system] --> E E --> F{Reconciliation and data quality checks} F -- Pass --> G[TM engine: TM-SCN-014] F -- Fail --> H[Hold run and raise data incident] G --> I[Alert queue] I --> J[Case management] ``` A failed reconciliation stops the run for the affected data and opens a data incident. When the run resumes, the scenario reprocesses the missed days so no window is skipped. Every change to a source system that touches the fields above goes through the change control in section 13 before release. ## 8. Calibration and tuning ### 8.1 Definitions A productive alert is an alert that an investigator escalated to a case for further investigation, whether or not a report followed. The productivity rate is the share of alerts that are productive. $$ \text{Productivity rate} = \frac{\text{productive alerts}}{\text{total alerts}} $$ Report productivity alongside the report conversion rate (alerts that led to a suspicious activity or transaction report). Productivity is a measure of alert quality, not a target to maximise: a scenario with very high productivity may have thresholds set too high and be missing activity. ### 8.2 Above-the-line testing Above-the-line (ATL) testing reviews alerts the scenario produced, by segment and by threshold band, to see where productive alerts concentrate. If almost all productive alerts sit in the highest bands, the threshold may be raised safely; if they spread evenly, keep it. ### 8.3 Below-the-line testing and sample size Below-the-line (BTL) testing runs the scenario with lowered thresholds and has investigators review a sample of the extra events that would have alerted. Sample size uses a zero-failure acceptance approach: to be confident at level $c$ that the productive rate in a band is below $p$ if no productive events are found, review at least $$ n = \left\lceil \frac{\ln(1-c)}{\ln(1-p)} \right\rceil $$ events. With $c = 0.95$ and $p = 0.02$, $n = \lceil -2.9957 / -0.0202 \rceil = 149$, rounded up to 150 *(Example)*. When productive events are found, the productive count in the band is estimated as $$ \hat{k}_{\text{band}} = N_{\text{band}} \times \frac{k}{n} $$ where $N_{\text{band}}$ is the number of events in the band, $k$ the productive events found in the sample, and $n$ the sample size. ### 8.4 Worked example: retail segment, six months to 2026-06-30 | Item | Value *(Example)* | |---|---| | ATL alerts at P1 = EUR 10,000 | 1,240 | | ATL productive alerts | 93 | | ATL productivity rate | 93 / 1,240 = 7.5% | | ATL alerts leading to a report | 21 (1.7%) | | BTL band 1: credits EUR 9,000 to below 10,000, events | 1,050 | | Band 1 sample, productive found | 150 reviewed, 6 productive (4.0%) | | Band 1 estimated productive events | 1,050 x 6 / 150 = 42 | | BTL band 2: credits EUR 8,000 to below 9,000, events | 1,380 | | Band 2 sample, productive found | 150 reviewed, 1 productive (0.67%) | | Band 2 estimated productive events | 1,380 x 1 / 150 = 9.2 | Decision rule *(Example)*: lower the threshold to a band when its productive rate is at least half of the ATL productivity rate. Half of 7.5% is 3.75%. Band 1 (4.0%) meets the rule, so P1 moves from EUR 10,000 to EUR 9,000. Band 2 (0.67%) does not, so the threshold stops at EUR 9,000. The single productive event in band 2 was reviewed by the MLRO and is covered by scenario TM-SCN-021, so no coverage gap remains. After the change, the expected alerts for six months are 1,240 + 1,050 = 2,290, with an expected 93 + 42 = 135 productive alerts, a productivity rate of 135 / 2,290 = 5.9%. ### 8.5 Tuning cycle Tune each scenario at least every 12 months, and sooner after a change in the risk assessment, a new product, a material change in alert productivity, or a data incident that affected coverage. Each tuning exercise records the data period, the tests run, the results, the decision and the approval, and adds a row to section 13. ## 9. Expected alert volumes and capacity | Item | Before (P1 = EUR 10,000) | After (P1 = EUR 9,000) | |---|---|---| | Alerts per month (6-month average) | 1,240 / 6 = 206.7 | 2,290 / 6 = 381.7 | | Level 1 review time per alert *(Example)* | 25 minutes | 25 minutes | | Level 1 hours per month | 206.7 x 25 / 60 = 86.1 | 381.7 x 25 / 60 = 159.0 | | Analyst capacity at 150 productive hours per month | 0.57 FTE | 1.06 FTE | The head of financial crime operations confirms that 1.1 FTE is assigned to this scenario's queue from the go-live date, and that the level 1 service level of 10 business days from alert to disposition *(Example)* can be met. ## 10. Alert handling and investigation ```mermaid flowchart TD A[Alert TM-SCN-014] --> B[Level 1: review profile and window activity] B --> C{Explained by known legitimate activity?} C -- Yes --> D[Close with rationale and evidence] C -- No --> E[Escalate to case: level 2 investigation] E --> F[Contact fraud team on recalls; request information if appropriate] F --> G{Suspicion?} G -- No --> H[Close case with rationale] G -- Yes --> I[Prepare SAR or STR] I --> J[MLRO or BSA officer decision and filing] J --> K[Account actions: restrict, exit, continuing review] ``` The level 1 reviewer compares the window activity with the expected profile, looks at the originators and beneficiaries, checks recent fraud recalls against the account, and records a rationale that someone else could follow. Acceptable closure reasons are limited to a controlled list, such as documented change of employment or business, verified sale of a personal asset, or family support with evidence. A level 2 investigator reviews 12 months of activity, linked accounts and devices, and open-source information, and may ask the fraud team to contact originating banks. When a report is filed, the case file follows the SAR/STR Narrative template (`compliance/sar-str-narrative`). Investigators must not tell the customer that an alert, case or report exists. In the US, the SAR must be filed within 30 calendar days of the date of initial detection of facts that may constitute a basis for filing (31 CFR 1020.320(b)(3); up to 60 days if no suspect is identified). The clock starts when the institution determines that the activity may be suspicious, not when the alert fires and not when the case is escalated. The institution records this as [the date the level 2 investigator, after a prompt review, concludes that the activity may be suspicious] *(Example)*. Set a service level for the review itself (for example 30 days from alert to decision) and do not delay escalation or review to postpone the clock; record the date and the reviewer in the case. ## 11. Testing and validation Pre-implementation testing confirms that the logic does what section 4 says: testers build known cases (alerting and non-alerting, edge values exactly at each threshold, excluded transaction types, currency conversion) and confirm results in a test environment that uses production-like data. Post-implementation testing confirms, in the first month, that production alert counts match the calibration forecast within a tolerance (for example plus or minus 20%) and that reconciliations pass every day. Independent validation follows the institution's model risk policy (`finance/model-risk-management-policy`). Under SR 26-2 the bank decides whether a rule-based scenario is a model and which tier it sits in; OCC Bulletin 2026-13 rescinded the 2021 interagency statement on model risk for BSA/AML systems, so the general MRM policy governs. A validation covers conceptual soundness of the typology and logic, data integrity, implementation testing, outcome analysis (ATL and BTL results), and ongoing monitoring; record findings in the Model Validation Report (`ai-data/model-validation-report`). | Test ID | Test | When | Result *(Example)* | |---|---|---|---| | TST-01 | Logic test with 64 constructed cases, including threshold edges | Before go-live of v2.0 | 64 of 64 passed | | TST-02 | Data lineage walk-through, source to alert, for 25 sampled alerts | Before go-live | All fields traced | | TST-03 | Reconciliation of record counts per run | Daily | 0 breaks in first month | | TST-04 | Post-implementation volume check | First month | 372 alerts vs forecast 381.7 (within 20%) | | TST-05 | Independent validation | Before go-live, then per tier cycle | Approved with one low finding | ## 12. Performance monitoring | KPI ID | Indicator | Threshold for review *(Example)* | Frequency | |---|---|---|---| | KPI-01 | Alerts per month vs forecast | Outside plus or minus 30% | Monthly | | KPI-02 | Productivity rate | Below 3% or above 20% for two months | Monthly | | KPI-03 | Report conversion rate | Trend only | Quarterly | | KPI-04 | Alerts older than service level | Any | Weekly | | KPI-05 | Data quality breaks affecting the scenario | Any | Daily | | KPI-06 | Share of reports on this typology originating from other sources (referrals, law enforcement requests) | Rising trend | Quarterly | KPI-06 is a coverage signal: if many mule cases reach the bank through fraud recalls or law enforcement requests but not through this scenario, the scenario is missing activity and needs tuning even if its own productivity looks healthy. The fraud detection platform (`system-design/design-fraud-detection`) and this scenario should share confirmed mule outcomes so each improves the other. ## 13. Tuning history | Change ID | Date | Change | Evidence | Approved by | |---|---|---|---|---| | CHG-014-01 *(Example)* | 2025-03-01 | Scenario introduced, retail P1 EUR 10,000, SME P1 EUR 50,000 | Calibration report 2025-02 | MLRO | | CHG-014-02 *(Example)* | 2025-11-15 | Payroll whitelist exclusion added | False positive analysis, 18% of alerts were payroll | MLRO | | CHG-014-03 *(Example)* | 2026-08-01 | Retail P1 lowered to EUR 9,000 | Section 8.4 BTL results; capacity sign-off | MLRO, MRM | Keep the configuration export for each version alongside this table, so that the exact parameters in force on any date can be shown to an examiner or a court. Never delete a retired version: when a scenario is replaced, mark it Retired, record the successor scenario, and keep the specification for at least the record retention period that applies to the alerts it produced. Emergency changes (for example a temporary suppression after a data incident flooded the queue) need the same record, an expiry date and a follow-up review of any events the change suppressed. ## 14. Approval and certification evidence The approval pack contains this specification, the calibration report, the test results, the validation report and the capacity sign-off. For the New York branch, the BSA officer files the pack with the Part 504 evidence for the year, and any area needing material improvement is recorded with its remediation plan, as 504.3(d) requires. ## 15. Traceability matrix | Requirement | Reference | Section | Evidence | |---|---|---|---| | Based on the risk assessment | 3 NYCRR 504.3(a)(1); FATF R.1 | 1 | Risk IDs ML-R-07, ML-R-11 | | Detection scenarios with thresholds | 504.3(a)(4) | 4, 5 | Logic, parameter table | | Documentation of assumptions, parameters, thresholds | 504.3(a)(6) | 5 | Parameter table, assumptions | | End-to-end pre- and post-implementation testing | 504.3(a)(5) | 11 | TST-01 to TST-04 | | Alert investigation protocols | 504.3(a)(7) | 10 | Workflow, closure codes | | Ongoing analysis of relevance | 504.3(a)(8) | 8, 12 | Tuning reports, KPIs | | Data sources, integrity, extraction and loading | 504.3(c)(1) to (3) | 7 | Data table, reconciliations | | Governance and change management | 504.3(c)(4) | 13, 14 | Tuning history, approvals | | Ongoing monitoring of transactions | Directive (EU) 2015/849 Art. 13(1)(d); AMLR Art. 26 from 2027-07-10 | 4 to 10 | Scenario output | | Suspicious activity reporting | 31 CFR 1020.320; Directive (EU) 2015/849 Art. 33; AMLR Art. 69 from 2027-07-10 | 10 | Case files | | Model risk governance | SR 26-2; OCC Bulletin 2026-13 | 11 | Validation report | ## 16. Glossary and references | Term | Meaning | |---|---| | Scenario | A defined rule or model that selects activity for review | | Above-the-line (ATL) | Events that met the threshold and generated alerts | | Below-the-line (BTL) | Events just under the threshold, reviewed to test whether activity is missed | | Productive alert | Alert escalated to a case for investigation | | Out/in ratio | Debits divided by credits in the window | | Holding time | Time between funds arriving and leaving, weighted by value | | Money mule | A person whose account is used to receive and move proceeds of crime | | Tuning | Review and adjustment of logic, parameters or thresholds | References: - New York 3 NYCRR Part 504, Banking Division Transaction Monitoring and Filtering Program Requirements and Certifications (effective 2017-01-01), sections 504.2 to 504.4. - 31 CFR 1020.210 and 1020.320, ecfr.gov; FinCEN and federal banking agencies SAR FAQs (2025-10-09); FinCEN AML/CFT programme NPRM (2026-04-07, proposed). - Board of Governors of the Federal Reserve System, SR 26-2 Revised Guidance on Model Risk Management (2026-04-17); OCC Bulletin 2026-13. - FFIEC BSA/AML Examination Manual, suspicious activity monitoring and reporting sections. - Directive (EU) 2015/849 Articles 13 and 33; Regulation (EU) 2024/1624 Articles 26, 69 and 73, eur-lex.europa.eu. - FATF Recommendations 1, 10 and 20 (names only). ## Standard and licence note Based on New York 3 NYCRR Part 504, 31 CFR Chapter X, SR 26-2 and the FFIEC BSA/AML Examination Manual (US government works, public domain, or state regulations cited by section), and on Directive (EU) 2015/849 and Regulation (EU) 2024/1624 published on EUR-Lex (reuse under Commission Decision 2011/833/EU). FATF Recommendations are cited by number only. The scenario, logic, parameters, calibration method, worked example and text are original; no regulatory text or industry scenario library is reproduced. Fernhollow Bank and all figures are fictional. Check the current official version of each source and the national transposing law before use. Template licence: MIT.