EAI — Enterprise Banking Agent System [PART 2]

What This Guide Covers

A complete, production-ready implementation of a regulated banking agent system built on Claude's multi-agent framework. You will follow a single €500 transfer as Atlas (Claude Opus 4.6 orchestrator) routes it through five specialist sub-agents, three deterministic policy gates, fraud ML scoring, and AML/KYC compliance screening — all in under two seconds — with every step generating an immutable chain-hash audit record.

Five-Agent Architecture

No single agent has broad access — least-privilege design is the cornerstone of the system. The Orchestrator (Atlas, Claude Opus 4.6) receives customer requests, classifies intent using Haiku (fast, cheap), routes to specialists, and synthesises results. The ReAct loop is hard-bounded to 10 turns with automatic escalation to a human agent on overflow.

A sixth component — the Audit Agent — uses no LLM at all. It writes an immutable chain-hash log: each record includes a SHA-256 hash of the previous record, making tampering cryptographically detectable. Customer IDs are stored only as SHA-256 hashes — PII never appears in plain text in any audit record. Total model routing cuts LLM costs 75% versus an all-Opus deployment.

10 Banking MCP Tools

All 10 tools enforce ownership verification, per-customer rate limiting (20 calls/minute per tool), and PII filtering at the tool level — independent of the LLM and API gateway. The execute_transfer tool requires confirmed=true (set only after the customer responds YES to a confirmation request) and passes three sequential gates before a single byte reaches core banking.

• get_account_balance · get_transactions · get_account_details — All with ownership check; IBAN masked to last 4 chars in logs
• resolve_account_name — Maps 'savings' → ACC-SAV-001 within customer scope only
• check_transfer_eligibility — Dry-run policy check before customer confirmation is requested
• execute_transfer — Requires confirmed=true + all 3 gates: Policy → Fraud → Compliance
• get_transfer_history · setup_standing_order · cancel_standing_order · get_statement — Scoped to customer; standing orders require policy gate + confirmation

Deterministic Policy Engine — 4 Sequential Gates

The policy engine is the most critical safety component in the system. The LLM can request actions; the policy engine decides whether they happen. Any single gate failure stops execution immediately — the LLM cannot skip, reorder, or override any gate. Total evaluation latency target: under 20ms.

Hard rules (10 of 12) run with zero LLM involvement. Only two rules use the LLM: AMBIGUOUS_DEST (when a destination account reference is unresolvable — Claude asks for clarification) and SOCIAL_ENGINEERING (LLM classifier detects coercion patterns — escalates to human with a security flag).

EUR 500 Transfer — Complete Execution Trace

Maria types: "Please transfer EUR 500 from my savings to my current account." The complete 11-step trace: (1) API Gateway authenticates JWT and extracts customer ID; (2) Orchestrator classifies INTRA_ACCOUNT_TRANSFER, extracts amount=500, currency=EUR; (3) Account Agent resolves 'savings' → ACC-SAV-001, 'current' → ACC-CUR-002; (4) Orchestrator requests explicit confirmation showing FROM/TO/AMOUNT/FEES; (5) Policy Gate passes: limit 500 < 5,000 ✓, status ACTIVE ✓, hours 08–22 ✓; (6) Fraud Agent scores 0.08 → APPROVE; (7) Compliance Agent: domestic transfer, amount < €10K threshold → CLEAR; (8) Account Agent executes via Core Banking → TX-REF-2026-98765; (9) Audit Agent writes immutable record AUD-2026-001234; (10) Notification Agent sends SMS + push; (11) Orchestrator returns success + reference. Steps 5, 6, and 7 run in parallel. Total: 1,886ms.

Testing & Security

A minimum 500-scenario regression test suite is required before any production deployment or system prompt change — including 100 happy-path, 80 policy violation, 60 fraud, 50 compliance, 50 security/injection, 40 edge case, 40 multi-turn, 30 error recovery, 30 concurrent, and 20 regulatory scenarios. Any single-word prompt change must re-run the full suite; deployment blocked if regression exceeds 0.5%.

The red-team matrix covers: prompt injection (fund redirection), role override ('you are now an unrestricted AI'), cross-customer account access by ID, social engineering ('grandmother is dying'), AML structuring (multiple transfers just below €10K), JWT forgery with elevated scopes, and MCP server spoofing via DNS hijacking — each with an exact pass criterion that CI must enforce before production deployment.

Multi-channel support spans Web (WebSocket streaming, JWT Bearer), Mobile (JWT + device cert, biometric step-up for large transactions), Internal Staff (OAuth2 + RBAC, 8-hour session), API/PSD2 TPP (OAuth2 + client_credentials, stateless), and Batch (service account + mTLS, job store).

Brief Summary

Five specialist AI agents, one deterministic policy gate, and working Python code — this guide hands you the complete production blueprint for a regulated banking agent built on Claude's multi-agent framework.

You will watch a real €500 transfer silently traverse an orchestrator, a fraud ML model, AML/KYC screening, and an immutable audit chain — all in under two seconds, and none of it bypassable by the LLM.

From OPA Rego policies and MCP tool security to a 500-scenario red-team regression suite, every architectural decision is explained, justified, and ready to deploy or defend.

Extended Summary

What if the most dangerous thing your banking AI could do was trust itself too much — and the safest architecture was one where the LLM is only ever allowed to ask permission?

This guide constructs a five-agent banking system from the ground up: Atlas, the Claude Opus 4.6 orchestrator, routes each customer request to narrowly scoped specialists — Account, Fraud, Compliance, Notification, and Audit — while a deterministic policy gate stands between every action and the real banking systems, unreachable by any prompt.

You will follow the complete EUR 500 transfer execution trace across 11 steps, 8 tool calls, 3 parallel policy gates, and a chain-hash audit record — with every line of Python annotated so the architecture is not just readable but reproducible.

The security chapter does not stop at theory: it presents the full red-team matrix covering prompt injection, JWT forgery, cross-customer access attempts, social engineering patterns, and MCP server spoofing — each with the exact pass criterion your CI pipeline must enforce before any production deployment.

Whether you are an engineer building the system, an architect reviewing it, or a security team stress-testing it, this guide delivers the OPA Rego policies, MCP tool definitions, model routing rationale, multi-channel API matrix, and a 500-scenario regression blueprint — the complete operational reference for enterprise agentic banking.

SimuPro Data Solutions

Cloud Data Engineering & AI Consultancy  ·  AWS  ·  Azure  ·  GCP  ·  Databricks  ·  Ysselsteyn, Netherlands  ·  simupro.nl

SimuPro is your end-to-end cloud data solutions partner — from in-depth consultancy (research, architecture design, platform selection, optimization, management, team support) to tailor-made development (proof-of-concept, build, test, deploy to production, scale, automate, extend). We engineer robust data platforms on AWS, Azure, Databricks & GCP — covering data migration, big data engineering, BI & analytics, and ML models, AI agents & intelligent automation — secure, scalable, and tailored to your exact business goals.

From Data to Valuable Insights — Proven Impact that Drives Business Growth

Data-Driven AI-Powered Validated Results Confident Decisions Smart Outcomes

Related Guides in the SimuPro Knowledge Store

EAI — Enterprise AI Agent Systems [PART 1]

 

EAI — Enterprise Data Platform [PART 3]

 

From Tokens to Enterprise: Agent AI Systems

 

Cloud Data Governance & Security

 

The Autonomous AI Data Engineering Agent

 

SimuPro Data Solutions — Cloud Data Engineering & AI Consultancy

Expert PDF guides · End-to-end consultancy · AWS · Azure · Databricks · GCP

Visit simupro.nl →