AI Ops Layer for Banking: Vercel AI SDK, Temporal & MCP

Product FAQ chatbots do not clear bank ops queues.

Banks need an AI ops layer on core systems, case queues, and payment rails that finishes or escalates work stuck in email, Excel, and browser tabs. The stack that holds up 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) after request_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_repair Activity writes a proposal with idempotency key = caseId:repairAttempt.
Checker opens bank UI, sees AI rationale + raw tool evidence, Signals maker_approved or rejected_with_reason.
Only then submit_payment_repair runs. 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 AI ops layers for banking and fintech: Temporal workflows, MCP tool boundaries, and dual control that survives audit.

Read the banking case study → · Book a Discovery Call → · AI Agent Development → · Finance industry →