Transaction Monitoring Utility

Version: 2.5 Last Updated: May 2026

Component Overview

The Transaction Monitoring utility is a financial crime alert triage and case-management application built on the DataFab core framework. It evaluates customer alerts using a self-organizing DAG rule chain, orchestrates the operational workflow per tenant via a tenant-scoped BPMN engine, enriches subjects and counterparties through OSINT and watchlist screening, runs straight-through processing for clear cases, and supports analysts with an explainable decision-support surface and human-in-the-loop review for high-risk decisions. The utility produces three structured outcomes — Close, Request for Information (RFI), and Escalate (SAR) — each backed by an immutable chain trace, a workflow audit, and, where applicable, a regulatory filing pack.

The utility is delivered as a single coherent surface: alert intake, rule-based assessment, OSINT and screening enrichment, decisioning, workflow execution, analyst dialog, SAR filing, outreach, dashboards, and policy management — all under unified tenant scoping and audit.

Capabilities:

Architecture Overview

┌───────────────────────────────────────────────────────────────────────┐
│                TRANSACTION MONITORING UTILITY                         │
├───────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                    DATA SOURCES                                 │  │
│  │  Core Banking │ KYC │ Sanctions / PEP │ Adverse Media │ OSINT   │  │
│  │  via Knowledge Fabric MCP Connectors                            │  │
│  └─────────────────────────────────────────────────────────────────┘  │
│                              │                                        │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                    KNOWLEDGE GRAPH                              │  │
│  │  Subject │ Counterparties │ Linked Parties │ Account Links      │  │
│  │  Entity Resolution │ Regulatory Markers                         │  │
│  └─────────────────────────────────────────────────────────────────┘  │
│                              │                                        │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                    DAG RULE CHAIN (69 rules)                    │  │
│  │  Tier 0  Intake (Alert + KYC)                                   │  │
│  │  Tier 1  Baseline (12-month rolling stats)                      │  │
│  │  Tier 2  Deviation (historic + focus period)                    │  │
│  │  Tier 3  Focus Set Merge                                        │  │
│  │  Tier 4  Tagging (16 rules + precedence + aggregation)          │  │
│  │  Tier 5  Pattern Detection                                      │  │
│  │  Tier 6  Context Rules (relationships, SoF, regulation)         │  │
│  │  Tier 7  OSINT Evidence Pack                                    │  │
│  │  Tier 8  OSINT Adverse Press                                    │  │
│  │  Tier 9  Gap Analysis + Adverse Media + Linked Parties          │  │
│  │  Tier 10 Composite (typology, materiality, mitigant)            │  │
│  │  Tier 11 Risk Scoring                                           │  │
│  │  Tier 12 Decision Router → Close / RFI / SAR                    │  │
│  └─────────────────────────────────────────────────────────────────┘  │
│                              │                                        │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                    ANALYTICAL SERVICES                          │  │
│  │  OSINT + Screening │ Customer Profile + Behavioural Intelligence│  │
│  │  Anomaly Detection │ Linked Accounts + Flow of Funds            │  │
│  │  Evidence Assembly │ Historical Alerts and SARs                 │  │
│  └─────────────────────────────────────────────────────────────────┘  │
│                              │                                        │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                    EXPLAINABILITY + DECISION SUPPORT            │  │
│  │  Graph-to-Narrative │ Recommendations │ HITL                    │  │
│  │  Grounding Validator                                            │  │
│  └─────────────────────────────────────────────────────────────────┘  │
│                              │                                        │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                    DECISION OUTPUT                              │  │
│  │  Final Normalized Risk Score (0–100)                            │  │
│  │  Decision (Close / RFI / SAR)                                   │  │
│  │  Hard-Override Reason │ Chain Trace                             │  │
│  └─────────────────────────────────────────────────────────────────┘  │
│                              │                                        │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                    TENANT WORKFLOW (BPMN)                       │  │
│  │  Post-decision workflow per tenant │ SAR pipeline               │  │
│  │  Outreach loop │ Approval gates                                 │  │
│  └─────────────────────────────────────────────────────────────────┘  │
│                              │                                        │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │              STRAIGHT-THROUGH PROCESSING                        │  │
│  │  Deterministic agents auto-close clear cases                    │  │
│  │  SAR / escalation hard guard │ Tenant exclusion config          │  │
│  └─────────────────────────────────────────────────────────────────┘  │
│                              │                                        │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                    INVESTIGATION CASE                           │  │
│  │  Client-centric case │ Notes + Decision Record                  │  │
│  │  Event Log + Notifications │ Audit Trail                        │  │
│  └─────────────────────────────────────────────────────────────────┘  │
│                              │                                        │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                    ANALYST WORKBENCH (Studio Widgets)           │  │
│  │  Graph Renderer │ Visual Link Analysis │ Evidence Panel         │  │
│  │  Typologies Drawer │ Baseline + Spike Chart │ Raw Tx Table      │  │
│  │  Linked Flow of Funds │ Counterparty Analysis │ Account Switcher│  │
│  │  Anomaly Metrics │ Recommendations Cards │ Quick-Action Toolbar │  │
│  │  Audit Trail Timeline │ Decision + Notes │ Mobile / Tablet      │  │
│  └─────────────────────────────────────────────────────────────────┘  │
│                              │                                        │
│  ┌─────────────────────────────────────────────────────────────────┐  │
│  │                    ANALYST SURFACE                              │  │
│  │  Case List + Drill-Down │ Error Queue │ Dashboards              │  │
│  │  Dialog Playbook │ SAR Filing UI │ Policy Management            │  │
│  └─────────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘

Domain and Schemas

Schemas are managed by the Schema Registry (Schema Management). Schema changes are versioned and gated.

Data Sources

Connection security (see 02-Architecture: Connectivity, 03-Knowledge-Fabric: MCP Connectors):

DAG Rule Chain

The Transaction Monitoring chain is the canonical example of a DAG Rule chain (see Graph Operations › DAG Rules). The platform ships 69 rules out of the box, organized into 13 tiers — but the rule chain is fully customizable: customers can author additional rules, adjust weights and thresholds, group rules into custom typology domains, and disable platform-shipped rules where their methodology differs. The chain’s self-organisation (declared inputs / outputs / dependencies, parallel-safety flag, dependency-not-met handling) means changes do not require manual workflow rewiring.

Tier Structure

The 13 tiers express the data-flow phases of the chain. Each tier may contain any number of rules, including customer-authored rules.

Rule Classes

The platform ships rules in well-defined classes. Each class has a stable contract; new rules are authored by adding members to a class and wiring them into the chain. Rules within a class share an output shape, so downstream rules can consume them uniformly.

Rule Logic Patterns

The Rule Engine supports several logic patterns that may be used alone or in combination within a rule. Customers may use any combination when authoring custom rules; every pattern is bound by the same execution-context, schema, and audit contract.

Customer-Authored Rules and Tenant Customization

Every governable artefact in the chain is tenant-customizable. The utility ships sensible defaults; customers can author additional rules, adjust weights and thresholds, and disable platform-shipped rules where their methodology differs. All changes flow through Policy Management (versioning, ground-truth testing, hot reload) and are audited.

Scoring Configuration

Decision Configuration

Graph-Query Rules

Rules in any class may use the Graph Query logic pattern (Text-to-Cypher; see 13-Graph-RAG: Text-to-Cypher Rules) to consult the knowledge graph for evidence the transaction-level data alone cannot provide — for example, classifying counterparties by regulatory status, discovering indirect linked parties through shared accounts or common references, or boosting a third-party-pattern signal with graph context.

Every graph-query rule must declare a deterministic fallback for use when the graph query is unavailable, returns an unexpected shape, or breaches the resource budget. Without a declared fallback, the chain rejects the rule at registration. This enforces the principle that no graph-query failure can silently change a decision.

Chain Trace

Every chain run persists a chain trace on the analysis record.

OSINT and Watchlist Screening

OSINT and screening are first-class evidence sources for the chain. Both feed scoring inputs (the OSINT rule class) and both surface independently to analysts through the dialog and case surface.

OSINT Snapshots

Every OSINT enrichment captures a per-source snapshot rather than a single aggregated result, so analysts can see exactly which provider returned which signal and when.

Watchlist Screening

Screening uses the platform’s Screening Service. Watchlists are catalogued globally; the selection of which watchlists to apply is tenant-specific and per-check, so different tenants can prioritise different list sets without operating distinct screening services.

Customer Profile and Behavioural Intelligence

The Customer Profile is the subject-centric view that combines static KYC attributes with derived behavioural signals. It is the analyst’s grounding for “what should normal look like for this customer?” and feeds into baseline rules, expected-use gap detection, and outreach question generation.

The Customer Profile is read-only from the analyst’s perspective; modifications go back through the source-of-record systems and are reflected through the Knowledge Fabric on next sync.

Anomaly Detection

Anomaly Detection is an analytical service consumed by both the rule chain (Tier 1 / 2 baseline-deviation rules) and the analyst surface (anomaly metrics widget). It quantifies how unusual the alert period is relative to the customer’s own history and to peer cohorts.

Anomaly metrics are surfaced in the analyst surface alongside the contributing chain-trace rules so the analyst can see the rule-based reasoning and the underlying numeric signal in one place.

Evidence Assembly

Evidence Assembly compiles every artefact bearing on a case into a single coherent evidence pack. It is the source of truth for the SAR pack, the RFI pack, the analyst evidence panel, and the audit trail.

The evidence pack is append-only and traceable: every entry carries the source, timestamp, and (where applicable) the actor. The grounding validator (see Explainability) blocks any narrative or recommendation that cannot be traced to a persisted evidence entry.

Linked Accounts and Flow of Funds

Linked Accounts and Flow of Funds is the cross-account view: it identifies other accounts associated with the subject, surfaces shared-counterparty patterns, and renders the directional flow of funds through the focus period.

The Linked Flow of Funds is rendered as a dedicated Studio Widget in the canvas surface; the Visual Link Analysis widget supplements it with relationship-level navigation across linked parties (see Graph Operations › Knowledge Graph for Operations).

Historical Alerts and SARs

Every case carries the customer’s history of prior alerts, decisions, RFIs, and filed SARs. This history is surfaced into the live case so the analyst sees the full pattern over time, not just the current trigger.

History is read-only and tenant-scoped; cross-tenant comparison is permitted only in anonymised aggregate.

Investigation Case, Notes, and Event Log

The Investigation Case is the client-centric record that binds together every artefact in a single audit-ready record. Cases are unified across alerts, RFIs, and SARs; one customer relationship maps to one investigation case timeline.

The case event log is the foundation for the audit trail. Every action — automated or analyst-driven — appends an event with actor, timestamp, and payload reference. Notes and the decision record are versioned; prior versions are preserved.

Analyst Workbench

The Analyst Workbench is the unified investigation surface. It is composed of Studio Widget Types bound to the analyst playbook (see Dialog › Playbook-Based Communication — Widget Bindings) so the dialog can render any of these widgets inline as part of a response, in the canvas surface, or both.

The workbench is mobile- and tablet-responsive: every widget supports the dialog and canvas view types and adapts to narrow viewports for analyst review on the move.

Widget rendering and tool authorization follow 04-Studio (Widget Types, Tool Authorization) and 15-Dialog (Widget Rendering); ad-hoc widgets cannot be invoked outside the playbook’s bound widget catalogue.

Tenant Workflow (BPMN)

The platform’s BPMN workflow engine (see Graph Operations › Graph Workflows) drives the operational lifecycle of every case. Each tenant declares an active BPMN workflow version that defines:

• post-decision handling (Close / RFI / SAR);
• the SAR filing pipeline including approval gates;
• the outreach loop following an RFI;
• any tenant-specific approval, escalation, or notification gates.

Explainability, Decision Support, and Human-in-the-Loop

To support the analyst in understanding and acting on a chain decision, the utility ships an explainability and decision-support surface backed by a grounding validator that prevents fabrication.

All LLM-driven steps in this surface route through the platform LLM Router with model provenance recorded (see AI & LLM).

SAR Filing Pipeline

The SAR pipeline orchestrates a draft → review → approve / reject → file workflow on top of the unified Case model. Multi-jurisdiction templates (FinCEN, NCA) are bundled; tenants may extend the catalogue.

Outreach Gap Detection

When evidence is insufficient — a rule was skipped due to missing input, a knowledge-gap rule fired, KYC fields are missing, or a signal was OSINT-only — the platform automatically identifies the gap and proposes outreach questions to the customer.

Generated outreach questions are surfaced as auto-created recommendations in the analyst recommendations panel and through a dialog tool. Analysts accept, edit, or reject before issuing the RFI.

Straight-Through Processing

For clear cases, the platform supports straight-through processing through deterministic agents (see Graph Operations › Graph Workflows) that auto-close the case without analyst review.

The deterministic-agent step takes no probabilistic decisions; eligibility is computed from the chain trace, exclusion configuration, and hard-override flags.

Dashboards and Analytics

Each dashboard tile supports unified drill-down to the underlying cases.

Policy Management and Testing

Every governable artefact in the utility — DAG rule chain, tenant BPMN workflow, freetext rules, scoring weights, decision thresholds — is managed through a unified Policy Versioning surface.

Policy testing prevents silent drift: an analyst cannot promote a candidate policy without seeing the regression impact against ground-truth data.

Case Management Surface

The analyst surface unifies case lookup, filtering, drill-down, error handling, and ad-hoc ingestion.

User Management

User identity, roles, tenants, and feature flags are managed through the Knowledge Fabric and consumed by the utility through the platform identity layer.

Decision Outputs

Dialog Playbook

The Transaction Monitoring playbook (see Dialog › Playbook-Based Communication) governs the analyst conversation surface.

Tool Catalog (illustrative)

Tools are subject to Tool Authorization; analysts only see tools their role permits.

Persona and Guardrails

System Self-Awareness

Within Transaction Monitoring, Self-Awareness (see Dialog › System Self-Awareness) gives analysts these specific capabilities:

Self-Awareness is read-only; configuration changes go through Rule Engine, BPMN, and Policy governance.

User Roles

Authentication: MFA required; password policy minimum 12 characters; idle timeout 15 minutes; absolute session timeout 8 hours; SAML 2.0 SSO supported.

Operational Modes

The utility supports the platform’s operational modes (see Studio › Operational Modes), with the addition of straight-through processing for clear cases. SAR / escalation cases retain a hard guard regardless of mode.

Straight-through behaviour (auto-close eligibility, exclusion configuration) is tenant-scoped and surfaced in the dashboard. The deployment-time configuration declares which modes are permitted for the utility. Mode transitions are change-controlled.

Security Controls

Audit Logging

Logs are stored in immutable tamper-evident storage with PII redaction. Retention defaults are configurable per regulator requirement.

Data Subject Rights

Recovery Objectives

DR testing schedule: monthly backup-restore tests; quarterly failover tests; annual full DR exercise; semi-annual tabletop exercise.

Regulatory Mapping

Cross-References

• Overview — Utilities overview
• Car Finance — Reference utility implementation (security framing reused)
• Compliance — Compliance utility (graph-based conflict detection, screening, BPM)
• Knowledge Fabric — Knowledge Graph, Entity Resolution, OSINT integration, MCP connectors, identity authority
• Studio — Tools, Widgets, Tool Authorization, Operational Modes
• Dialog — Playbooks, Context-Awareness, System Self-Awareness, Widget Rendering
• AI & LLM — LLM Router, Model Provenance
• Graph Operations — DAG Rules, Rule Engine, Graph Workflows
• Schema Management — Schema Registry
• Graph RAG — Text-to-Cypher Rules
• Compliance Capabilities — Regulatory framework