Banks do not need another chatbot that “knows product FAQs.”
They need an AI ops layer for banking that can sit on top of core systems, case queues, and payment rails — then finish (or escalate) work that today dies in email, Excel, and three browser tabs. The stack that makes that survivable in 2026 is the same spine we use on exchange desks: Vercel AI SDK for the agent loop, Temporal for durable workflows, and MCP for a typed tool allowlist into bank systems.
This is the banking edition — same architecture, different liabilities, higher scrutiny.
For measured outcomes from a production rollout, see the Banking AI Ops case study. For the consumer/fintech twin — chat that authors salary and crypto↔fiat recipes — see conversational banking rules → Temporal.
The use cases that clear audit (and the ones that don't)
| Use case | Ops owner | Agent job | Dual control |
|---|---|---|---|
| KYC / CDD exception queues | Onboarding / Compliance | Assemble evidence, map gaps to policy, draft request letters | Any outbound customer action |
| Payment exception / repair | Payments Ops | Classify fail codes, propose repair, stage SWIFT / ACH retry | Every retry / amend |
| Credit memo assists | Credit / Mid-market lending | Pull bureau + internal signals, draft memo sections | Credit decision stays human |
| Fraud case triage | Fraud Ops | Summarize alert clusters, pull account timeline, suggest next steps | Account freeze / unfreeze |
| Regulatory change impact | Compliance | Diff new circulars vs policy library (RAG), open tickets | Policy publish |
Start with payment exceptions or KYC queues. Volume is high, rules are written down, and “wrong AI email to customer” is less catastrophic than an unsupervised funds move — as long as writes are gated.
Do not start with “AI opens accounts and books loans.” That pitch belongs in a vendor fantasy deck.
Architecture: Intake → Case → Control → Judge
Mirror the exchange Broker / Execution / Judge pattern with banking names:
- Intake agent — turns tickets, emails, or case-manager events into a structured Case Intent (Zod).
- Case agent — calls MCP tools against core banking, CRM, document store, sanctions / KYC vendors. Never invents APIs.
- Control plane — Temporal Signals for maker-checker. Policy limits in code, not in the system prompt.
- Judge agent — scheduled LLM-as-judge on sample cases: wrong classification rate, rework loops, policy miss — feeds evals, not silent prompt rewrites of risk appetite.
Case Manager / Slack / Email intake
│
▼
┌─────────────────────┐
│ Intake Workflow │ ← Vercel AI SDK (generateText + tools)
└──────────┬──────────┘
│ starts CaseWorkflow
▼
┌─────────────────────┐ MCP allowlist ┌──────────────────────────┐
│ Case Workflow │ ─────────────────► │ Temporal Activities │
│ (durable loop) │ getCustomer, │ getPayment, stageRetry, │
└──────────┬──────────┘ fetchDocs, │ openTicket, notifyMaker… │
│ stageRepair └──────────────────────────┘
│ Signal: maker_approved
▼
┌─────────────────────┐
│ Control / Checker │ ← human in bank UI
└─────────────────────┘
Same mental model as Xenith Agents: orchestrator, specialists, evaluators — with human-in-the-loop as a first-class Temporal Signal, not a hope.
Why banking needs this stack specifically
Vercel AI SDK — structured banking intents
Ops hates free-form JSON. Use Zod schemas for:
PaymentRepairIntent(utr / endToEndId, failCode, proposedAction)KycGapBundle(missing docs, policy clauses, next ask)CreditMemoDraft(sections + citations to internal docs)
generateText / streamText with tools keeps TypeScript as the source of truth. With Temporal’s AI SDK integration, LLM turns become durable Activities — rate limits and worker restarts don’t orphan a half-built exception case.
Temporal — maker-checker that survives Monday deploy
Banks already speak workflow language: maker, checker, four-eyes, SLA clocks. Temporal maps 1:1:
- Long-running CaseWorkflow idles on
await condition(() => approved)afterrequest_maker_check - Retries on core-banking timeouts don’t double-post because Activities use idempotency keys
- Schedules run Judge sampling and overnight queue digests
- Replay gives Internal Audit what chat-GPT-over-SharePoint never will
MCP — the only way the model touches the bank
Expose tools, not credentials:
| MCP tool | Type | Notes |
|---|---|---|
get_customer_profile | Read | Mask PAN / Aadhaar / SSN in Activity layer |
get_payment_status | Read | Normalize across CBS / payment hub |
list_kyc_documents | Read | Doc store metadata only |
fetch_policy_clause | Read | RAG over policy library |
stage_payment_repair | Write (staged) | Creates repair proposal, not live post |
submit_payment_repair | Write | Requires checker Signal |
open_service_ticket | Write | ITSM / case system |
request_maker_check | Control | Blocks until Signal |
MCP without Temporal is a fragile demo. MCP tools implemented as Activities/Workflows is how you keep four-eyes and idempotency.
Expose the ops layer as platform MCP for the next product
Southbound MCP (above) is how agents touch CBS and the payment hub. Northbound MCP is how your next bank product — a wealth assistant, SME portal, or partner agent — reuses the same case and repair capabilities without a second integration project.
Ship the ops capabilities as an MCP server: get_payment_status, stage_payment_repair, open_kyc_gap_pack, request_maker_check. Product B authenticates with a scoped token; Temporal + dual control stay mandatory. Same pattern we use when a conversational banking product exposes create_rule to future apps.
Do not give Product B a second set of CBS credentials. Give it platform MCP.
Temporal hygiene (same as consumer rules): prefer short CaseWorkflow runs or Continue-As-New before history hits Temporal’s hard ceilings (~51k events / ~50MB). Keep Activity payloads as ids, not document bytes. Details — including rule DSL + supervisor vs run-per-trigger — are spelled out in the conversational banking → Temporal post.
Concrete flow: failed outward remittance repair
- Payment hub drops a fail code (
AC01/RR04/ bank-specific) into the queue. - Intake agent classifies →
PaymentRepairIntent. - Case agent pulls payment + beneficiary via MCP, fetches last successful template, drafts repair (account / IBAN / narrative).
- Policy engine: if amount > threshold or jurisdiction on watchlist → force dual control.
stage_payment_repairActivity writes a proposal with idempotency key =caseId:repairAttempt.- Checker opens bank UI, sees AI rationale + raw tool evidence, Signals
maker_approvedorrejected_with_reason. - Only then
submit_payment_repairruns. Crash mid-way? Replay; completed Activities not re-fired. - Judge samples weekly: classification accuracy, avg time-to-repair, override rate.
That is an AI ops layer a CRO can defend. Not a model “deciding money.”
Data residency, PII, and model choice
Banking constraints rearrange the stack:
- PII minimization in prompts — Activities redact before LLM call; store full payload in encrypted case store.
- On-prem / VPC models when policy requires — route via Private AI / Xenith Private patterns; Temporal workers stay in-region.
- No training on customer data — contractual + technical. Tool logs are ops logs, not fine-tuning corpora.
- Audit artifacts — workflow history + tool I/O digests exportable for governance reviews.
If your “AI for banking” vendor cannot explain where PAN numbers sit in the prompt path, walk away.
Failure modes unique to banks
Silent customer email.
Outbound comms tools always staged + approved. No “helpful” auto-send from the agent loop.
Core double-post.
Every write Activity carries a deterministic idempotency key. CBS quirks get adapter-level dedupe.
Policy drift via Judge.
Judge may open tickets and propose prompt wording. Risk appetite and authority matrices stay in signed config — same rule we enforce on exchange overlays.
RAG poisoning from outdated circulars.
Policy library versioned; fetch_policy_clause returns doc id + effective date. Stale hits escalate to compliance, not auto-apply.
Tool storm on fraud spikes.
Per-case tool budgets + queue backpressure. Fraud days should degrade gracefully, not melt the LLM bill.
51-hour slice vs. regulated production
Sprint (51-Hour MVP Sprint):
- One queue (e.g. payment exceptions) on sandbox / non-prod CBS
- Intake + Case workflows
- Four MCP tools (2 read, 1 stage, 1 approve Signal)
- Thin checker UI
- Temporal history as the audit demo
Production (weeks → months):
- Maker-checker roles mapped to bank IAM
- PII redaction layer + encryption at rest
- Full adapter set (CBS, payment hub, KYC vendor, ITSM)
- Judge evals + model routing
- Runbooks, kill switch, model risk documentation
When not to use agents
- Hard real-time authorization at the card switch — keep deterministic rules engines.
- Anything where regulators require fully documented scorecards without generative prose — use RAG + forms, not free-form agents.
- Institutions with no API or even RPA path into core — fix integration first; AI cannot paper over green-screen purgatory alone.
How this lands with Xenqube
This is AI Agent Development for mid-market and digital banks, often paired with Enterprise AI Consulting for the control framework, and industry context on our Financial Services page. Productized patterns live under Xenith Agents.
If payment repairs or KYC queues are burning your ops team today, the architecture is ready. Durable cases. Typed tools. Humans on the money.
Xenqube builds durable AI ops layers for banking and fintech teams — Temporal workflows, MCP tool boundaries, and dual control you can show audit.
Read the banking case study → · Book a Discovery Call → · AI Agent Development → · Finance industry →