From regulatory advisories, analyst-filed SARs, and machine-discovered patterns — how a typology library becomes a governed, learning asset, not a static rulebook.
Every AML monitoring program is, at its core, a library of typologies: codified beliefs about what financial crime looks like in transaction data. The quality of detection is bounded by the quality, freshness, and coverage of that library. Today, that library is maintained by hand — slowly, expensively, and unevenly.
Three forces are squeezing the conventional typology-management process at every large bank simultaneously, and the gap between what the typology library should contain and what it actually contains is widening.
FinCEN, OFAC, FATF, and peer-bank intelligence publish faster than the typology-management process can absorb. Advisories sit in inboxes for months before they are translated into detection logic, if they are translated at all.
Every SAR narrative contains a trained investigator's reasoning about why a pattern is suspicious. Across thousands of SARs, an enormous latent typology library is buried in prose. None of it is being systematically mined.
Most banks operate the same vendor-provided scenarios for years, with calibration drift, high false positive rates, and no clean mechanism to retire what no longer works. The library accumulates entropy.
The honest framing matters here. Generative AI is not the right tool for transaction scoring; that work belongs to deterministic logic and statistical models that can be validated under SR 11-7. But the work upstream of detection — reading regulatory prose, extracting structured signals from analyst narratives, naming and explaining machine-discovered clusters, drafting MRM documentation — is precisely the work that classical NLP and rule-based systems cannot do well, and that humans cannot do at scale.
The shift we are proposing is structural, not cosmetic. A learning typology library is one where new typologies are discovered, drafted, validated, calibrated, deployed, and retired as a continuous process, with provenance and lifecycle gates that satisfy model risk management. The institution's accumulated knowledge — from regulators, from analysts, from its own transaction history — compounds rather than evaporates.
Typologies authored manually. Regulatory advisories absorbed selectively. SAR insight lives in analyst memory. Tuning is reactive. The library ages.
Typologies discovered continuously across four sources. Each typology is a versioned, governed artifact. Detection logic is generated from the spec. The library learns.
The system is a constellation of eight specialized agents, each doing one well-bounded job. Four are heavy users of generative AI — Parsing, Data Binding, Translation, and SAR Mining. Four are deterministic engines — Ingestion, Pattern Discovery, Runtime Detection, and Calibration. The output is a typology library expressed in three layers — institution-agnostic specification, institution-specific data binding, and executable detection — that can be reviewed, versioned, and audited independently.
The system absorbs typology knowledge from four distinct sources, each requiring its own ingestion treatment but converging on a common skill format.
| Source | What it provides | Ingestion treatment |
|---|---|---|
| Regulatory advisories | Authoritative typology narratives with red flags. FinCEN, OFAC, FATF, FFIEC, foreign FIUs. Low volume, high authority. | Scheduled crawl with change detection; RSS where available; subscription email parsing. |
| SAR narrative mining | Highest-signal source. Analyst reasoning encoded in prose. Highly institution-specific. | Continuous read from case management; structured extraction; cross-narrative clustering. |
| ML pattern discovery | Unsupervised clusters of anomalous behavior; novel patterns no existing typology describes. | Graph community detection & sequence clustering on transaction data; agent names & explains clusters. |
| Peer & enforcement intelligence | 314(b) information sharing, DOJ DPAs, court filings, consortium publications, enforcement actions. | Scheduled crawl of free sources; manual ingestion for 314(b); commercial feed where available. |
Each agent has a single responsibility. The separation matters: it concentrates model risk in the four agents that depend on generative AI (Parsing, Data Binding, Translation, SAR Mining) and keeps the four deterministic agents (Ingestion, Pattern Discovery, Runtime, Calibration) auditable as pure code. The detection path itself contains no LLM in the hot path.
The eight agents and skill artifacts compose into a layered architecture that separates intelligence sources, transformation, the skill library itself, runtime execution, and the continuous-learning loop. Crucially, the runtime detection path contains no generative model in the hot path — the AI work is upstream, in the construction and maintenance of the skill library, and downstream, in learning from outcomes.
A typology in the library is not a single object. It is three nested artifacts, each versioned independently, each reviewable by different stakeholders. This separation is what makes the system defensible under SR 11-7 and auditable for regulators.
Institution-agnostic. Narrative, provenance, behavioral components, combination logic, default calibration. Portable across clients. The output of the parsing agent.
Institution-specific. Each abstract concept resolved against the bank's data dictionary, with confidence scores, edge cases, and human approvals. The institution's accumulated ontology.
Generated artifact. Deterministic SQL or scenario code. Validation evidence from shadow runs. The runtime contract.
The system is deliberately additive. It does not displace Actimize, the case management workflow, the SAR filing pipeline, or the existing scenario library. It sits above them as a learning layer that produces governed typologies and routes alerts through the bank's existing investigation infrastructure.
The bank's current AML estate is well-established: Actimize for detection scenarios and case management, the data lake or warehouse for transaction data, the SAR filing pipeline to FinCEN, and the model risk management governance that wraps it all. The proposed system threads through these without replacing them.
The integration is not a single connection; it is a small set of well-defined contracts between the new system and the existing estate. Each is technically straightforward but operationally meaningful.
| Integration point | Direction | Mechanism |
|---|---|---|
| Transaction data feed | Bank → Typology system | Read access to the analytics layer of the data estate (Iceberg, Hadoop, Snowflake). No new pipelines. |
| SAR narrative ingestion | Actimize → Typology system | Daily extract of filed SAR narratives plus disposition codes. API or scheduled file drop. |
| Alert publication | Typology system → Actimize | Alerts routed via Actimize Alert REST API with full evidence payload, typology reference, version. Appears as a new alert type alongside existing scenarios. |
| Disposition feedback | Actimize → Typology system | Analyst dispositions on typology-generated alerts feed back into shadow validation and calibration tuning. |
| MRM artifact handoff | Typology system → MRM | Generated development docs, validation reports, and ongoing monitoring dashboards exported to MRM document repository. |
Existing Actimize scenarios continue to run unchanged. The new system contributes additional alerts through the same case-management front door. Over time, three patterns emerge: (a) new typology coverage that Actimize did not have; (b) refinements to existing scenarios where the new system suggests better calibration; (c) candidate retirements where the new system demonstrates that older scenarios are producing only redundant alerts. None of this is forced — the institution decides what to retire and when.
A realistic deployment proceeds in three phases. The first delivers value within a quarter without touching production detection; the second introduces shadow alerts; the third graduates the most-validated skills into production alerting.
Stand up ingestion of FinCEN advisories and 12 months of historical SARs. Build initial binding registry. Produce first 5–8 skills in candidate state. Validate against historical alerts. No production impact.
Promote skills to shadow mode. Generate parallel alerts not visible to investigators but compared daily against Actimize output. Tune calibration. Validate recall against historical SARs. Begin pattern discovery agent operation.
Graduate validated skills to production. Alerts flow to Actimize case management. Disposition feedback loop active. SAR mining continuous. New skills proposed monthly; retirement decisions on existing scenarios begin.
The system is designed to learn from three distinct sources, each with its own discovery rhythm: regulatory advisories arrive in bursts, transaction patterns surface gradually, and internal SAR narratives accumulate continuously. The three examples below trace one typology each through the same governed pipeline, ending in the same versioned library. The mechanism is identical; only the entry point differs.
FinCEN publishes a new advisory on its public advisories page. AG-01 has FinCEN in its monitored source registry; its 15-minute crawl detects the new content via header diff and content hash. The advisory PDF is fetched, text is extracted with pdftotext, and the document is enqueued to Kafka topic nexus.documents.new. Total elapsed time from publication: 9 minutes.
AG-02 reads the full advisory, identifies it as a new typology (not an update or restatement), and emits a Layer 1 specification. The six behavioral concepts in the red-flag list become first-class objects in the spec, each with confidence scores and provenance back to specific paragraphs in the source document.
AG-03 takes the six concepts and resolves each against the bank's data catalog. Four concepts find existing bindings in the registry (REUSED); two are novel (NEW) and routed for FCC review. The reuse rate is high because three of the four reused bindings were authored for earlier typologies — this is the compounding-asset effect in action.
| Concept | Status | Binding Expression | Confidence |
|---|---|---|---|
C.WIRE_OUTBOUND |
REUSED | FCT_TRANSACTIONS WHERE txn_type IN ('WIRE_OUT_FED', 'WIRE_OUT_SWIFT') |
0.98 |
C.NEW_BENEFICIARY |
REUSED | NOT EXISTS prior txn to counterparty in 30+ days (BIND-NEW-BENEF v1.2) |
0.96 |
C.CRYPTO_OR_NEW_MSB |
NEW | beneficiary.entity_classification IN ('CRYPTO_EXCHANGE','VASP') OR (classification='MSB' AND registered_within_days < 365) |
0.84 · FCC review |
C.AMOUNT_TREND |
REUSED | linear regression slope > 0 with min 4 wires over 30 days (BIND-AMT-TREND v1.0) |
0.92 |
C.AGE_AND_MARITAL_STATUS |
COMPOSED | DIM_CUSTOMER.age >= 60 OR marital_status_changed_within_days < 365 |
0.88 |
C.RETIREMENT_WITHDRAWAL |
NEW | account_type IN ('IRA','401K') AND withdrawal date < wire_date AND date_diff < 14 days |
0.81 · FCC review |
AG-04 compiles the spec plus bindings into Spark SQL. The query compiles cleanly. AG-04's deterministic validation pass runs the query against 90-day historical transactions; it returns 12 candidate matches and four of those candidates correspond to SARs already filed by FCC investigators for similar patterns — a strong out-of-sample signal. The typology enters Shadow mode for 60 days of parallel running before any production decision.
Total elapsed: 12 hours from FinCEN publication to draft typology entering Shadow validation. The same workstream done manually by FCC and Compliance Engineering would historically have taken 8 to 12 weeks.
AG-05 runs continuous community detection and temporal pattern clustering on the 90-day rolling transaction graph, subtracting subgraphs that match existing typology patterns. One residual cluster — persistent for 11 weeks — surfaces a coherent payment pattern that no current typology covers: 34 small commercial customers (electronics importers and resellers) sending wires to overseas suppliers for invoices systematically above market price for the declared goods.
When cluster confidence crosses 0.75 with corroborating external signals (in this case, two recent FATF and Wolfsberg publications on TBML in electronics corridors), AG-05 packages the cluster evidence and hands it to AG-02. The handoff includes the cluster signature, supporting transactions, the eight shared beneficiaries, FATF/Wolfsberg corroboration documents, and a confidence trend chart showing how the cluster has stabilized.
AG-02 in cluster mode reads the cluster signature, the eight shared beneficiaries' transaction histories, and the two corroborating external documents. It drafts a Layer 1 spec with four behavioral concepts — two of which reference market-data lookups the bank does not currently maintain. These data dependencies are surfaced explicitly in the spec, so FCC and Compliance Engineering can decide whether to commission the external data subscription before the typology advances.
Because this candidate depends on external data the bank does not currently maintain, governance places it in a different queue from FinCEN-derived typologies. FCC reviews the spec, the cluster evidence, and the proposed data dependencies. The decision before AG-03 binding work begins is a business one: commission the external pricing data feed (one-time investment), or close the candidate with a documented rationale. The system has done its job — surfacing a real pattern with provenance — and now hands the decision to humans with the right context.
The shape of ML discovery: Unlike the FinCEN path, the ML path often surfaces patterns that require investment decisions before they can be implemented. The system's job is to find the pattern and present the trade-off honestly — not to assume that every interesting cluster should become a typology.
One of 47 SARs filed over an eight-month period. Each describes a variant of the same underlying pattern, but no formal typology existed for it at the time of filing. AG-07 reads each narrative, extracts a structured pattern signature, and accumulates the signatures into a similarity graph.
After 47 SARs accumulate over eight months, AG-07's similarity graph reveals a tight cluster: young account-holders with low-income declared occupations, receiving Zelle from elderly counterparties, aggregating and outbound-Zelling within 24 to 72 hours. AG-05 confirms the cluster signature is statistically distinct from existing typology coverage. The cluster confidence crosses threshold; AG-07 hands the cluster to AG-02 with all 47 SAR narratives attached.
AG-02 drafts the Layer 1 spec from the cluster signature plus all 47 narratives. AG-03 resolves bindings — reusing five existing bindings (occupation classification, age tier, Zelle rail filter, low-income proxy, time-since-account-opening) and authoring three new ones (sender-age-distribution, post-aggregation-velocity, recurrent-beneficiary-network). AG-04 compiles to Spark SQL and runs the backtest against the source SARs themselves: 44 of 47 SARs are recalled (94 percent), with three near-misses caused by Zelle-rail metadata gaps that AG-04 surfaces as a known limitation.
The typology runs in Shadow mode for 60 days alongside existing scenarios. FCC reviews every alert. Shadow produces 38 candidate alerts; 23 are filed as SARs (61 percent precision); 15 are closed. AG-08 Calibration adjusts the post-aggregation-velocity threshold from 72 to 96 hours after Shadow analysis shows several legitimate-pattern false positives at the original cutoff. MRM reviews the validation package (Layer 1 spec, Layer 2 bindings with audit trail, Layer 3 code with provenance, backtest evidence, FP analysis); approves on January 15, 2026.
AG-06 runs the production query nightly. On 2026-05-15, it produces alert ALT-2026-05-1144 against Tyler B., a 23-year-old account holder showing the exact pattern. The alert is routed to Actimize with the full evidence payload — typology reference, version, contributing transactions, behavioral concepts matched, and lineage to the 47 SARs that produced the typology in the first place. The analyst sees not just an alert, but the case-law of patterns that justified the detection.
Typology lineage: Derived from 47 SARs filed 2024-08 through 2025-04. Shadow validated Oct–Dec 2025 with 94% historical recall. Approved for production by FCC and MRM 2026-01-15. Source-of-truth: TYP-EFM-001 v1.0.0 · BIND-BANK-TYP-EFM-001 v1.0.0.