AI assistants in Peruvian banking: the next step needs data and trust

Context

Conversation is becoming a more important part of digital banking. For teams building these services, the challenge goes beyond answering questions. It also involves connecting a customer's intention to reliable information and, where appropriate, to an authorized action.

In Peru, this shift combines existing services with a vision still taking shape. Understanding that distinction makes it easier to assess progress without treating every chatbot as an agent capable of managing money.

The news: a direction of travel, not a confirmed launch

On October 15, 2026, El Comercio reported that Credicorp AI executive Rafael Lemor outlined a move toward assistants executing tasks with autonomy determined by users. At the same BCP conference, Patricia Wissar announced an upcoming refresh of its app experience. This describes a strategic direction; it does not confirm an autonomous agent is available in Banca Móvil BCP or give a launch date for that capability. [1]

The useful question is what must happen between that vision and an everyday experience customers can understand and control.

What exists today, and where

Official pages establish several different starting points:

• BCP presents Clara with generative AI on WhatsApp for product questions and banking information. This does not establish an equivalent integration within Banca Móvil. [2]
• BBVA Perú provides access to Blue within its app for questions and guidance, with human escalation. Its page does not establish autonomous transfer execution. [3]
• On March 6, 2024, Interbank announced that AVI was integrated into its app to answer customer questions. [4]
• Mibanco's current terms describe an AI-based WhatsApp interface through which customers can contract certain products. They also acknowledge possible errors and provide for human assistance. [5]

A separate announcement, dated August 10, 2026, covers Interbank's agreement with Anthropic to expand enterprise AI use. It is not an announcement of a customer-facing Claude assistant within the bank's app. [6]

These distinctions matter. Channel, underlying technology, and functional scope are separate dimensions. An assistant's availability does not establish which model it uses, which information it can access, or which actions it can perform.

Three levels worth distinguishing

The following framework is Cloudata's analysis for evaluating products. It does not describe a confirmed architecture at any of the banks mentioned.

The first level is answering. An assistant explains a product or helps someone find an option. Its main challenge is retrieving current information and recognizing when a question exceeds its scope.

The second level is interpreting. A question such as “How did my spending change this month?” requires access to authorized transactions, definitions of periods and categories, and an explanation of the result. A fluent answer can still be wrong if data is incomplete or a refund is treated as ordinary income.

The third level is acting. An instruction that changes an account's state needs a different process from an explanation. The experience must make clear what the person requested, what is about to happen, what requires confirmation, and what actually occurred.

This distinction supports specific tests and permissions. It also helps customers understand why one question receives an immediate answer while another request needs additional steps. A product can be useful at one level without offering all three.

Integration determines usefulness

As an implementation approach, a language model should work through bounded services. The conversational interface interprets a request; authorized systems provide information or process actions under verifiable rules.

That requires practical questions to be settled before designing an appealing conversation. Which system is authoritative for a balance? How is a pending transaction identified? What happens when two services return information updated at different times? How can a repeated instruction be prevented after a connection failure?

Teams can organize integrations around clear contracts: accepted inputs, expected outputs, possible errors, and conditions for proceeding. The quality of those contracts directly affects what an assistant can responsibly promise.

It also helps to separate general knowledge from customer-specific information. Explaining a fee and investigating a particular charge require different sources and permissions. Combining them without clear controls makes errors harder to detect and answers harder to explain.

The conversational layer should therefore make the underlying service easier to use while preserving its boundaries. Replacing a menu with text is only part of the work; the interaction still needs a reliable connection to the operation it represents.

Trust is designed into each step

In our view, a trustworthy experience makes its limits understandable. Customers need to know whether they are receiving an explanation, an estimate, or confirmation that an operation has been recorded.

Before a consequential action, the interface should present the relevant details. Verification can vary with risk, but natural conversation does not remove the need for identity checks, permissions, and consent.

How uncertainty is communicated matters too. If an assistant cannot find a transaction or receives incomplete information, it should say so and offer a resolution path. Filling a gap with an assumption can turn a data problem into a trust problem.

Continuity with human service is another design requirement. A useful handoff preserves necessary context, avoids repeated questions, and allows the user's attempted task to be reviewed. This should be built with access controls and data minimization rather than by transferring an entire conversation history indiscriminately.

The system should also distinguish an attempted action from a completed one. Customers should not have to infer whether a request succeeded from the assistant's tone. A clear result, including a failure when necessary, is more useful than a reassuring but ambiguous response.

Measure outcomes, not just conversations

For gradual implementation, we propose measuring correctly completed tasks, answers supported by current sources, detected errors, useful escalations, and customer understanding of confirmations. Response speed matters, but it cannot replace verification of the outcome.

A narrowly scoped pilot can test common questions before adding more sensitive actions. Evaluations should include ambiguous language, out-of-scope requests, interruptions, and disagreements between systems. These cases reveal whether the experience remains dependable beyond an ideal demonstration.

Conversational banking offers a real opportunity to simplify interactions. Turning that opportunity into sustained value requires less visible work: consistent data, robust integration, explicit permissions, and ways to correct mistakes. The next evolution of the banking app will depend on those decisions as much as on a model's conversational ability.