Agentic investing: what banks should learn from the new interface

On 25 August 2026, Scalable Capital launched Agentic Investing, allowing customers to use core brokerage functions through external AI assistants. Scalable describes itself as the “first bank in Europe” to provide this access. That is the company’s claim, not an independently established market classification. Reuters independently confirmed the launch.

For retail banks, the significant change is not just a new feature. It is the relocation of the customer touchpoint. When a customer states an intention in ChatGPT, Claude or Grok, the journey no longer begins in the banking app. The bank remains responsible for the account, execution and controls, but it no longer automatically owns the interface, conversational context or first moment of guidance.

From app access to an executable interface

According to Scalable’s official announcement, Agentic Investing supports trading, savings plans, watchlists, price alerts, news and market data. Access is provided through the Model Context Protocol (MCP) and a command-line interface (CLI), enabling connections to major chatbots as well as local assistants.

This combination changes the competitive frame. A strong app remains important, but it is no longer sufficient as the only distribution channel. Banks must decide which services should be available as safely callable tools and how their identity remains visible when an external assistant conducts the interaction. Our analysis of dynamic banking engagement platforms explains why customer dialogue should not depend on a single front end.

Interface ownership will therefore mean less than designing every screen. It will mean controlling interaction rules, response quality and secure execution. Product teams need a channel-independent journey definition: what may an assistant explain, prepare or execute, and when must it hand the customer back to the bank?

Consent must extend to individual tools

A broad login is too coarse for agentic interactions. Authorisation should be limited by tool, account, action and, where appropriate, amount or duration. An assistant could be permitted to read market data and update a watchlist without being allowed to trade or modify a savings plan. Customers need scopes that are clearly named, visible and revocable at any time.

Scalable applies a firm gate to orders. Its official help page describes a mandatory two-step process. First, the customer receives a preview containing current details, costs, disclosures and warnings. A fresh, explicit confirmation is then required; no order is placed without it. Scalable also states that the function does not constitute investment advice.

For banks, this pattern matters more than the individual channel. Confirmation gates should be placed where a preparatory step acquires financial or legal effect. Confirmation must not be inferred from an earlier chat message. It has to refer to the current, fully presented transaction and must not be silently reused or anticipated by the assistant.

Observability becomes part of the product

An agentic interface needs a complete audit trail. Records should capture not only the outcome and timestamp, but also the tool called, scope granted, relevant parameters, preview, warnings, confirmation and final response. Operations, compliance and support can then determine whether a failure originated in the assistant, authorisation layer, bank tool or execution process.

Revocation deserves the same attention as consent. Customers should be able to remove an individual assistant or scope immediately. Tokens, sessions and pending delegations must then become reliably invalid. Banks also need an emergency control that can suspend a tool or integration centrally without disabling every digital service.

Service boundaries must be visible within the journey. The external provider is responsible for its interface and conversation; the bank is responsible for its tools, permissions and execution. Customers should not be passed back and forth between support teams. Cases need a shared reference, defined handover points and a clear statement of where binding order information can be found.

Measure adoption across the lifecycle

Connection counts alone reveal little about adoption. A useful measurement model follows the lifecycle: successfully authorised connections, use by tool, abandonment between preview and confirmation, failed executions, revocations, support contacts and repeat use. Metrics should be segmented by assistant and scope without storing sensitive conversation content unnecessarily.

The shift resembles the move towards operational agentic commerce: intent is expressed outside the provider, while controlled tools execute the transaction. Banks should therefore avoid starting with unrestricted access. A limited set of clearly described functions, verifiable approvals and resilient operating processes provides a stronger basis for scaling.

Five takeaways

1. The customer interface may sit outside the bank, but responsibility for secure execution remains with the bank.

2. Authorisation needs understandable scopes for tools, accounts and actions rather than blanket access.

3. Financially consequential actions require a current preview and fresh, explicit confirmation.

4. Audit trails, revocation and clear support boundaries must be designed into the product.

5. Success should be measured across activation, use, confirmation, execution, revocation and retention.

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.