Backbase Conversational Banking: Linking Customer Confirmation to Execution

Imagine contacting your bank through a chat or voice interface and saying, “I’ve lost my card. Please block it and issue a replacement.” Your request starts the process.

When the system asks, “Would you like to proceed?”, what does your answer establish—and what must the bank check separately?

On October 8, 2026, Netherlands-based Backbase announced the general availability of Conversational Banking. The company describes a design that combines several controls: permissions, policies and approvals defined by the bank, explicit confirmation by the customer, and records of decisions.

This article focuses on customer confirmation. It outlines what a financial institution adopting or designing a similar system should check about how confirmation connects to the actual transaction and to the bank’s own decisions.

What the official announcement says

According to Backbase’s announcement, customers and employees make requests by voice or text, and AI agents turn them into banking actions within the permissions, policies and approvals the bank defines. The examples given are blocking and replacing a lost card, checking a payment, and processing a service request. When a request requires investigation or human judgment, Backbase says staff receive the relevant information and an overview of the work the agent has already completed.

The announcement describes the following controls:

• The bank decides which information, knowledge and tools agents can access, which actions they can perform, and where human approval is required
• Any consequential request requires explicit customer confirmation
• Information, decisions and outcomes related to each request are recorded and used for audits and retrospective review

The company’s product page also says that access, policy and approval checks are applied before an action executes, that exceptions are routed to an authorized employee, and that the evidence behind each decision and the confirmed outcome are retained.

All of the above is Backbase’s own description of its product. MIF has not tested how the product actually behaves or how effective its controls are. In what follows, we use this description as a starting point to outline design requirements to verify before deployment.

What customer confirmation can and cannot do

A mechanism in which the customer reviews the details and responds can serve as one control for obtaining the customer’s agreement to the action presented.

It can, for example:

• Produce a record that the customer responded to the specific action that was presented
• Narrow a request that was vague in conversation down to concrete details before execution
• Provide a reference point for later reviewing what exactly the customer responded to

The response to a confirmation prompt alone, however, does not establish the following:

• Whether the person responding is actually the customer (identity is established through authentication)
• Whether that user is permitted to perform that action (permission is established through authorization)
• Whether fraud is involved (a customer can approve a transfer or a similar action while being deceived by a third party, so the customer’s own approval does not rule out fraud)
• Whether the customer fully understood the details

Customer confirmation and review by bank staff serve different purposes. Customers confirm the details of the actions they request. The bank’s systems and staff check authorization, signs of fraud, and the requirements for carrying out those actions. Employees handle exceptions that require human judgment.

MIF recommends distinguishing these roles and linking both the customer’s confirmation and the bank’s decision to the action performed. The bank must still verify that its requirements are met, even after the customer confirms.

Requirements for linking confirmation to execution

The following are checks that MIF proposes for anyone adopting or designing a similar system.

Generate confirmation messages from verified action data

The wording “Would you like to proceed?” by itself may not make clear what is about to be carried out. Before execution, state the specifics: which card, what action (a temporary lock, or a block and replacement because the card was lost), whether it can be undone, any fee, and how long it will take.

If the confirmation text is generated only from a summary of the conversation, key details such as the target or the amount may be dropped or drift from the original request. MIF therefore recommends building the displayed or spoken confirmation from action data that the bank has verified.

Tie the customer’s response to that specific action

Presenting the correct details and ensuring that only the confirmed action is carried out are separate requirements.

Link the customer’s response to the action presented. At the point of execution, verify both that the customer agreed to proceed and that the action matches the details they confirmed.

If key details—such as the card, delivery address, or amount—change, request confirmation again rather than relying on the earlier response.

Also check that the confirmation cannot be reused for an action outside the confirmed scope, and that retries cannot cause the same action to be performed twice.

Choose the confirmation method by impact and fraud risk

Do not choose a confirmation method solely on the basis of how easily an action can be reversed. Also consider its impact, the information involved, the likelihood of fraud, and how easily an error can be corrected.

For example, temporarily locking a card and blocking and replacing a card reported lost should be treated differently. Whether the block can be lifted and what happens to the old card should be checked against the specifications of the service in question.

Reducing the number of confirmations is not a goal in itself. Keep the confirmations that are needed while removing duplicate prompts and unclear wording. Repeated prompts may lead customers to proceed without reading them carefully, so review how customers respond to those prompts in actual use.

Decide whether to proceed, ask again, or hand off to staff

A customer not saying “yes” can mean several different things.

If the customer clearly declines, do not carry out the proposed action.

If the customer corrects the details, update the proposed action and ask for confirmation again.

If the response is ambiguous, put the action on hold and ask for clarification.

If the issue cannot be resolved through the conversation, or the request meets the bank’s criteria for escalation, hand it over to an appropriate staff member.

The announcement says that when a request requires human judgment, staff receive the relevant information and an overview of the work so far. The specific criteria that trigger a handoff are something to confirm before deployment.

A request that differs from the customer’s normal activity does not necessarily need to be rejected. When signs of unusual activity are detected, follow the bank’s defined procedure, which may involve additional verification, putting the request on hold, or referring it to staff.

What to record, and how

The announcement says that information, decisions, and outcomes relating to each request are recorded to support audits and retrospective review. The announcement we reviewed does not specify the detailed record fields, level of detail, or retention periods.

Link the details presented to the customer, their response, the bank’s decision, and the execution result so they can be traced to the same request. Retain the information needed to review what the customer responded to, such as the text displayed or read aloud, the confirmation template version, and the action data.

Do not adopt a blanket policy of storing every conversation or screen. Exclude passwords and reusable credentials from logs, and limit personal information to what is necessary for review. Where detailed information must be retained as evidence, define storage locations, access permissions, retention periods, protections against tampering, and deletion procedures in line with applicable laws, regulations, and the bank’s policies.

Records alone do not establish that controls are effective. Use both records and tests of system behavior to verify that a declined action is not carried out, that earlier confirmation is not reused after key details change, and that retries do not cause duplicate execution.

Example design by type of action

The table below uses card-related procedures and similar requests to set out what to present to the customer and what the bank checks. This is a design example from MIF, not a description of Backbase’s settings or a universal set of authentication requirements.

Every row assumes the necessary authentication and authorization checks. Define the conditions for additional authentication or staff review according to the transaction and each bank’s own requirements.

Example action	Details to present to the customer	Additional checks by the bank	Supporting systems and procedures (examples)
Temporary card lock, where offered	Card identification; scope of the lock; whether and how it can be lifted	Whether the requester is authorized to act on that card; current card status; impact of an incorrect lock	Conversational interface; authentication and authorization; card management
Blocking and replacing a lost card	Card identification; delivery address; what happens to the old card; fees; expected replacement time	Replacement requirements; any change to the delivery address; signs of fraud; additional verification requirements	Approval workflow; card management; staff-assisted processing
Changing a registered address or contact details	Details being changed and the new information; implications for notifications and authentication	Current authentication status; existing verification channels; the bank’s requirements for making changes	Customer data management; authentication infrastructure; change-management procedures
Funds transfer	Source account; amount; recipient; fees; when the transfer will be made	Authorization to make the transfer; applicable limits; signs of fraud; any required additional authentication or approval	Transaction authorization; payment processing; fraud detection; exception handling

The last column maps each check to where it is implemented: the conversational product, the authentication and authorization infrastructure, connected systems, or internal procedures. When a single check is implemented across several mechanisms, make clear who configures it and where it is performed.

As you adapt the table to your bank, flag any check whose implementation is unclear. Clarify where that check is performed before deployment.

What else to confirm before deployment

The following are points worth confirming before deployment:

• The definition of a consequential request and the list of actions that require confirmation
• How confirmation is presented (displayed or spoken wording, whether re-confirmation is required)
• The exact fields recorded, the level of detail, retention periods and access rights
• The specific criteria that trigger a handoff to staff and how they are configured

We could not find these details in the announcement or the product page we reviewed. This does not mean the features are absent; these are items to confirm in product documentation and contractual specifications before deployment.

Summary

Explicit customer confirmation can serve as a control for obtaining agreement to the action presented. It does not replace the bank’s authentication, authorization, fraud checks, or approval requirements.

MIF emphasizes linking the details presented to the customer, their response, the bank’s decision, and the action carried out. Request confirmation again when key details change, and do not treat a refusal or an ambiguous response as permission to proceed.

Keep records that allow these links to be reviewed later, while protecting personal information and credentials.

Before deployment, define the customer confirmation and bank-side checks required for each action. Verify that those requirements are implemented in the system’s configuration, processing, and records.

Sources and scope

This article draws on the following sources, reviewed as of October 30, 2026:

• Backbase’s press release “Backbase launches Conversational Banking to turn customer conversations into governed banking action” (dated October 8, 2026)
• Backbase’s product page “Conversational Banking”

The descriptions of the product’s features and controls in this article are taken from the company’s published materials and have not been independently tested by MIF.

The action-specific design examples and the recommendations for linking confirmation, execution, records, and testing are MIF’s proposals based on the published materials.

Product availability and specifications are subject to change. If you are considering adoption, please check the provider’s latest official information and contractual specifications.