AI Agents in Banking

Natural language to Cypher, RAG over knowledge graphs, and agentic workflows that answer banking questions with provenance and compliance guardrails.

Overview

What · How · Why · Where · Importance

What

An AI agent in banking is a system that takes natural language input, reasons over structured banking data (graphs, tables, contracts), and returns accurate answers with an audit trail — without exposing raw data.

How

User question → LLM (with context) → generates Cypher/SQL → executes against Neo4j/DB → formats result with provenance → returns to user. Can chain multiple steps (retrieve → reason → validate → respond).

Why

Risk analysts, branch managers, and compliance officers cannot write Cypher or SQL. An AI agent democratises access to complex data — with guardrails ensuring they only see what they're authorised to see.

🏠

Where

Customer 360 queries, portfolio risk analysis, AML investigation support, regulatory report generation assistance, internal audit Q&A, and branch performance analysis.

Importance

The AI agent is the consumer-facing interface of the entire knowledge stack. All the governance, semantics, and graph work pays off here — when a non-technical user gets an accurate, traceable answer in seconds.

Architecture

Text-to-Cypher Agent Flow

Step-by-step: from user question to verified answer with provenance.

Step 1 — Intent Classification

Classify the question type: customer lookup, portfolio analysis, branch comparison, or compliance check. Routes to the appropriate context package and query template.

Step 2 — Context Retrieval

Fetch the relevant schema (Neo4j node labels, property names), glossary definitions, and — for specific entity questions — pre-retrieve the entity's subgraph from Neo4j.

Step 3 — Cypher Generation

Send question + context to Ollama (Llama3/Mistral). The LLM generates a Cypher query grounded in the injected schema — not invented node labels. Includes a validation step: does the Cypher parse before execution?

Step 4 — Safe Execution

Execute Cypher against Neo4j with read-only credentials. Timeout guardrail prevents expensive traversals. Result set is validated (expected column names present, no unexpected PII exposure).

Step 5 — Response with Provenance

Format the answer in natural language. Append provenance: which nodes were traversed, which source system the data came from, when it was last updated. The audit trail is built into the response.

Use Cases

Three Questions the Agent Must Answer

💵 Customer Exposure

"What is CUST_0042's total financial exposure?"

Agent traverses OWNS edges from Customer to all accounts and loans. Sums bal_amt (savings/current) and outstanding_amt (loans). Returns total with per-product breakdown and provenance.

📈 Risk Segmentation

"How many customers have both a savings account and an overdue loan?"

2-hop pattern match: Customer → SavingsAccount AND Customer → LoanAccount where overdue_days > 0. Returns count with optional drill-down to customer list (with access control).

🏠 Branch Risk

"Which branch has the highest portfolio at risk?"

Traverses DISBURSED_AT edges to aggregate outstanding and overdue amounts by branch. Computes PAR %. Returns ranked branch list — branch manager can act immediately.

⚠ AI in Banking — Guardrails & Model Risk

Deployment

Local LLM vs Cloud LLM in Banking

🏠 Local LLM (Ollama)

Pros: Data never leaves the bank's network. No third-party data sharing agreements needed. GDPR and data localisation compliance by default. Latency predictable.
Cons: Smaller models (Llama3/Mistral) less capable than GPT-4. Requires GPU infrastructure. Context windows smaller.
Best for: Structured query generation (Cypher/SQL) where the task is well-defined by injected schema.

🌐 Cloud LLM (Claude/GPT-4)

Pros: Larger context windows, better reasoning, multilingual support. Better for complex multi-hop reasoning or report drafting.
Cons: Customer data sent to third-party. Requires DPA (Data Processing Agreement), anonymisation, or synthetic data. Latency variable.
Best for: Regulatory report drafting, complex document analysis, where data can be anonymised before sending.

🔧 In the Demo

agent/agent.py — Ollama + Neo4j CLI Agent

The demo runs Ollama locally (llama3 or mistral, whichever is available). The agent loads the Neo4j schema, injects the business glossary, and accepts natural language questions from the terminal. It sends the context-enriched prompt to Ollama, parses the returned Cypher, executes it against Neo4j with the neo4j Python driver, and prints the answer with traversed node IDs as provenance. The three example questions — customer exposure, at-risk count, branch PAR — are built into the agent as test cases.