Compliance Utility

Version: 1.0 Last Updated: May 2026 Reference Implementation: Conflict Management Platform (legal-tech compliance and conflict-of-interest detection)

Component Overview

The Compliance utility is a domain-specific application built on the DataFab core framework that combines six capabilities into a single operational surface for legal and regulatory compliance teams: graph-based conflict-of-interest detection, schema management for OSINT-driven entity research, BPM-defined compliance processes, rules-driven risk-level assessment, adverse media checks, and screening against built-in and tenant-specific watchlists. Every capability is tenant-scoped, every decision is backed by a chain of audit records, and every external service consumed by the utility (the screening service, the OSINT enrichment service, the schema service) is reachable through declared, governed integration points.

The utility is what compliance teams use to onboard a new client, screen a new case, detect conflicts of interest, run risk assessment, trigger the right downstream process, and maintain a defensible audit trail.

Capabilities:

Connection to the DataFab Platform Value Proposition

The Compliance utility is the integration point at which several DataFab core primitives meet a single operational goal: deciding whether the platform can act for a client, on a case, on a matter — without conflict and within compliance.

Architecture Overview

┌──────────────────────────────────────────────────────────────────────┐
│                COMPLIANCE UTILITY                                    │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                    EXTERNAL SOURCES                            │  │
│  │  Customer / Onboarding Systems │ OSINT │ Watchlists            │  │
│  │  Adverse Media Indices │ Bank / Org Reference Data             │  │
│  └────────────────────────────────────────────────────────────────┘  │
│                              │                                       │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                    PLATFORM INTEGRATIONS                       │  │
│  │  Essential Knowledge Fabric API │ Organization Management API  │  │
│  │  Screening Service │ LLM Router │ OSINT Search Service          │  │
│  └────────────────────────────────────────────────────────────────┘  │
│                              │                                       │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                    SCHEMA REGISTRY                             │  │
│  │  Tenant-defined OSINT schemas; flattened field paths;          │  │
│  │  bound to clients, rules, BPM, compliance checks               │  │
│  └────────────────────────────────────────────────────────────────┘  │
│                              │                                       │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                    KNOWLEDGE GRAPH                             │  │
│  │  Person │ Company │ Case nodes │ Dynamic relationships         │  │
│  │  Per-tenant graph; configurable conflict depth (default 3)     │  │
│  └────────────────────────────────────────────────────────────────┘  │
│                              │                                       │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                    ASYNC PIPELINES                             │  │
│  │  search_entity_data │ company_enrichment │ case_enrichment     │  │
│  │  onboarding_enrichment │ compliance_check │ weekly_report      │  │
│  └────────────────────────────────────────────────────────────────┘  │
│                              │                                       │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                    RULES + RISK SCORING                        │  │
│  │  Attribute-path conditions │ Per-rule weights (0–100)          │  │
│  │  Sum capped at 100 → Final risk score                          │  │
│  └────────────────────────────────────────────────────────────────┘  │
│                              │                                       │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                    RISK THRESHOLDS                             │  │
│  │  LOW / MEDIUM / HIGH / VERY_HIGH bands per tenant              │  │
│  │  Each band binds to a Business Process (BPMN XML)              │  │
│  └────────────────────────────────────────────────────────────────┘  │
│                              │                                       │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                    BUSINESS PROCESS TRIGGER (BPM)              │  │
│  │  Tenant BPMN XML executes the right operational workflow       │  │
│  └────────────────────────────────────────────────────────────────┘  │
│                              │                                       │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                    SCREENING & CONFLICT REVIEW                 │  │
│  │  Case-party adverse-media + watchlist hits                     │  │
│  │  Conflict paths from the graph; reviewer status workflow       │  │
│  └────────────────────────────────────────────────────────────────┘  │
│                              │                                       │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                    COMPLIANCE OFFICER DIALOG (Playbook)        │  │
│  │  list_clients │ explain_decision │ rule_deep_dive │ hits       │  │
│  │  conflicts │ thresholds │ schema introspection                 │  │
│  └────────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────────┘

Domain and Schemas

The utility’s domain is centred on Clients (people or companies the tenant transacts with), Cases (matters with parties), and the graph relationships that connect them.

Schemas are managed centrally through the Essential Knowledge Fabric API. Every compliance artefact (client, rule, business process, compliance check) carries a schema_uuid and schema_name so that rules and processes always operate on known data shapes.

Six Core Capabilities

The remainder of this document describes the six capabilities the utility delivers, framed against the corresponding DataFab core primitives.

1. Graph-Based Conflict Detection

Purpose. Identify potential conflicts of interest by finding paths between two entities (e.g., a prospective client and an existing case party, two opposing parties on a case, a director and a counterparty) within a configurable graph depth.

Conflict record fields: source_node_name, source_parent_node_name, source_parent_node_type, target_node_name, target_parent_node_name, target_parent_node_type, path_data (JSONB), path_length, node_name_chain, status, summary, notes, reviewed_by, reviewed_at.

Conflict detection runs as part of every enrichment pipeline (company, case, onboarding) and is also runnable on demand. A weekly aggregated conflict report is produced for each tenant.

2. Schema Management for OSINT

Purpose. Let each tenant declare the entity shapes the platform should ingest through OSINT and external sources, so that downstream rules, BPM, and compliance checks all operate on consistent, governed data.

Why this matters. A rule cannot reference an attribute the active schema does not declare. Adding a new property to a tenant’s compliance surface is a schema operation, not a code change.

3. BPM-Defined Compliance Processes

Purpose. Externalise the operational workflow that should run after a compliance decision (file SAR, request EDD, escalate to Senior Compliance, decline, refer) so that tenants can adjust process logic without code changes.

Why this matters. The platform separates what to assess (rules + thresholds) from what to do about it (BPM). Tenants in different jurisdictions or business lines run different BPMs from the same rule set.

4. Risk Rules and Risk-Level Assessment

Purpose. Convert a client’s attributes (e.g., address.country, business.industry, pep_status) into a numeric risk score by evaluating governed conditions.

The Compliance utility’s rule model fits cleanly into the Graph Operations › Rule Engine — Pattern Scoring + Threshold rule types. Risk rules can be promoted into a DAG chain when a tenant’s compliance flow needs the chain-trace audit pattern (see Graph Operations › DAG Rules).

5. Risk Thresholds and BPM Binding

Purpose. Map the 0–100 risk score onto a discrete risk level, and from that risk level onto the BPMN process the platform should run.

Threshold rules:

The compliance pipeline reads the calculated score, finds the threshold band whose range contains the score, fetches the bound business_process_uuid, and triggers the BPM. The decision (band + BPM ID) is persisted on the compliance check.

6. Adverse Media and Watchlist Screening

Purpose. Screen case parties against adverse-media indices and sanctions / PEP / watchlist sources, with reviewer triage of hits.

Screening flow:

Screening result fields: entity_name, case_uuid, organization_uuid, similarity (0–100), match_type, index_name (watchlist source), status (relevant / irrelevant), notes, reviewed_by, reviewed_at.

Watchlist catalogue. The Screening Service exposes the available watchlists at WATCHLIST_BASE_URL/v1/api/list/filter_list/{page}/{limit}. The catalogue lists each watchlist version and its record count, paginated for tenant selection.

Tenant-Specific Screening Lists

Watchlists are catalogued globally by the Screening Service so that the platform can pool feeds (sanctions, PEP, adverse-media) once and offer them to all tenants. Selection is tenant-specific: every screening request explicitly lists the watchlists the tenant has chosen for that check. The platform never broadcasts a request across the whole catalogue. Three layered controls deliver tenant scoping:

This pattern lets one tenant prioritise OFAC + UK HMT + EU sanctions while another prioritises a sector-specific adverse-media feed, without operating distinct screening services.

Async Pipelines (Compliance Check Lifecycle)

The Compliance utility is implemented as a set of async pipelines orchestrated by the platform’s async-task runner; each pipeline produces persistent records and progress events.

Per-pipeline progress is broadcast over the platform’s event bus and surfaced over WebSocket to the analyst UI.

Decision Outputs

Every output is schema-bound, tenant-scoped, and traceable to its triggering pipeline.

Dialog Playbook

The Compliance playbook (see Dialog › Playbook-Based Communication) governs the analyst conversation surface for compliance officers and reviewers.

Intents

Persona and Guardrails

System Self-Awareness

Within the Compliance utility, Self-Awareness (see Dialog › System Self-Awareness) gives officers these specific capabilities:

Self-Awareness is read-only; rule, threshold, BPM, and watchlist changes go through compliance governance.

User Roles

Authentication uses JWT bearer tokens with role claims (USER / ADMIN / SUPER_ADMIN); inter-tenant access is denied unless the role is SUPER_ADMIN.

Operational Modes

Modes 0 and 4 are not used for this utility. Sanctions strong-matches and HIGH / VERY_HIGH risk bands always retain a HITL gate by default.

Security Controls

Audit Logging

Logs use immutable tamper-evident storage with PII redaction. Compliance audit logs are exportable for regulatory review.

Reference Implementation: Conflict Management Platform

Surface area. Multi-tenant application with a per-tenant graph database, async background workers, Pub/Sub for progress events, bearer-token authentication with USER / ADMIN / SUPER_ADMIN roles, and object-storage-backed BPMN definitions and client data.

Key external integrations:

Background workers:

Storage:

Regulatory Mapping

Cross-References

• Overview — Utilities overview
• Transaction Monitoring — Reference utility implementation
• Car Finance — Reference utility implementation
• Knowledge Fabric — Knowledge Graph, Entity Resolution, OSINT integration, MCP connectors
• Studio — DDA Pipelines, Chain of Agents, Tool Authorization, Widget Types
• Dialog — Playbooks, Context-Awareness, System Self-Awareness, Widget Rendering
• AI/LLM — LLM Router, model provenance
• Graph Operations — Rule Engine, DAG Rules, Graph Workflows, Case Management
• Schema Management — Schema Registry, domain discovery, validation
• Compliance Capabilities — Regulatory framework, retention policies
• Graph RAG — Text-to-Cypher Rules