Transaction Monitoring Scenario Specification Template (NYDFS Part 504, AML)

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

Approvals

Revision history

Contents

• 1. Scenario summary and risk mapping
• 2. Regulatory basis
• 3. Typology and red flags
• 4. Business logic
• 5. Parameters and thresholds
• 6. Population and segmentation
• 7. Data inputs and lineage
• 8. Calibration and tuning
• 9. Expected alert volumes and capacity
• 10. Alert handling and investigation
• 11. Testing and validation
• 12. Performance monitoring
• 13. Tuning history
• 14. Approval and certification evidence
• 15. Traceability matrix
• 16. Glossary and references
• Standard and licence note

1. Scenario summary and risk mapping

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

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.

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.

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

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.

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

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.

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

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

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

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

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

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).

12. Performance monitoring

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

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

16. Glossary and references

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.