Production workflows / Guide 01
A Bank Support Agent That Explains Holds Without Inventing Balances
Build a bank customer support agent that distinguishes holds from posted payments, scopes account access, and escalates disputes with verified evidence.
Illustrative engineering guide. Examples are not client deployments, production-ready integrations, or evidence of measured results. Validate the design with your domain and security owners.
Imagine a hypothetical bank customer who sees two hotel charges after checkout. One is a posted payment; the other is an authorization hold. The customer asks for the second charge to be reversed. A fluent chatbot could promise a refund even though the second item is not a settled debit. A useful bank customer support agent must first establish which financial objects the customer is describing, then explain what the bank actually knows.
The initial product should answer balance and transaction questions and prepare service cases. It should not move money, override risk restrictions, or adjudicate disputes. That boundary makes the assistant useful without confusing conversational confidence with banking authority.
Preserve the Financial Meaning
Available balance, ledger balance, pending authorization, and settled transaction are separate facts. Do not flatten them into a list of descriptions and amounts. A hotel can adjust an authorization, a merchant descriptor can differ from its trading name, and two equal amounts do not prove duplication. Deterministic matching should use processor identifiers and explicit links between authorization and settlement records where available.
Each retrieved item needs a source identifier, observation time, currency, status, and account scope. An answer should say that a hold was present when the source was queried, not that funds will certainly become available tomorrow. Release estimates belong to an approved product policy, with uncertainty preserved. Missing linkage is a reason to investigate, not permission for the model to invent one.
An LLM earns its place by translating those distinctions into ordinary language, asking which transaction the customer means, and summarizing evidence for support staff. Arithmetic, ownership checks, dispute deadlines, and allowed service actions remain software and maintained policy. The model should never calculate an available balance from a partial transaction history.
A Small Evidence Architecture
Use an authenticated session gateway, a read-only account adapter, a policy retrieval index, and a case service. The gateway supplies customer and tenant identifiers from verified server-side context. The account adapter exposes narrow operations such as listing eligible accounts and retrieving one transaction’s status. It does not expose arbitrary SQL or an unrestricted search across customers.
Retrieve policies by product, jurisdiction, effective date, and customer segment before semantic ranking. A highly similar answer about a different card product is still wrong. Separate the published policy corpus from employee notes and customer uploads. Only the policy publisher can promote a document to authoritative status.
The following is an illustrative internal JSON contract, not a bank API or a complete validation schema. A production implementation still needs session verification, typed validation, encrypted transport, and audited source adapters.
{
"question_type": "possible_duplicate",
"account_ref": "acct_demo_17",
"evidence": [
{"id": "hold_demo_8", "kind": "authorization", "status": "open"},
{"id": "txn_demo_9", "kind": "settlement", "status": "posted"}
],
"linkage": "not_verified",
"observed_at": "2026-09-07T10:15:00Z",
"allowed_actions": ["explain", "prepare_case"],
"prohibited_claims": ["duplicate_confirmed", "refund_completed"]
}The response layer should enforce the allowed claim vocabulary before rendering a message. This is not a semantic truth guarantee, so sample responses still need expert evaluation. It does make a specific mistake, claiming completion without a receipt, mechanically preventable.
A second specialist agent is justified only if a separate task has a distinct evidence boundary, such as reviewing a lengthy complaint against a dedicated complaint-handling policy. Transaction lookup is a tool, not an autonomous agent. Multiple models discussing the same incomplete balance do not create missing evidence.
Treat Every Conversation as Untrusted
OWASP authorization guidance recommends deny-by-default access and permission checks on every request. Apply that to transactions, statement downloads, support cases, and retrieved documents. Joint-account access and delegated business-account access need explicit relationships; a matching surname is not authorization.
A merchant descriptor might contain instruction-like text. A customer attachment might ask the assistant to disclose another account. Both remain data. Following OWASP prompt-injection guidance, constrain tool calls independently of the model, restrict outbound destinations, and keep credentials outside prompts. MCP can connect the tools, but it is not authorization by itself.
Do not ask users to paste PINs, full card numbers, passwords, or authentication codes. Route sensitive identity recovery through the bank’s existing verified process. Operational logs should contain opaque case references and reason codes, not balances or raw chat transcripts. Store necessary case evidence separately under retention and access policies.
Recover Without Creating a Second Case
A core-banking timeout means current status is unavailable, not that the transaction does not exist. Return the last observation time if showing cached evidence is permitted, and offer a case handoff. Never quietly mix a fresh hold response with yesterday’s ledger response and describe the result as a single current snapshot.
Case creation needs a durable business request identifier. Persist the intended case and an outbox event together, then send to the downstream case platform. If the response disappears, reconcile by request reference before retrying. HTTP semantics distinguish idempotent operations from arbitrary writes; a POST does not become safe because a chatbot repeats it politely.
Human staff should receive the question, verified identity scope, source timestamps, unresolved ambiguity, and actions already attempted. This avoids making customers repeat their story while ensuring the reviewer can inspect the original evidence rather than trusting a summary alone.
Acceptance Tests That Expose Real Risk
- Supply equal-value hold and settlement records with no verified linkage. The assistant explains the distinction but never labels a duplicate or promises a refund.
- Replace an authorized account reference with another tenant’s reference. Every lookup and case attachment is denied without revealing that account’s existence.
- Inject instructions into a merchant descriptor requesting a statement export. No export tool runs, and the normal transaction explanation remains available.
- Drop the case platform response after successful creation. Recovery finds one existing case and returns its receipt rather than creating another.
- Return conflicting observation times beyond the configured freshness window. The answer identifies stale evidence and routes to a human instead of presenting a computed balance.
Measure Resolution, Not Deflection
Establish a baseline from manually handled hold-related conversations, segmented by product and case complexity. Measure verified resolution as conversations with a correct answer and no same-issue recontact within a defined seven-day window divided by all eligible conversations. Report exclusions and unresolved cases separately so transfers cannot inflate success.
Track unsupported financial claims per reviewed answer as a guardrail, alongside access-control violations and mistaken case merges. Compare median and upper-percentile handling time, including the human handoff. Begin in shadow mode, then let staff approve drafts, then expose read-only explanations for one product. Any money movement remains outside this rollout.
Start by modeling hold-to-settlement evidence for one card processor. The transaction investigation guide extends evidence handling into analyst work; the credit-limit guide explains why financial decisions need stronger human boundaries. AI systems engineering can help define those contracts before conversational scope expands.