HIP-306: AML Transaction Monitoring, Screening and Case Management. Status Draft. Hanzo's own standard — read this before implementing against it.
This HIP specifies what an anti-money-laundering transaction monitoring, sanctions screening and case management system must do to be lawfully operable by a regulated financial institution, and therefore sellable to one. Every requirement here is traceable to a published standard or rule. Nothing here is a design preference.
The distinction this document exists to enforce is the one between a system that has rules and a system that discharges an obligation. A rule engine that evaluates expressions is a week of work. An AML system is a set of promises to a supervisor: that the monitoring covers the institution's risks, that the screening runs against current lists, that every alert can be explained years later, that records survive five years, and that the model was validated by someone who did not build it. Those promises are what this HIP specifies.
AML software fails audit in characteristic ways, and they are not the ways engineers expect. It is rarely throughput. It is: the screening list silently stopped loading; the aggregation window was computed over a truncated fetch; the alert cannot be reproduced because the rule was edited without a version; the amount on the report was derived rather than summed; nobody can say who approved the threshold. Each of those is a control failure that a supervisor will find and an engineer will not, because each looks like working software from the inside.
A specification is the countermeasure. If a requirement is written down with its citation, it can be tested, and a test that fails is cheaper than a consent order.
The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in RFC 2119.
Institution means the regulated entity operating the system. Operator means Hanzo or a customer running the engine. Subject means the natural or legal person whose activity is monitored. Alert means a machine-generated indication that activity matched a detection rule. Case means a human-owned investigation record.
A note on obligation-bearers: almost every rule cited here binds the institution, not the software. The software's duty is to make the institution's compliance possible and evidenceable. Where this HIP says the system MUST do something, it means the system must not be the reason the institution fails.
AML-SCOPE-1. The system MUST treat monitoring, screening, risk rating, case management and recordkeeping as one control surface, not five features. US supervisors define the object of examination broadly: a bank's "suspicious activity monitoring and reporting systems" comprise its "policies, procedures, or processes to identify, research and report unusual activity" and "are critical internal controls" [1]. A component that is individually correct but not evidenced as part of that control surface does not discharge the obligation.
AML-SCOPE-2. The system MUST NOT assume a single jurisdiction. Obligations that look equivalent are not. The same $3,000 funds-transfer recordkeeping duty is written twice in US law in two different vocabularies — 31 CFR 1010.410(e) governs non-bank financial institutions in terms of transmittor, transmittal order and recipient, while 31 CFR 1020.410(a) governs banks in terms of originator, payment order and beneficiary [2][3]. The canonical data model MUST represent one concept per role and map both legal vocabularies onto it. Emitting a bank's records in non-bank terminology is a finding.
AML-SCOPE-3. Where an obligation is split between a functional regulator and a prudential regulator, the system's conformance evidence MUST cite both. Suspicious activity reporting is the canonical case: FinCEN's rule at 31 CFR 1020.320(a)(2) sets a single flat threshold of "at least $5,000 in funds or other assets" [4], while the familiar tiered thresholds live in each banking agency's own rule — 12 CFR 21.11(c) for national banks, and identically at 12 CFR 353.3 (FDIC), 12 CFR 208.62 (Federal Reserve) and 12 CFR 748.1(d) (NCUA) [5]. A bank is subject to both. Citing only the FinCEN rule understates the duty.
AML-TM-1. Monitoring MUST be risk-based and MUST be driven by a documented risk assessment, per FATF Recommendation 1 and, in the UK, MLR 2017 reg 18 [6][7]. Coverage is therefore not a fixed list of rules; it is the demonstrated mapping from assessed risks to deployed detections. The system MUST be able to render that mapping as an artefact: for each assessed risk, the rules that address it.
AML-TM-2. Ongoing monitoring is an express legal requirement, not an implication. In the US it is stated at 31 CFR 1020.210(a)(2)(v)(B), which requires "conducting ongoing monitoring to identify and report suspicious transactions and, on a risk basis, to maintain and update customer information" [8]. In the UK it is MLR 2017 reg 28(11) [9]. The system MUST monitor continuously, not only at onboarding.
AML-TM-3. Detection MUST cover, at minimum, the typologies the institution's risk assessment identifies, and the rule library MUST be organised by typology so that coverage gaps are visible. Structuring MUST be covered: 31 U.S.C. 5324 makes it an offence to structure transactions to evade reporting, and 31 CFR 1010.314 states the prohibition [10]. Note that structuring has no intent threshold expressed as an amount — a detection tuned only to a narrow band immediately below a reporting threshold is under-inclusive.
AML-TM-4. Every detection MUST be evaluated against the correct threshold operator, not merely the correct number. This is a recurring and silent source of non-compliance. Two US thresholds that appear similar are opposite in inclusivity: currency transaction reporting applies to a transaction "in currency of more than $10,000" (exclusive) [11], while funds-transfer recordkeeping and the Travel Rule apply to a transmittal "in the amount of $3,000 or more" (inclusive) [2]. A conformance test MUST assert behaviour at exactly the boundary value for every threshold rule, in both directions.
AML-TM-5. Currency MUST be normalised before any monetary threshold is applied, and the normalisation MUST be auditable. A threshold expressed in USD that is compared against a raw foreign-currency amount is both over- and under-inclusive depending on the pair. Where a rate is used, the system MUST record the rate and its as-of time with the alert, because the alert must later be reproducible (AML-EXP-2). Hard-coded static rates MUST NOT be used for threshold decisions.
AML-TM-6. Aggregation duties MUST be implemented with the scope the rule states. US currency-transaction aggregation is at 31 CFR 1010.313(b) and reaches transactions "by or on behalf of any person", not merely the same named person [12]. Implementing this as same-subject aggregation narrows the duty and will miss the third-party and agent cases the rule exists to catch.
AML-TM-7. Travel-rule obligations MUST be implemented per jurisdiction and per asset class, because the thresholds genuinely differ and one of them is zero.
In the US, the pass-on duty applies to transmittals of $3,000 or more and the elements are enumerated at 31 CFR 1010.410(f)(1)(i)–(vii) [2]. One element is routinely omitted from implementations because summaries drop it: (vii) "either the name and address or numerical identifier of the transmittor's financial institution". The same duty falls on every intermediary institution in the chain, per 1010.410(f)(2) [2].
In the EU, Regulation (EU) 2023/1113 has applied since 30 December 2024 and repealed Regulation (EU) 2015/847 from that date; beneficiary information elements are at Art 14(2) [29]. Critically, there is no de-minimis threshold for crypto-asset transfers — the regulation deliberately declines to exempt domestic low-value crypto transfers, consistent with treating all crypto-asset transfers as cross-border, and its Art 37 review clause asks whether such thresholds should be introduced [29]. A system that applies a EUR 1 000 floor to crypto transfers is therefore under-inclusive in the EU. That figure appears in the crypto context only for the separate purpose of self-hosted-address ownership verification.
In the UK, the crypto threshold changed on 30 June 2026: SI 2026/621 reg 32 substitutes "£800" for "1,000 euros" in MLR 2017 reg 64C(4) [31]. A new reg 34A, imposing enhanced due diligence obligations on cryptoasset firms and correspondent relationships, commences 1 February 2027 [31]. Threshold values MUST therefore be jurisdiction-scoped and effective-dated, not global constants.
AML-TM-8. Legal-instrument references MUST be unambiguous. "AMLD6" MUST NOT be used in specifications, configuration or code: in pre-2024 usage it denotes Directive (EU) 2018/1673 (the criminal-law directive) and in 2024-package usage it denotes Directive (EU) 2024/1640. CELEX identifiers MUST be used instead — 32018L1673 and 32024L1640 respectively [30].
AML-TM-9. Deferred. A typology catalogue enumerating FinCEN advisories and their published red flags is required to complete this section and is deliberately not asserted here. See §12.
AML-AGG-1. Where a detection depends on activity over a window, the aggregation MUST be computed over the complete set of qualifying records in that window. If the implementation retrieves candidate records by key and then filters by time, the retrieval MUST NOT be silently truncated by a fetch limit. A capped fetch turns a "total in 24 hours" into "total among the first N records", which is a wrong answer presented as a right one. Where a cap is unavoidable, the system MUST mark the aggregate as incomplete and MUST surface that state to the analyst and to the alert record.
AML-AGG-2. Where aggregates are precomputed or cached for latency, the system MUST record the staleness of the aggregate used in each decision. An aggregate that a background process maintains is, by construction, capable of being behind. That is an acceptable engineering trade-off and an unacceptable undisclosed one: an analyst and an examiner must both be able to see that the number was as of a time.
AML-AGG-3. Threshold values MUST be institution-configurable and MUST NOT be compiled in. FATF prescribes no numeric alert threshold, and deliberately so; the calibration is a function of the institution's risk appetite and portfolio. A vendor default is a starting point, never a control. Every threshold MUST carry an owner and an effective date.
AML-AGG-4. Helper functions available to the rule language MUST fail closed and MUST be observably unimplemented if unimplemented. A helper that returns a plausible constant — false for a screening predicate, true for a completeness predicate — silently disables every rule that depends on it while the rule continues to appear enabled in the UI and the API. The system MUST NOT ship a rule whose dependencies are stubbed; a rule MUST be either functional or explicitly disabled, and the API that lists rules MUST distinguish the two.
AML-SCR-1. Targeted financial sanctions MUST be applied without delay. That phrase is the operative standard in FATF Recommendations 6 and 7, and it is a timeliness requirement on the institution's screening, not merely on its policy [6]. Screening that runs on a daily batch cycle does not satisfy a without-delay obligation for payment interdiction.
AML-SCR-2. The system MUST ingest, at minimum, the OFAC SDN and consolidated lists, the UN Security Council consolidated list, the EU consolidated (CFSP) list and the UK sanctions list, each in its publisher's own current format. These formats are not interchangeable: they differ in record type, identifier space, name decomposition and date representation. A single parser applied to four different schemas will produce empty or corrupt results for at least three of them, and it will do so quietly.
The UK source requires specific attention because it changed recently and silently. The OFSI Consolidated List closed on 28 January 2026; the gov.uk publication is withdrawn and states that "from 28 January 2026 the UK Sanctions List is the only source for all UK sanctions designations" [35]. The canonical source is now the FCDO UK Sanctions List [36]. An implementation still pointing at the OFSI ConList.csv/ConList.xml assets has been ingesting nothing since that date while continuing to report successful screening — the exact failure mode AML-SCR-3 exists to catch.
AML-SCR-2a. Where a publisher offers both a structured and a flat export, the system MUST ingest the structured one. This is not a preference. OFAC's flat files omit weak aliases entirely — the strong-alias count in SDN.XML equals the row count of ALT.CSV exactly, so weak aliases exist only as quoted fragments inside a free-text Remarks column that is itself truncated at 1,000 characters with overflow in a separate file [7][37]. Ingesting CSV therefore discards thousands of alias records and corrupts the remainder.
AML-SCR-2b. The system MUST distinguish the sanction measure from mere presence on a list. The UK list expresses measures as explicit boolean indicators including AssetFreeze, TravelBan and ArmsEmbargo [36]; a travel-ban-only designation is not an asset-freeze target, and interdicting a payment on it is a false positive with customer-detriment consequences. Screening for payment blocking MUST gate on the asset-freeze measure.
AML-SCR-3. List ingestion MUST be verified per source on every refresh, and a failure MUST be treated as a control incident. The system MUST assert, per source and per run: that the fetch succeeded, that the parsed record count is within an expected band, and that the count did not drop discontinuously. It MUST alarm on staleness beyond a configured interval, and it MUST NOT report a screening result as clean when the list backing it failed to load. This is the single most dangerous failure mode in the entire system, because an empty list produces zero hits and zero hits is indistinguishable from compliance. It is an observed failure mode in shipped AML products in three distinct forms: source URLs that now 404 because the list was withdrawn (AML-SCR-2), live URLs whose payload the parser silently rejects, and a successful load into a store that the screening path does not read.
AML-SCR-3a. Change detection SHOULD use the publisher's own delta mechanism where one exists, rather than diffing full exports. OFAC retired its RSS feed on 31 January 2025 and publishes dated delta files carrying explicit action="add|remove|update" semantics at entity and sub-element level [38]. Publication cadence is irregular and MUST NOT be assumed: OFAC states notices may be published at any time, and the observed pattern is business-day publication with a median gap of two days and occasional gaps beyond a week [7]. A weekly refresh therefore breaches the without-delay obligation in AML-SCR-1.
AML-SCR-4. Screening MUST match on names and aliases and MUST NOT require exact equality. Fuzzy matching MUST be applied, and the technique, the matched name form and the threshold MUST be recorded with each result so a match can be defended and a non-match explained.
The baseline technique is not a matter of vendor invention: OFAC documents the algorithm its own Sanctions List Search uses — an edit-distance prefilter at 50% similarity, then Jaro-Winkler over the full name string and Soundex over split name parts, "returning the higher of the two scores" [39]. The underlying comparators have primary citations [49]. An implementation that adopts this combination can defend it by citation. A third algorithm was added in January 2021 which OFAC does not name; it MUST NOT be guessed at.
AML-SCR-4a. The match threshold MUST be institution-configurable and MUST NOT be compiled in. OFAC is explicit that it will not recommend one: "OFAC cannot make such a recommendation because each search has its own unique set of facts surrounding it. Users … must make their own match threshold determinations based upon their own internal risk assessments and established compliance practices" [39]. Wolfsberg likewise requires that a governance framework contain "the documented rationale for risk based decisions, such as those made in support of the creation of screening rules and threshold settings" [40]. A hard-coded constant is therefore a governance defect as well as an engineering one.
AML-SCR-4b. Weak and low-quality aliases MUST NOT be screened as primary match candidates, but MUST be retained and surfaced for alert adjudication. Both authorities agree and both give the same rationale. OFAC: "OFAC does not expect that persons will screen for weak AKAs, but expects that such AKAs may be used to help determine whether a 'hit' arising from other information is accurate" [7]. Wolfsberg: "It is not expected, nor is it typically productive, to screen against weak aliases" [40]. Screening every alias at equal weight is a principal driver of false positives and is contrary to published expectation.
AML-SCR-4c. Alternative spellings and transliterations of sanctioned jurisdictions and parties MUST be handled. OFAC names this as a distinct root cause of compliance failure — organisations that "did not account for alternative spellings of prohibited countries or parties … (i.e., Habana instead of Havana, Kuba instead of Cuba, Soudan instead of Sudan, etc.)" [41]. A jurisdiction check implemented as equality against a list of ISO codes does not satisfy this.
AML-SCR-5. Non-Latin and transliterated names MUST be normalised before comparison, using a documented standard rather than an ad-hoc character map. The system MUST apply Unicode normalisation — NFKC is the appropriate pre-comparison fold, as it collapses compatibility variants, full/half-width forms and ligatures (UAX #15) [42] — MUST compare at primary collation strength for accent- and case-insensitive equality (UTS #10) [43], and MUST defeat homoglyph substitution using the confusable skeleton defined by UTS #39 and its published confusables.txt [44][45]. A hand-maintained Cyrillic-to-Latin table is not a substitute: it is incomplete by construction and silently diverges from the published confusable set.
This is load-bearing, not theoretical. Non-Latin name forms are present in volume in the primary sources — the OFAC advanced export carries thousands of Cyrillic and Arabic name parts alongside Chinese, Hangul, Japanese, Greek, Georgian, Hebrew and Armenian, and the UK list carries Cyrillic, Arabic, Chinese, Hebrew, Georgian, Thai, Hangul, Khmer, Greek, Burmese and Lao [36][46]. Wolfsberg treats "support for the screening or transformation of data in non-Latin characters" as an explicit selection criterion for a screening application [40].
Where romanisation rather than normalisation is required, the system MUST name the scheme (ICAO Doc 9303 Part 3 for travel-document transliteration [33]; ISO 9 or BGN/PCGN for Cyrillic). The identities of these standards are settled; their canonical URLs were not retrievable during drafting and are marked accordingly in §15.
AML-SCR-6. Where a candidate match is found, the system MUST use the discriminating attributes the lists actually publish to raise or lower confidence: date of birth, nationality, place of birth, and identity document numbers. A screening interface that accepts a date of birth and then ignores it in the match decision is worse than one that does not accept it, because it implies a discrimination it does not perform. Discriminators MUST participate in scoring and MUST be shown in the result.
AML-SCR-6a. Date of birth MUST be modelled as an interval with a qualifier, not as a scalar. The UN list types every date as EXACT, APPROXIMATELY or BETWEEN and carries year-range fields for the latter [12]; OFAC's advanced model carries approximate flags and per-component fixity [46]. Comparing an approximate or ranged listed date against an exact customer date as though both were points produces both false negatives and indefensible false positives.
AML-SCR-6b. Identity-document structures MUST NOT be assumed to contain only identity documents. OFAC's idList is an untyped key-value bag whose types include gender, secondary-sanctions-risk notes, websites, email addresses, vessel MMSI numbers and digital-currency addresses alongside passports [7]. Modelling it as passport data mis-parses the majority of its contents — and discards the digital-currency addresses, which are directly actionable for crypto screening.
AML-SCR-7. The system MUST support screening beyond the four corners of the list. OFAC's 50 Percent Rule provides that "any entity owned in the aggregate, directly or indirectly, 50 percent or more by one or more blocked persons is itself considered to be a blocked person", and that such an entity's property is blocked "regardless of whether the entity itself is listed" [13]. Two qualifications matter for implementation: the rule turns on ownership, not control, so a controlled-but-under-50% entity is not automatically blocked though caution is urged [47]; and ownership aggregates across multiple blocked owners and resolves transitively through intermediate entities [48].
The engineering consequence is that the blocked population is strictly larger than the published list, and a name matcher alone cannot compute it. The system MUST maintain an ownership graph supporting transitive resolution and aggregation across multiple blocked owners, and MUST accept institution-supplied ownership data and internal watchlists as first-class screening sources. The published list is a seed set, not the answer.
AML-SCR-10. The screening application itself MUST be treated as within scope of model governance where the institution's framework so provides. Wolfsberg states that a screening application "may also be submitted for consideration as a model and, if so considered, any associated governance framework" applies, and requires "an independent risk based testing regime to ensure that the screening application generates expected alerts, threshold settings and/or screening rules" [40]. §9 therefore applies to the matcher, not only to any statistical scorer.
AML-SCR-11. There is no published regulator benchmark for sanctions screening false-positive rates, and the system MUST NOT be specified or marketed against one. No such benchmark was located from OFAC, OFSI, FATF or the FCA during drafting, and the widely repeated claim that 95–99% of sanctions alerts are false positives could not be traced to any primary source; it MUST NOT be cited. The institution MUST instead establish its own baseline false-positive and match rate, hold it under change control, and re-baseline after any change to lists, algorithm or thresholds — per Wolfsberg's independent-testing requirement [40] and OFAC's position that thresholds are the institution's own determination [39]. Where a name variation is found to have been previously undetected, a lookback with root-cause analysis MUST be performed [40].
AML-SCR-8. PEP status MUST be a resolved attribute of the subject, distinguishing foreign, domestic and international-organisation PEPs, and MUST extend to family members and close associates, per FATF Recommendation 12 [6]. In the UK, a person ceasing to be a PEP MUST continue to be treated under enhanced measures for at least 12 months, per MLR 2017 reg 35(9)(a) [14]. A PEP flag that is never populated because entity resolution is a stub means every PEP rule is inert; the system MUST NOT derive a subject record solely from an identifier present on the transaction.
AML-SCR-9. Screening results MUST be reproducible against the list version in force at decision time. The system MUST retain list versions, not only current state, because an alert raised today may be examined in three years against the list as it then stood.
AML-CRR-1. Each subject MUST carry a risk rating derived from documented factors, and the derivation MUST be reproducible. Customer due diligence obligations attach to the rating (FATF Recommendation 10; 31 CFR 1010.230 for beneficial ownership; MLR 2017 reg 33 for enhanced due diligence) [6][15][16].
AML-CRR-2. The rating MUST be refreshed on a schedule bounded by risk. The EU 2024 package makes this a hard engineering requirement rather than a policy aspiration: AMLR (EU) 2024/1624 Art 26(2) caps the review interval at one year for higher-risk customers and five years for all others [17]. The system MUST therefore implement a scheduler with per-tier caps and MUST evidence that reviews occurred within them.
AML-CRR-3. Enhanced due diligence triggers MUST be encoded with jurisdictional precision. The UK's trigger for unusual transactions at MLR 2017 reg 33(1)(f) is qualified — "unusually complex or unusually large in each case given the nature of the transaction" — which is narrower than a bare size test and differs from the EU formulation [16]. Sharing one hard-coded trigger across jurisdictions will be wrong in at least one of them.
AML-CRR-4. The rating MUST feed monitoring, not merely reporting. A risk rating that does not change which rules apply or which thresholds are used is decorative.
AML-ALT-1. Every alert MUST be durably persisted at the moment it is raised, before any response is returned to the caller. Alerts held only in process memory are lost on restart and cannot satisfy retention (§8). An in-memory alert store with capacity eviction is not a cache in this context; it is undisclosed destruction of records the institution is required to keep.
AML-ALT-2. Alert volume MUST be bounded by tuning, not by eviction. Where the system caps memory or storage, it MUST do so by refusing or shedding with an error that the operator can see, never by discarding already-raised alerts.
AML-ALT-3. The system MUST NOT allow a client-supplied identifier to cause unbounded growth in any store. Re-submission of the same transaction identifier MUST be idempotent or explicitly versioned.
AML-ALT-4. Aggregate risk scores MUST be monotone, bounded and informative. A score that saturates at its maximum for ordinary activity conveys no information and MUST be treated as a defect: if the modal transaction scores at the ceiling, the score cannot rank work. Scores MUST be validated against a labelled sample before deployment (§9) and their distribution MUST be monitored in production.
AML-ALT-5. Where a score is described as a weight of evidence, it MUST be a weight of evidence in the statistical sense (a log-odds contribution) or MUST be renamed. Naming a weighted sum after a specific statistical construct misleads model validators and is a documentation defect.
AML-ALT-6. Rule changes MUST be governed. A change to a detection rule, threshold or suppression MUST be versioned, attributed to an author, reviewed by a second party, and carry an effective date; and the system MUST record which rule version produced any given alert. Independent testing of the AML program is required at 31 CFR 1020.210(a)(2)(ii) and independent audit at MLR 2017 reg 21(1)(c), and neither is possible if the rule that fired cannot be recovered [8][18].
AML-CASE-1. Suspicious activity MUST be reportable within the statutory deadline, and the system MUST make the clock explicit. In the US the SAR must be filed "no later than 30 calendar days after the date of the initial detection", with "an additional 30 calendar days to identify a suspect" and a hard ceiling of "in no case ... more than 60 calendar days" [5][4]. The system MUST record the initial detection date as a first-class field, because every deadline is computed from it, and MUST surface time remaining. Note a real drafting divergence to respect: NCUA's rule at 12 CFR 748.1(d)(2)(i) says "more than 60 days", omitting "calendar" [5].
AML-CASE-2. Currency transaction reports MUST be filed within 15 days, per 31 CFR 1010.306(a)(1) [19].
AML-CASE-3. Reported amounts MUST be computed from the underlying transactions, never derived from a risk score or any other proxy. A monetary field on a regulatory report is an assertion of fact. Deriving it arithmetically from an internal score produces a false statement on a filing.
AML-CASE-4. A report MUST NOT be filed automatically. The narrative is the substance of a SAR and requires human judgement; the system's role is to assemble a complete draft and to record who reviewed, amended and submitted it.
AML-CASE-5. The case file MUST retain the analyst's assessment whether or not it resulted in a report. This is explicit in the EU 2024 package: AMLR Art 77(1)(b) requires retention of the record of the Art 69(2) assessment "whether or not such assessment results in a suspicious transaction report", and requires that records "are not redacted" [17]. A no-report decision is precisely the decision an examiner will test, so the system MUST make closing an alert without a report a recorded, reasoned, attributable act.
AML-CASE-6. Confidentiality MUST be enforced in the product, not only in policy. Disclosure of a SAR or of its existence is prohibited (31 CFR 1020.320(e), resting on 31 U.S.C. 5318(g)(2)(A)(i)) [4], and the UK tipping-off offence is POCA 2002 s.333A, carrying three months on summary conviction and two years on indictment [20]. The system MUST scope access to SAR content by role, MUST exclude it from general search, export and notification paths, and MUST log every access.
AML-CASE-7. The system MUST support FIU response service levels. AMLR Art 69(1) requires reply to an FIU request "within 5 working days", shortenable "including to less than 24 hours", and Art 71(1) permits proceeding absent contrary instruction "within 3 working days" [17]. UK moratorium arithmetic MUST likewise be representable: POCA s.335(5) seven working days, s.335(6) 31 days, s.336A(4) extensions of not more than 31 days each, and an absolute cap at s.336A(7) of "more than 186 days (in total)" [20]. These are computable deadlines and belong in the case model, not in a runbook.
AML-CASE-8. Every state transition, note, attachment, assignment and disclosure MUST be recorded in an append-only audit trail bearing actor, timestamp and prior value. Audit entries MUST NOT be editable or deletable through any interface.
AML-REC-1. Records required by the BSA MUST be retained for five years. The rule is unambiguous: 31 CFR 1010.430(d) — "All records that are required to be retained by this chapter shall be retained for a period of five years" [21]. SAR copies and supporting documentation are separately required to be retained five years from the date of filing [4].
AML-REC-2. UK retention is five years under MLR 2017 reg 40(3), and the system MUST also honour the ceiling most summaries omit: reg 40(4) provides that records need not be kept "for more than 10 years" [22]. Retention policy MUST therefore be expressible as a window with both a floor and a cap, not as an indefinite hold — over-retention of personal data is itself a compliance problem.
AML-REC-3. Records MUST be sufficient to reconstruct the transaction. MLR 2017 reg 40(2)(b) states this directly [22]. Storing a decision without its inputs does not satisfy it.
AML-REC-4. Retained records MUST be retrievable within a reasonable period. 31 CFR 1010.430(d) sets a reasonableness standard rather than a numeric SLA [21]; the system SHOULD nonetheless publish a measured retrieval time so the institution can evidence reasonableness.
AML-REC-5. The transaction that was scored MUST itself be persisted. A system that evaluates and discards has no basis for aggregation (§3), no basis for reconstruction (AML-REC-3) and no basis for reprocessing (AML-MOD-6). Operational telemetry — request logs, traces — MUST NOT be mistaken for, or substituted for, the AML record. Volume of logs is not evidence of retention.
AML-REC-6. Where the store of record is an embedded database, durability and replication MUST conform to HIP-0302. Per-tenant embedded storage is compatible with a five-year obligation only with an explicit durability story.
AML-REC-7. Records MUST be tenant-isolated at every read path. Multi-tenant isolation on the organisation boundary is required by the Hanzo platform baseline, and for AML data a cross-tenant read is simultaneously a data-protection breach and a confidentiality breach under AML-CASE-6. Every endpoint that returns alert, case, subject or report data MUST derive tenancy from the authenticated principal and MUST NOT accept it from a client-supplied header or parameter.
AML-MOD-1. Any statistical or machine-learning component used in detection or scoring MUST be governed as a model under HIP-0201 and the supervisory model risk management guidance: Federal Reserve SR 11-7, OCC Bulletin 2011-12 and FDIC FIL-22-2017 [23][24][25]. The guidance organises the discipline into three areas — "(1) Model development, implementation, and use; (2) model validation; and (3) governance, policies, and controls" — and requires "adequate governance, development, documentation, testing, performance monitoring, validation, and effective challenge" [26].
AML-MOD-2. Applicability is charter-dependent and MUST NOT be over-claimed. The MRMG was not issued by the NCUA and does not apply to credit unions [26]. The 2021 interagency statement on model risk management for BSA/AML is FDIC FIL-27-2021, 9 April 2021, issued by the FDIC, Federal Reserve and OCC in consultation with FinCEN and NCUA — the latter two are not co-issuers [27].
AML-MOD-3. In the EU, model risk management is already an express requirement: AMLD4 Art 8(4)(a) requires "model risk management practices" as part of the institution's policies and controls [28]. This is base text, not a 2024 amendment.
AML-MOD-4. Validation MUST be performed by parties independent of development, MUST assess conceptual soundness as well as outcomes, and MUST be documented and repeated on a defined cycle. The system MUST retain, per model version: the training and evaluation datasets or their fingerprints, the performance metrics, the validation report and the approval.
AML-MOD-5. Model performance MUST be measured with metrics appropriate to a heavily imbalanced detection problem and MUST be reported as a distribution, not a point. Confusion matrix, precision, recall and ROC/AUC on a held-out sample are the minimum; accuracy alone MUST NOT be reported. Production drift MUST be monitored against the validation baseline.
AML-MOD-6. The system MUST support reprocessing historical activity through a changed model or rule set, so that the effect of a change can be measured before deployment and exposure can be assessed after new intelligence arrives. Above-the- line and below-the-line threshold testing depends on it.
AML-MOD-7. Rules and models MUST be promotable through environments with an approval gate, and the promoted artefact MUST be immutable and identified in every decision it produces.
AML-EXP-1. For any alert, the system MUST be able to state, in terms a non-engineer can act on: which detection fired, on what inputs, against what threshold, at what time, under which rule version, and what contribution each component made to the aggregate score. This is the operational meaning of HIP-0230 in a regulated context.
AML-EXP-2. An alert MUST be reproducible. Given the retained inputs, re-running the retained rule version MUST produce the same outcome. Any dependency that cannot be pinned — a live rate, a mutable list, a cached aggregate — MUST be captured as a value at decision time, not re-fetched at explanation time.
AML-EXP-3. Screening explanations MUST identify the matched list, the matched record, the matched name form and the score. An aggregate such as a mean distance across all matched records MUST NOT be the only value exposed to rule logic or to the analyst, because it cannot answer "who did we match, and on which list". A regulator's question is always about a specific designation.
AML-EXP-4. Where an unexplainable model contributes to a decision, the decision MUST be attributable to explainable evidence sufficient on its own to justify the action taken. A model score MAY prioritise work; it MUST NOT be the sole stated basis for a filing.
AML-EXP-5. The rule authoring language MUST be reviewable by a compliance reader. Where the language is general-purpose and compiled, the system MUST also render the rule's intent in a constrained, human-readable form, and MUST sandbox execution.
AML-OPS-1. Real-time interdiction paths MUST publish a latency budget and MUST be measured against it at p50 and p99 under representative concurrency, not at mean. An interdiction control that is fast at concurrency 1 and serialises under load has no usable capacity figure.
AML-OPS-2. Throughput MUST be reported together with the durable work performed per transaction. A figure obtained while the system performs no durable write is not comparable to one obtained while it archives, aggregates and screens, and MUST NOT be presented as though it were.
AML-OPS-3. Memory MUST be bounded and MUST be measured under sustained load, not only at idle. Unbounded in-process accumulation of alerts, cases or logs is a defect regardless of headroom.
AML-OPS-4. The system MUST start unattended. It MUST NOT require an interactive step, and MUST NOT attempt to launch a browser or any desktop process; on a server or in a container that is at best inert and at worst a failure. Readiness MUST be exposed as a health endpoint that reports not-ready until dependencies, including loaded sanctions lists, are usable.
AML-OPS-5. Every background responsibility MUST state whether it is safe to run in more than one instance. A component with no concurrency control is a scaling ceiling and MUST be documented as one.
AML-OPS-6. Operational cost MUST be stated as the full dependency set required to run — every process, datastore and broker — because that set, not the binary, is what an institution must operate, secure, patch and prove.
AML-OPS-7. Authentication and authorisation MUST be enforced on every endpoint that touches AML data, and the enforcement MUST be verified by negative tests that would fail if the check were removed. Documentation asserting that endpoints are authenticated MUST NOT be the only evidence that they are.
An implementation claims conformance to this HIP by publishing, per requirement, a test that fails when the requirement is violated. The following are mandatory negative tests, chosen because each corresponds to a failure mode that presents as working software:
both inclusive and exclusive directions (AML-TM-4).
if any deployed, enabled rule depends on an unimplemented helper (AML-AGG-4).
clean while any configured list has zero records or a stale load timestamp (AML-SCR-3).
to be on each configured list (AML-SCR-2, AML-SCR-3).
asserts the alert is still retrievable (AML-ALT-1).
as tenant B and asserts no record of tenant A is returned (AML-REC-7).
credentials (AML-OPS-7).
produces a maximal score or any alert (AML-ALT-4).
inputs and asserts an identical outcome (AML-EXP-2).
sum of its constituent transactions (AML-CASE-3).
not return a parseable payload of the expected shape, run against every configured source rather than one (AML-SCR-2, AML-SCR-3).
known designated name and asserts the match still fires (AML-SCR-5). The UN list's populated original-script names are a ready-made corpus for this.
approximate or as a range is compared as an interval, not as a point (AML-SCR-6a).
measure does not cause payment interdiction (AML-SCR-2b).
screening alerts but are present in adjudication context (AML-SCR-4b).
Requirements deliberately left incomplete, to be closed by the capability catalogue rather than guessed at here:
explicit red-flag indicators and request specific SAR key terms; these are the correct basis for a typology library. They are enumerable from fincen.gov/resources/advisories. No advisory number is asserted in this HIP because none was verified during drafting, and an unverified citation in a compliance specification is worse than an acknowledged gap.
environment. This HIP therefore cites FATF Recommendations by number for the obligation but asserts no FATF numeric threshold or retention period. In particular, the FATF R.16 wire-transfer de-minimis figure and the R.11 retention period MUST be confirmed against the primary text before either is relied on. The US equivalents are verified and cited above and are the safe anchor in the interim.
access mechanism is asserted anywhere in this HIP, because none was verified. Unresolved: whether the legacy webgate.ec.europa.eu/fsd/fsf token-bearing URL remains valid, whether an open mirror exists on data.europa.eu, and the actual structure of sanctionEntity, nameAlias, birthdate, identification and the legal-basis reference. AML-SCR-2 states the requirement to ingest the EU list; the how is an open work item and MUST be closed before EU coverage is claimed.
requirement to tune and validate a screening filter, and its text was not retrievable during drafting. No subsection is cited here. It SHOULD be obtained verbatim and folded into §4 and §9, and it may impose obligations on New York regulated institutions beyond what this HIP currently states.
threshold testing were not reached, and AML-MOD-6 is therefore stated in general terms rather than against the examiners' own wording.
This HIP is the specification. The engine's capability catalogue is the inventory of what is implemented. They MUST agree on three things, and the agreement MUST be mechanical rather than editorial:
entry MUST cite the requirement it satisfies; each requirement MUST resolve to zero or more catalogue entries. An unreferenced requirement is an open gap, and the count of unreferenced requirements is the headline compliance metric.
from §12 exists and passes. "Present in the codebase" is not a status. A rule whose helpers are stubbed MUST be catalogued as not implemented, however complete its definition looks.
because §2 and §5 establish that superficially equivalent obligations differ by jurisdiction and by charter.
Where the catalogue and this HIP disagree, the HIP is authoritative as to what is required and the catalogue is authoritative as to what exists. Neither may be edited to conceal the difference.
The following are not engineering decisions, and this HIP does not decide them. Each requires a qualified compliance officer or counsel for the institution in question, because each turns on the institution's own risk appetite, charter and regulator.
appropriate. FATF sets no number by design; a vendor default is not a control (AML-AGG-3).
cover, and whether the deployed rule set is adequate to its risk assessment.
thresholds. This is an explicit trade-off between missed designations and investigator load, and it is the institution's to make. No credible public false-positive benchmark was identified during drafting, so this cannot be settled by reference to an industry figure.
sufficiency of any narrative.
MRMG applies at all given charter (AML-MOD-2).
ten-year cap and applicable data-protection law (AML-REC-2).
and the treatment of the EU transition to 10 July 2027.
Citations verified against primary sources during drafting are marked (verified). Citations recorded from a secondary or paraphrasing source are marked as such.
support BSA/AML compliance, 86 FR (doc 2021-07428), footnote 4 (verified) — https://www.federalregister.gov/documents/full_text/text/2021/04/12/2021-07428.txt
"$3,000 or more" (verified) — https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-31.xml?part=1010
https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-31.xml?part=1020
$5,000"; (b)(3) "no later than 30 calendar days"; five-year retention of the SAR copy and supporting documentation; (e) confidentiality resting on 31 U.S.C. 5318(g)(2)(A)(i) (verified) — https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-31.xml?part=1020§ion=1020.320
Reserve); 12 CFR 748.1(d) (NCUA) — tiered SAR thresholds, the 30/60-day deadlines, and NCUA's "60 days" divergence (verified) — https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-12.xml?part=21
Terrorism & Proliferation — the FATF Recommendations. Cited by Recommendation number for R.1, R.6, R.7, R.10, R.11, R.12, R.13, R.16, R.18, R.20. Numeric values not verified — host unreachable during drafting; see §12 — https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
Payer) Regulations 2017, SI 2017/692, reg 18 — risk assessment (verified) — https://www.legislation.gov.uk/uksi/2017/692/regulation/18
(verified) — https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-31.xml?part=1020
https://www.legislation.gov.uk/uksi/2017/692/regulation/28
https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-31.xml?part=1010
https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-31.xml?part=1010§ion=1010.311
https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-31.xml?part=1010
in Property Are Blocked (the 50 Percent Rule) — cited for the obligation; URL not re-verified during drafting — https://ofac.treasury.gov/faqs/topic/1521
https://www.legislation.gov.uk/uksi/2017/692/regulation/35
https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-31.xml?part=1010
https://www.legislation.gov.uk/uksi/2017/692/regulation/33
applies from 10 July 2027 (verified) — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401624
https://www.legislation.gov.uk/uksi/2017/692/regulation/21
https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-31.xml?part=1010
(verified) — https://www.legislation.gov.uk/ukpga/2002/29/contents
https://www.ecfr.gov/api/versioner/v1/full/2026-07-01/title-31.xml?part=1010§ion=1010.430
(verified) — https://www.legislation.gov.uk/uksi/2017/692/regulation/40
verbatim during drafting; see [26] — https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm
https://www.occ.gov/news-issuances/bulletins/2011/bulletin-2011-12.html
(verified by title) — https://www.fdic.gov/news/financial-institution-letters/2017/fil17022.html
from this Federal Register document, not from SR 11-7 itself; footnote 3 states the MRMG does not apply to credit unions (verified) — https://www.federalregister.gov/documents/full_text/text/2021/04/12/2021-07428.txt
Secrecy Act/Anti-Money Laundering Compliance, 9 April 2021 (verified) — https://www.fdic.gov/news/financial-institution-letters/2021/fil21027.html
(verified, consolidated text CELEX 02015L0849-20240709) — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02015L0849-20240709
certain crypto-assets; applies from 30 December 2024; beneficiary elements at Art 14(2); no de-minimis for crypto-asset transfers (verified) — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R1113
(32024L1640, 32018L1673) rather than "AMLD6", which is ambiguous between them (verified) — http://publications.europa.eu/resource/celex/32024L1640
2026 — reg 32 substitutes "£800" for "1,000 euros" in reg 64C(4) in force 30 June 2026; new reg 34A commences 1 February 2027 (verified) — https://www.legislation.gov.uk/uksi/2026/621/regulation/32
name transliteration and MRZ rules. Document identity verified; canonical URL not retrievable during drafting (icao.int paths returned 404).
HIP-0302 Hanzo Replicate — Encrypted SQLite Durability for Base Services.
financial-sanctions-consolidated-list-of-targets —withdrawn 2026-01-28T10:40:06Z; "The OFSI Consolidated List has closed. From 28 January 2026 the UK Sanctions List is the only source for all UK sanctions designations" (verified) — https://www.gov.uk/api/content/government/publications/financial-sanctions-consolidated-list-of-targets
https://sanctionslist.fcdo.gov.uk/docs/UK-Sanctions-List.xml (and .csv/.ods/.pdf); schema and field names incl. UniqueID, IndividualEntityShip, Names/Name/{Name1..Name6,NameType,AliasStrength}, NonLatinNames, SanctionsImposedIndicators/*, RegimeName, DesignationSource (verified) — https://www.gov.uk/api/content/government/publications/the-uk-sanctions-list
https://sanctionslistservice.ofac.treas.gov/api/PublicationPreview/exports/
https://www.treasury.gov/ofac/DeltaFile/1.0, carrying action="add|remove|update"; RSS feed retired 31 January 2025 (verified) — https://www.treasury.gov/ofac/downloads/sanctions/1.0/DeltaFile.xsd and https://ofac.treasury.gov/sdn-list-data-formats-data-schemas/ofac-technical-actions-in-reverse-chronological-order
distance prefilter, higher of the two scores), FAQ 250 (OFAC will not recommend a threshold), FAQ 892 (unnamed third algorithm added 2021-01-25), FAQ 287 (the tool is not for automated repeated querying), FAQ 5 (hit-adjudication steps) (verified) — https://ofac.treasury.gov/faqs/topic/1636
and documented threshold rationale; §3.4 independent testing and treatment of the screening application as a model; §3.6 non-Latin support as a selection criterion; §6.3 weak aliases; §7 lookbacks (verified) — https://db.wolfsberg-group.org/assets/29c751c6-f406-4329-a267-1b05aabdd241/Wolfsberg%20Guidance%20on%20Sanctions%20Screening.pdf
cause VI, "Sanctions Screening Software or Filter Faults" (verified) — https://ofac.treasury.gov/media/16331/download?inline
https://www.unicode.org/reports/tr15/
(verified) — https://www.unicode.org/reports/tr10/
(verified) — https://www.unicode.org/reports/tr39/
https://www.unicode.org/Public/security/latest/confusables.txt
DistinctParty / Profile / Alias / DocumentedName structure, script and reference value sets, DatePeriod approximation flags (verified) — https://ofac.treasury.gov/media/10391/download?inline
https://ofac.treasury.gov/faqs/398
(verified) — https://ofac.treasury.gov/faqs/401
Winkler, W.E. (1990), ERIC ED325505, https://files.eric.ed.gov/fulltext/ED325505.pdf; Damerau, F.J. (1964), CACM 7(3):171–176, DOI 10.1145/363958.363994; Soundex coding rules, US National Archives, https://www.archives.gov/research/census/soundex (all verified). Levenshtein (1966), Fellegi & Sunter (1969), Metaphone and Double Metaphone are not verified to a citable primary source; where an implementation uses Double Metaphone it SHOULD be cited by reference implementation rather than by paper.