Agentic end-to-end case resolution

A service request is complete when the allowed change exists in core banking and the CRM case records the same cite, on an allow-listed request type only. A polished transcript, a resolved status, or a customer thank-you does not count. If core rejected the write, the case is not done.

This page is for bank service operations and digital leads who want a multi-step agent to execute bounded work such as address updates, card replacement, or direct debit cancellation across core and CRM without a human routing every step. It is not permission for the model to invent work. If the customer asked to replace a card, you do not cancel a mandate. If the type is not on the allow list, the agent stops and a human continues.

Channel intake can sit in tier-1 service deflection. The agentic path starts only after classification and verification pass.

Classification answers three questions in order: what the customer asked for, whether that type is on the allow list, and whose record would change.

Map the utterance to a closed vocabulary of request types your bank has signed off, for example address update, card replacement, and direct debit cancellation. Near-matches are not types. "I moved, and also stop that payment to the gym" is two or three intents. Run only the types that are both allow-listed and explicitly requested. Do not invent a direct-debit cancellation the customer did not ask for.

Identity belongs in classification, not as a later courtesy. Voice match, knowledge-based checks, device binding, or document capture must succeed for the channel you are in. A failed voice match is a stop. Changing an address after a failed voice match is a quality failure even if the new address looks plausible.

Language that indicates distress or vulnerability is a classification outcome. If vulnerable customer detection fires, do not auto-execute. Hand off.

When a document is in play, such as proof of address or ID for a card, form pre-population from ID extraction can fill fields. Pre-fill is not authority to write. Extracted values still pass the same verification gate as an address the customer typed.

The allow list is a procedure. For each type, name the systems, the fields, the verification evidence, and the stop conditions. Do not auto-run an address change without verification, even if the customer is in a hurry and the model is confident.

Verification is type-specific.

Address: authenticated session plus a corroborating check your policy names, such as a one-time passcode, a recent bound device, or proof of address. No write on a failed voice match.

Card replacement: authenticated customer, card identifier confirmed (last four plus product, or a token core already knows), and delivery address confirmed against the record or against a new address that has already landed in core.

Direct debit cancellation: authenticated customer, mandate identified by reference, originator, and amount pattern, and the customer restated the target. Cancelling a different mandate because the names were similar is a quality failure.

Sequence matters. Confirm the target record, show what will change, then write. If the customer said "the British Gas one" and two gas originators sit on the account, stop. Do not pick.

Off-list work includes disputes, fraud claims, limit increases, bereavement, power of attorney, credit variations, and any request that needs judgement or a regulated vulnerability pathway. The agent does not stretch the allow list with a similar-sounding procedure.

The durable source of the change is core, often a Temenos-class system of record. Case and interaction history live in a CRM such as Salesforce. Completeness requires both: the core update succeeded, and the CRM case stores the cite (reference, timestamp, request type, actor as agent, verification method).

Order of operations: verify identity and request type; execute the core write; wait for a success response, not an acknowledgement of a job you never confirmed; write the cite to CRM; only then mark the case complete.

If core rejects the write because of a format error, a deceased marker, a card already hot, or a mandate not found, the CRM case stays open. Marking the case done when core rejected the write is the failure operations will miss on a dashboard that only counts agent-resolved. The customer still has the old address. The case looks clean. Quality is broken.

Do not treat CRM as the system of record for the change. A Salesforce case comment that says "address updated" without a core reference is a note, not a completion.

If the core write succeeds and the CRM write fails, you have a completed change with a missing cite. Retry the CRM cite or park for a human. Do not reverse the core write unless policy requires the two systems to move together and you have a defined compensating step.

The human remains for anything off the allow list, any failed verification, any ambiguous mandate or card, and any core rejection. Handoff is a structured packet: request type attempted, evidence collected, last core response, fields the agent would have written, and why it stopped.

agent assist copilot is the right surface for that packet. The colleague who picks up should see the failed voice match, not a blank case. They should not re-ask for an ID the customer already supplied unless the capture was unusable.

Do not silently degrade into best effort. Partial execution is allowed only when the allow-listed procedure defines a safe partial, for example a card hot-listed in core with fulfillment parked because the delivery address is unverified. Undefined partials are stops.

A customer in authenticated chat writes: "We've moved to 14 Harbour Lane, please update my address, and the card you posted last month never arrived so send a new one. Also stop taking the gym if that's still going."

Classification yields three candidate types. Address update and card replacement are on the allow list. Direct debit cancellation is on the allow list only when the mandate is uniquely identified. "The gym" is not unique if two fitness originators sit on the account.

The session is authenticated. Voice match is not in play; this is chat with a bound device and a passcode already completed. If this had been a phone call and voice match had failed, the address change would stop here. Changing address on a failed voice match is not a recoverable shortcut.

The agent treats address as a verified request: it shows 14 Harbour Lane back to the customer, confirms which address types the product rules allow it to change, writes to core, receives a customer-record reference, and cites that reference on the CRM case. It does not use the new address for card fulfillment until that core write has succeeded.

It then confirms which card never arrived. The last four the customer supplies matches one open card. It issues the replacement against the verified address now in core and cites the card event in CRM.

It does not cancel a direct debit. It states that the gym payment needs a unique mandate, presents the two fitness originators, or hands off. Choosing the larger of the two would cancel the wrong mandate. The customer did not identify it.

If core then rejects the address write because the postcode fails format validation, the agent does not mark the case done, does not order the card to Harbour Lane, and does not touch mandates. It keeps the case open with the core error and hands off.

That is the quality bar: allow-listed types only, verification before write, a cite in core and CRM, and a human for every path the list does not cover.