Technical Architecture

Local Model Execution & Data Sovereignty

How AML Labs deploys agentic AI for compliance without transferring sensitive data to third-party ML providers, external APIs, or cross-border cloud regions — ensuring full regulatory control.

Core Principles

Why Local Execution Matters

Financial institutions operating under AML/KYC regulations face strict data residency and processing requirements. Transmitting customer PII, transaction records, or risk assessments to external ML inference APIs introduces regulatory, security, and operational risks that are incompatible with enterprise compliance mandates.

🔒

Zero Data Exfiltration

All model inference runs within the client's own infrastructure boundary. No customer data, embeddings, or compliance artifacts leave the institution's controlled environment — not even in encrypted form.

🏛️

Regulatory Alignment

Satisfies data residency requirements under GDPR, UAE PDPL, DIFC Data Protection Law, ADGM regulations, and sector-specific guidance from CBUAE, DFSA, and FSRA without requiring cross-border data processing agreements.

⚡

Deterministic Latency

No dependency on external API rate limits, provider outages, or internet routing. Inference latency is bounded by local compute, enabling real-time compliance decisions during onboarding and transaction monitoring.

🔑

Full Auditability

Every model version, prompt template, retrieval source, and inference output is logged within the institution's audit perimeter. Complete chain-of-custody for regulatory examination.

Architecture Overview

On-Premise Deployment Architecture

The system is composed of three isolated tiers — ingestion, intelligence, and integration — all executing within the institution's network boundary. No component makes outbound calls to external ML services.

Fig. 1 — High-Level System Architecture
CLIENT INFRASTRUCTURE BOUNDARY DATA INGESTION TIER Core Banking System KYC / CDD / EDD Records Transaction Monitor Alerts / STRs / SARs Document Store IDs / Proof of Address / UBO Sanctions / PEP Lists Local Mirror — Daily Sync ETL Pipeline Normalize → Validate → Chunk Vector Database pgvector / Milvus (local) AI INTELLIGENCE TIER Local LLM Runtime vLLM / Ollama / TGI GPU: A100 / H100 / L40S RAG Engine Retrieval-Augmented Generation Agent Orchestrator LangGraph / CrewAI (local) KYC Agent EDD Agent TM Agent QC Agent AUDIT LOG — ALL INFERENCE INTEGRATION TIER Case Management Auto-populate decisions Analyst Dashboard Review / Approve / Override Regulatory Reporting goAML / FIU Feeds Risk Scoring Engine Dynamic risk recalculation REST / gRPC API Layer Internal network only RBAC & mTLS Zero-trust auth layer ✕ NO EXTERNAL ML API CALLS
Comparison

Cloud ML APIs vs. Local Execution

Traditional approaches to AI-powered compliance rely on sending sensitive data to third-party inference endpoints. Our architecture eliminates this entirely.

Typical Cloud ML Approach
  • Customer PII sent to external inference APIs (OpenAI, Azure, AWS Bedrock)
  • Data may be processed in regions outside regulatory jurisdiction
  • Prompt content potentially used for model training by provider
  • Latency dependent on internet connectivity and API rate limits
  • Vendor lock-in to specific model provider's pricing and availability
  • Audit trail gaps — inference logs held by third party
  • Requires complex Data Processing Agreements and cross-border safeguards
AML Labs — Local Execution
  • All inference runs on institution-controlled GPU infrastructure
  • Data never leaves the designated compliance region or jurisdiction
  • No data shared with any ML provider — zero training data leakage
  • Sub-100ms inference latency on local hardware, no API dependency
  • Model-agnostic — swap between Llama, Mistral, Qwen, or fine-tuned variants
  • Complete audit trail within institution's own SIEM / log infrastructure
  • Simplified compliance — no cross-border data transfer mechanisms needed
Data Flow

Inference Pipeline — Zero External Transfer

A step-by-step view of how a compliance query is processed entirely within the institution's perimeter, from initial trigger through to analyst review.

Fig. 2 — Inference Request Lifecycle
1. TRIGGER Alert / Onboarding event received via internal queue 2. RETRIEVE Vector search on local embeddings pgvector / Milvus 3. REASON Local LLM inference with RAG context vLLM on GPU cluster 4. VALIDATE QC agent verifies output + confidence rule-based + LLM check 5. DELIVER Structured result to case management REST API → Dashboard PERSISTENT AUDIT LOG Every stage writes: timestamp • model version • input hash • output • confidence score • retrieval sources • latency NETWORK BOUNDARY — NO OUTBOUND ML TRAFFIC Firewall rules explicitly block egress to known ML inference endpoints (api.openai.com, *.azure.com/openai, bedrock.*.amazonaws.com) Network monitoring alerts on any attempted outbound connection to ML service IPs — integrated with SOC / SIEM
Technology Stack

Reference Implementation

A proven stack of open-source and enterprise-grade components, each selected for on-premise deployability, auditability, and compliance-readiness.

LLM Inference
vLLM / Ollama / TGI
High-throughput local serving with PagedAttention, continuous batching, and quantized model support (GPTQ, AWQ, GGUF).
Base Models
Llama 3.x / Mistral / Qwen
Open-weight models fine-tuned on AML/KYC domain data. No dependency on any proprietary model API.
Embeddings
BGE / E5 / Nomic Embed
Locally-hosted embedding models for document vectorization. No external embedding API calls.
Vector Store
pgvector / Milvus
On-premise vector database for semantic search over compliance documents, regulations, and client records.
Orchestration
LangGraph / CrewAI
Multi-agent orchestration with structured workflows for KYC, EDD, transaction monitoring, and quality control.
Document Processing
Unstructured / DocTR
Local OCR and document parsing for IDs, proof of address, corporate documents, and UBO structures.
Compute
NVIDIA A100 / H100 / L40S
On-premise or private cloud GPU infrastructure. Kubernetes-orchestrated for scaling and failover.
Observability
Prometheus / Grafana / ELK
Full inference monitoring, latency tracking, model drift detection, and audit log aggregation within the institution's SIEM.
Security Architecture

Network Isolation & Trust Zones

The deployment uses a defense-in-depth approach with distinct network zones, each enforcing strict ingress/egress rules to guarantee that sensitive data and model inference remain within the compliance perimeter.

Fig. 3 — Network Security Zones
DMZ Sanctions Feed Inbound only — TLS FIU / goAML Outbound reports — mTLS Reverse Proxy WAF + rate limiting Egress Firewall BLOCK: *.openai.com BLOCK: *.azure.com/openai FW APPLICATION ZONE — RESTRICTED API Gateway mTLS + JWT + RBAC Analyst UI SSO + MFA enforced Agent Orchestrator + RAG Engine Business logic — no external network access Local LLM Inference Cluster GPU nodes — vLLM serving — no egress permitted Message Queue Kafka / RabbitMQ Monitoring Prometheus + Grafana FW DATA ZONE — HIGHEST TRUST Customer PII Store Encrypted at rest — AES-256 Vector Database Embeddings — no raw PII Audit Database Immutable append-only log Model Registry Versioned weights + configs NO EXTERNAL NETWORK ACCESS
Deployment

Implementation Workflow

A structured deployment process ensures the local AI infrastructure meets compliance requirements from day one, with validation at every stage.

01

Infrastructure Assessment & Provisioning

Evaluate existing compute infrastructure and provision GPU nodes within the institution's data centre or private cloud. Establish network segmentation, firewall rules blocking outbound ML endpoints, and mTLS certificates for internal service communication.

02

Model Selection & Domain Fine-Tuning

Select open-weight base models and fine-tune on the institution's anonymized compliance data — including past KYC decisions, EDD reports, and regulatory correspondence. All training runs locally; no data leaves the environment. Model weights are stored in a versioned local registry.

03

RAG Pipeline & Knowledge Base Construction

Ingest and vectorize institutional knowledge: internal policies, regulatory guidance (CBUAE, FATF, EU AMLDs), sanctions lists, and historical case files. Embeddings generated locally using open-source models, stored in on-premise vector database.

04

Agent Design & Workflow Configuration

Configure specialized agents — KYC reviewer, EDD analyst, transaction monitoring assessor, quality control verifier — with structured prompt templates, tool access permissions, and escalation rules. Define human-in-the-loop checkpoints.

05

Integration & Validation Testing

Connect to existing core banking, case management, and regulatory reporting systems via internal APIs. Run parallel testing against historical cases to validate accuracy, measure false positive reduction, and calibrate confidence thresholds before go-live.

06

Production Deployment & Continuous Monitoring

Gradual rollout with real-time monitoring of inference latency, model accuracy, and drift metrics. Automated alerting on anomalies. Regular model retraining cycles using updated institutional data — always executed locally.

Regulatory Compliance

Data Sovereignty Compliance Matrix

Local model execution directly addresses the data handling requirements of major regulatory frameworks applicable to financial institutions in the UAE, EU, and globally.

Regulation Requirement Local Execution
GDPR (EU) Data minimization, purpose limitation, restricted cross-border transfers ✓ Satisfied — no external transfer
UAE Federal PDPL Personal data processed within UAE or approved jurisdiction ✓ Satisfied — on-premise in UAE
DIFC DPL Adequate data protection for DIFC-based entities ✓ Satisfied — local processing
ADGM DPR Data protection principles for ADGM entities ✓ Satisfied — no third-party sharing
CBUAE AML Guidelines Secure handling of customer due diligence data ✓ Satisfied — full audit trail
FATF Recommendation 15 Appropriate controls for new technologies in AML/CFT ✓ Satisfied — controlled, auditable AI