We are going to walk through the architecture of a compliance monitoring system we built for a mid-size bank. Not the strategy deck version. The engineering version, with the data pipeline design, the agent architecture, the audit trail implementation, and the parts that took three times longer than we estimated.
If you're an engineer building for financial services, compliance monitoring is probably the project your CTO will ask about next quarter. The regulatory pressure is intensifying, the manual monitoring approach is hitting its capacity ceiling, and the gap between what regulators expect and what batch-review processes deliver is widening every month.
The AI agents in finance space has matured past experimentation. Banks are running agent-based compliance systems in production. But the engineering content around how to build them is thin, most of what's published is either vendor marketing or regulatory theory. This is the builder's perspective.
The problem in engineering terms
Compliance monitoring in a financial institution means evaluating every transaction and operational event against applicable regulations, internal policies, and risk thresholds. The key word is every.
A mid-size bank processing 200,000 transactions daily against roughly 150 distinct regulatory rules across AML, sanctions, lending compliance, consumer protection, and internal policy creates a monitoring matrix of 30 million evaluations per day. The manual approach, sampling 5 percent of transactions for human review, covers 1.5 million of those evaluations. The other 28.5 million go unmonitored until something draws attention to them.
The engineering challenge isn't AI sophistication. It's building a system that performs 30 million evaluations daily with sub-minute latency on new transactions, maintains complete audit trails for every evaluation, handles rule changes without system downtime, distinguishes genuine violations from false positives at a rate that doesn't overwhelm the compliance team, and satisfies regulators that the monitoring is comprehensive, documented, and explainable.
That's a systems engineering problem with AI components, not an AI problem with systems requirements.
The four-agent architecture
The system runs four specialised agents coordinated through a central orchestration layer. Each agent has a bounded scope, defined inputs and outputs, and its own audit trail stream.
┌─────────────────────┐
│ Orchestration │
│ Engine │
└──────────┬──────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ Transaction │ │ Regulatory │ │ Policy │
│ Monitor │ │ Change Agent │ │ Compliance │
│ Agent │ │ │ │ Agent │
└────────────────┘ └────────────────┘ └────────────────┘
│ │ │
└──────────────────┼──────────────────┘
│
┌──────────▼──────────┐
│ Audit Trail │
│ Engine │
└─────────────────────┘
A fourth agent, the audit readiness agent, operates on a batch schedule rather than in real time, assembling examination evidence packages from the audit trail. I'll cover it separately because its architecture is fundamentally different from the real-time agents.
Agent 1: Transaction monitoring
The transaction monitor evaluates every transaction against the full applicable rule set in real time. This is the highest-throughput component and the one where architectural decisions have the most direct performance impact.
The naive approach, sending every transaction through an LLM for compliance evaluation, fails at this scale on three dimensions: latency (LLM inference adds 500ms to 2s per evaluation), cost (200,000 daily transactions at inference pricing burns through budget), and determinism (LLM outputs on clear-cut regulatory rules aren't perfectly consistent, which regulators won't accept).
The architecture that works splits the evaluation into two tiers.
The deterministic tier handles rules that have clear, binary answers. Transaction amount exceeds the $10,000 CTR reporting threshold, yes or no. Counterparty appears on the OFAC sanctions list, yes or no. Transaction geographic origin falls in a restricted jurisdiction, yes or no. These evaluations are rules-based, not AI-based. They run as a streaming rules engine against each transaction event.
# Deterministic compliance checks - no AI needed
class DeterministicComplianceEngine:
def __init__(self, rule_set: RuleSet):
self.rules = rule_set
def evaluate(self, transaction: Transaction) -> list[ComplianceResult]:
results = []
for rule in self.rules.get_applicable(transaction):
result = ComplianceResult(
rule_id=rule.id,
transaction_id=transaction.id,
passed=rule.evaluate(transaction),
evaluation_type="deterministic",
timestamp=datetime.utcnow(),
evidence=rule.get_evidence(transaction)
)
results.append(result)
return results
The AI tier handles evaluations that require interpretation. Is this sequence of transactions consistent with normal business activity or does it suggest structuring? Does this customer's recent behaviour represent a legitimate change in financial patterns or a potential account compromise? Does this transaction narrative contain information that contradicts the stated transaction purpose?
These evaluations use an LLM with a structured prompt that includes the transaction data, the relevant regulatory context, and the customer's behavioural baseline. The output is structured, a classification, a confidence score, and a reasoning chain.
# AI-assisted compliance evaluation for pattern-based rules
class AIComplianceEvaluator:
def __init__(self, model_client, prompt_templates):
self.client = model_client
self.templates = prompt_templates
def evaluate_pattern(
self,
transaction: Transaction,
customer_history: CustomerHistory,
rule: PatternRule
) -> ComplianceResult:
prompt = self.templates.render(
rule_type=rule.type,
transaction=transaction.to_context(),
history=customer_history.recent_summary(),
regulatory_context=rule.regulatory_text,
output_schema="classification, confidence, reasoning"
)
response = self.client.complete(
prompt=prompt,
temperature=0.1, # Near-deterministic for compliance
max_tokens=500
)
parsed = self.parse_structured_response(response)
return ComplianceResult(
rule_id=rule.id,
transaction_id=transaction.id,
passed=parsed.classification == "compliant",
confidence=parsed.confidence,
reasoning=parsed.reasoning,
evaluation_type="ai_assisted",
timestamp=datetime.utcnow(),
model_version=self.client.model_version,
prompt_hash=hash(prompt)
)
The temperature=0.1 is deliberate and non-negotiable for compliance evaluations. We need near-deterministic outputs. We also store the prompt_hash and model_version in every evaluation result because regulators need to reproduce the conditions under which any specific evaluation was made.
The split between deterministic and AI tiers is the design decision that makes the system viable at scale. In our deployment, roughly 85 percent of evaluations are deterministic, clear rules applied to structured data. The remaining 15 percent go through the AI tier. This means LLM inference runs on 30,000 transactions per day rather than 200,000, which changes the cost and latency picture entirely.
Agent 2: Regulatory change monitoring
This agent scans regulatory publications and identifies changes relevant to the institution's operations. It's the most straightforward AI application in the system and the one that delivers value fastest.
The data pipeline ingests publications from the institution's applicable regulators, federal register entries, supervisory letters, guidance documents, enforcement actions, consent orders. For US banking, that's the OCC, FDIC, Federal Reserve, CFPB, and FinCEN at minimum, plus state regulators for the institution's operating jurisdictions.
# Regulatory change monitoring pipeline
class RegulatoryChangeAgent:
def __init__(self, sources, relevance_model, institution_profile):
self.sources = sources # RSS feeds, API endpoints, scrapers
self.model = relevance_model
self.profile = institution_profile
def scan(self) -> list[RegulatoryChange]:
new_publications = []
for source in self.sources:
new_publications.extend(source.fetch_since_last_scan())
relevant_changes = []
for pub in new_publications:
assessment = self.model.assess_relevance(
publication=pub,
institution_products=self.profile.products,
institution_jurisdictions=self.profile.jurisdictions,
institution_charter=self.profile.charter_type
)
if assessment.relevance_score > 0.6:
change = RegulatoryChange(
source=pub.source,
publication_date=pub.date,
summary=assessment.summary,
affected_products=assessment.affected_products,
affected_rules=assessment.affected_rules,
recommended_actions=assessment.actions,
relevance_score=assessment.relevance_score,
urgency=assessment.urgency_classification
)
relevant_changes.append(change)
return relevant_changes
The relevance model isn't trying to interpret the law. It's classifying whether a publication is relevant to this specific institution's products, services, and jurisdictions, and identifying which internal policies and monitoring rules might need updating. The compliance team makes the interpretive decisions, the agent surfaces what they need to see.
This agent runs on a scheduled basis, every six hours for federal sources, daily for state sources. The latency tolerance is hours, not seconds, which means it can use larger models with longer inference times for better classification quality.
Agent 3: Policy compliance monitoring
The policy compliance agent monitors internal operations against the institution's own policies and procedures, employee trading restrictions, information barriers, approval authority limits, customer communication standards.
The architecture mirrors the transaction monitor's two-tier approach. Deterministic checks for clear policy rules (approval authority thresholds, mandatory cooling-off periods, prohibited activity lists). AI-assisted evaluation for policies that require interpretation (communication tone compliance, conflict of interest assessment, information barrier monitoring across communication channels).
The data sources are broader than transaction data, email metadata, internal messaging, access logs, trading activity, document access patterns. The AI compliance monitoring architecture for policy compliance requires integration with communication platforms, HR systems, and access management infrastructure alongside the financial systems.
# Policy compliance - information barrier monitoring
class InformationBarrierMonitor:
def __init__(self, barrier_config, communication_feed, model):
self.barriers = barrier_config
self.feed = communication_feed
self.model = model
def evaluate_communication(
self, event: CommunicationEvent
) -> Optional[PolicyAlert]:
# Deterministic check: are participants in restricted groups?
sender_group = self.barriers.get_group(event.sender)
recipient_groups = [
self.barriers.get_group(r) for r in event.recipients
]
barrier_crossed = any(
self.barriers.is_restricted(sender_group, rg)
for rg in recipient_groups
)
if not barrier_crossed:
return None # No barrier concern
# AI assessment: does the communication content
# contain material non-public information?
content_assessment = self.model.assess(
content_summary=event.content_summary, # Never full content
sender_role=event.sender_role,
context="information_barrier_evaluation",
output_schema="risk_level, reasoning, recommended_action"
)
if content_assessment.risk_level in ["high", "critical"]:
return PolicyAlert(
alert_type="information_barrier",
severity=content_assessment.risk_level,
participants=event.participants,
reasoning=content_assessment.reasoning,
recommended_action=content_assessment.recommended_action,
timestamp=datetime.utcnow()
)
A critical design note in the code above: the AI model receives content_summary rather than the full communication content. In regulated environments, the compliance monitoring system itself must respect data handling restrictions. The model assesses risk indicators, not reads everyone's email. This privacy-by-design approach is a regulatory requirement, not an engineering nicety.
The audit trail engine
The audit trail isn't a logging feature. It's the primary deliverable. Everything the system produces, every deterministic evaluation, every AI-assisted assessment, every alert generated, every human decision on an escalated case, flows into an immutable audit store.
# Audit trail, immutable, complete, reproducible
@dataclass
class AuditRecord:
record_id: str
timestamp: datetime
event_type: str # evaluation, alert, escalation, resolution
agent_id: str
# What was evaluated
subject_id: str # transaction_id, communication_id, etc.
subject_data_hash: str # Hash of the input data
# How it was evaluated
evaluation_type: str # deterministic, ai_assisted
rule_id: str
model_version: Optional[str] # For AI evaluations
prompt_hash: Optional[str] # For reproducibility
# What was concluded
result: str # compliant, non_compliant, escalated
confidence: Optional[float]
reasoning: Optional[str]
# What happened next
action_taken: str
human_reviewer: Optional[str]
human_decision: Optional[str]
human_decision_timestamp: Optional[datetime]
The subject_data_hash and prompt_hash fields are the reproducibility mechanism. If a regulator asks "why was this transaction evaluated as compliant on March 15th," the audit record contains the hash of the exact data that was evaluated and the exact prompt that was used. The original data can be retrieved and the evaluation can be reproduced with the same model version.
The audit store uses append-only storage, records are never modified or deleted. The retention period matches regulatory requirements, typically seven to ten years for banking. We use a combination of a hot tier (last 90 days in PostgreSQL for fast querying) and a cold tier (older records in S3 with Parquet format for cost-efficient long-term storage).
The audit readiness agent
The fourth agent operates on a batch schedule, weekly and on-demand, rather than in real time. It assembles examination evidence packages from the audit trail, organised against specific regulatory examination modules.
When an examination notice arrives, the compliance team specifies which examination modules apply. The agent queries the audit trail for the relevant time period, assembles the evidence for each module, transaction monitoring coverage statistics, alert volumes and resolution outcomes, rule change history, policy compliance metrics and produces a structured evidence package that the examination team can review.
This is the agent that turned six weeks of examination preparation into four days for one institution we worked with. The evidence already existed in the audit trail. The agent's job was assembly and formatting, not investigation.
The engineering lessons that cost us the most time
Three things took longer than estimated and are worth knowing before you start.
The deterministic rule engine was harder than it looked because regulatory rules aren't as deterministic as they appear in the regulation text. A rule that says "transactions exceeding $10,000" seems binary. Then you discover that the $10,000 threshold applies to aggregated transactions within a 24-hour window from the same customer, that the aggregation logic must account for transactions across multiple accounts held by the same beneficial owner, and that "same customer" has a specific legal definition that doesn't map cleanly to your customer ID field. What looked like a simple threshold check became a multi-step aggregation query with entity resolution.
Model consistency monitoring consumed more engineering effort than model development. In a compliance context, you need to prove that the AI tier produces consistent results over time, that the same input evaluated today produces the same result it would have produced last month. We built a regression testing pipeline that re-evaluates a golden test set of 500 labelled transactions against every model update and every prompt change. If the evaluation results drift beyond a defined threshold, the update is blocked. This pipeline took three weeks to build. It runs automatically and has blocked two updates that would have changed evaluation behaviour in ways the compliance team hadn't reviewed.
Integration with legacy communication systems for policy monitoring was the longest single engineering task. The bank's internal communication infrastructure included a modern email system, a legacy messaging platform, and a voice recording system with its own proprietary format. Building the ingestion pipeline that normalised communication metadata from all three sources into a format the policy compliance agent could evaluate took six weeks, longer than building the agent itself.
The operational architecture
┌──────────────────────────────────────────────────┐
│ Event Sources │
│ Core banking │ Payments │ CRM │ Comms │ Trading │
└───────────────────────┬──────────────────────────┘
│ (Event-driven)
▼
┌──────────────────────────────────────────────────┐
│ Stream Processing Layer │
│ (Kafka / event bus - normalisation, routing) │
└───────────────────────┬──────────────────────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────────┐ ┌────────────┐ ┌────────────────┐
│ Deterministic│ │ AI-Assisted│ │ Policy │
│ Rules Engine │ │ Evaluator │ │ Monitor │
│ (85% volume) │ │ (15% vol) │ │ (async) │
└──────┬───────┘ └─────┬──────┘ └───────┬────────┘
│ │ │
└───────────────┼───────────────┘
▼
┌──────────────────────────────────────────────────┐
│ Audit Trail Engine │
│ (Append-only │ Immutable │ 7-10yr retention) │
└───────────────────────┬──────────────────────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
┌──────────────┐ ┌────────────┐ ┌────────────────┐
│ Alert Queue │ │ Dashboard │ │ Audit Readiness │
│ (compliance │ │ (real-time │ │ Agent (batch │
│ team) │ │ metrics) │ │ assembly) │
└──────────────┘ └────────────┘ └────────────────┘
The stream processing layer is the foundational infrastructure investment. We use Kafka for event ingestion because the throughput requirements (200,000+ events daily with sub-minute processing latency) exceed what REST-based architectures handle gracefully. Each source system produces events to Kafka topics. The normalisation layer transforms source-specific event formats into the common evaluation schema.
The deterministic and AI-assisted evaluation paths are separate consumers from the same Kafka topics. The routing decision, which transactions need AI evaluation versus deterministic-only, is made by a lightweight classifier at the stream processing layer based on transaction characteristics (amount, type, counterparty risk level, customer risk profile).
What this costs to build and run
Development timeline: approximately five months for the core system (transaction monitoring, audit trail, basic regulatory change monitoring). An additional two months for policy compliance monitoring and the audit readiness agent. Total: seven months from kickoff to full production deployment.
Infrastructure costs: approximately $4,000 to $7,000 per month for a mid-size deployment. This covers the Kafka cluster, the inference compute for the AI tier, the PostgreSQL hot tier, and the S3 cold storage. The LLM inference costs are the largest variable component, they scale with the volume of transactions routed to the AI tier.
The cost comparison against manual monitoring: a twelve-person compliance team doing sample-based review costs roughly $1.2 to $1.8 million annually in fully loaded compensation. The agent-based system costs roughly $250,000 to build and $60,000 to $85,000 annually to operate. The system monitors 100 percent of transactions. The manual team monitored 5 percent. The math isn't close, and it gets more favourable as transaction volume grows because the system's cost scales sub-linearly while the manual team's cost scales linearly.
For financial institutions ready to build compliance monitoring that evaluates every transaction against every applicable rule with complete audit trail documentation, the AI agent development partner practice at Dextra Labs covers the full stack, from stream processing architecture through deterministic rule engines, AI-assisted evaluation pipelines, audit trail implementation, and the regulatory change monitoring that keeps the rule set current as regulations evolve.
The compliance monitoring problem is fundamentally an engineering problem. The AI components are important but bounded, they handle the 15 percent of evaluations that require interpretation. The other 85 percent is deterministic rules applied at streaming scale with complete auditability. Building for compliance means building for both, and knowing which evaluation type applies to which rule.
Published by Dextra Labs, AI Consulting and Enterprise Agent Development
Top comments (0)