Asking an assistant to explain a bank statement and asking it to submit a payment are different kinds of delegation. The second requires access that can affect an account. A sensible instruction from the customer does not automatically become a restriction the banking system can enforce.
That is the practical issue behind Royal Bank of Canada’s decision to block outside personal AI agents from directly accessing its signed-in digital services.
What RBC actually announced
In its October 27, 2026 notice, RBC said it would block third-party personal AI agents from direct access to authenticated digital properties, including online banking. It cited security and privacy concerns and said existing agent connections would stop working.
The notice leaves customers able to use the bank’s official website, mobile app and its own digital tools. It does not specify one universal cutoff moment for every connection.
This is a bank access policy. The announcement does not establish a new Canadian law or a prohibition on discussing money with a chatbot. Its scope matters: an explanation outside an account is different from an outside agent operating behind the login.
RBC’s statement supplies the policy and the bank’s stated rationale. It does not establish how every future dispute involving an assistant would be resolved.
A successful login leaves another question unanswered
Authentication checks who is entering, or whether they possess the required credentials. Authorization determines what that identity may do.
Consider a hypothetical instruction: prepare a payment to the electricity supplier for 120 Canadian dollars. The customer has specified a recipient, an amount and a task. If the assistant instead receives ordinary account credentials, those limits may exist only in the conversation.
Banks can apply transaction limits and other checks, so ordinary credentials do not necessarily permit unlimited transfers. But those controls are different from the particular boundary the customer requested. ‘Prepare this bill’ is enforceable only if the access and approval process can distinguish preparing that bill from other account actions. Wording in a conversation does not create that technical restriction by itself.
A payment mistake is not automatically fraud
RBC’s Electronic Access Agreement permits the bank to treat instructions submitted under a customer’s sign-in credentials as that customer’s instructions, while reserving the ability to refuse them. Its security guarantee is conditional and includes exclusions involving credential sharing and activity the customer authorizes or contributes to.
Imagine an assistant selecting the wrong saved payee. If the customer then approves the displayed recipient and amount, the eventual complaint differs from a stranger making a payment without permission. The unwanted outcome alone does not establish that the transaction was unauthorized.
Now imagine the assistant acts beyond the customer’s instructions. That changes the questions: what access was shared, what action was authorized, and what do the records establish? This example has no automatic reimbursement answer.
A contractual guarantee needs to be read alongside the applicable consumer protections and the facts. Neither “the software did it” nor “a password was used” settles every dispute.
Independent consumer guidance adds an important limit
The Financial Consumer Agency of Canada’s guidance on unauthorized credit and debit transactions says federally regulated institutions must investigate disputed transactions. Authentication technology being used is not, by itself, sufficient to hold a customer responsible for a transaction they did not authorize.
That guidance concerns credit and debit transaction protections. It is not a blanket promise covering every action an AI agent could take in online banking.
FCAC also warned in March 2018 that sharing banking login details with third-party services could breach account agreements and expose consumers to losses. The warning predates today’s personal agents. Better automation can make an old access problem easier to encounter without removing it.
Read together, these sources support caution about shared credentials while preserving the need to investigate an actual dispute. They do not support either universal reimbursement or universal loss of protection.
Privacy can be affected before money moves
Account access can reveal information even when no payment is submitted. Transaction histories can expose recipients, purchases and patterns of activity.
Consider a budgeting task. The assistant may need selected amounts and categories. That does not necessarily require a complete history or the ability to initiate a transfer. Data access and payment authority should be evaluated separately.
A useful permission description answers concrete questions: which information, which actions, which recipient, and for how long? “Help with my finances” leaves most of those unresolved.
What narrower delegation could look like
Microsoft’s security guidance for agents recommends dedicated identities, limited permissions, controlled tool access and records that establish authority. These are general engineering principles, not an announcement of an approved RBC integration.
For the hypothetical electricity bill, a narrower design might let an assistant prepare a draft while requiring the customer to approve the exact payee and amount. A different tool might supply selected transaction data without payment capability. These are examples of possible boundaries, not features promised by RBC.
The distinction is between trusting software to follow a request and giving it access that prevents unrelated actions. Logs also matter: they should help establish what was requested, permitted and submitted.
Open banking describes a different access model
FCAC’s consumer-driven banking guidance describes sharing agreed financial information through APIs without handing over banking login details. The customer chooses the information, recipient and sharing duration.
That model helps explain why a recognized connection can differ from a service signing in as the customer. Permission to share data also differs from authority to move funds. The existence of open-banking guidance does not prove that a particular assistant has an authorized RBC connection.
Before connecting any financial tool, check its actual access and the bank’s current terms. If credentials may already be exposed, contact the bank through its official channels about securing the account. Report suspicious activity promptly and review the bank’s own transaction records.
RBC’s restriction addresses a problem intelligence alone cannot solve. An assistant may understand the errand while still holding access broader than the errand requires. Safe delegation depends on the permissions, records and protections around that access.
