Yes, with the customer's consent and only through the regulated route. An AI agent can read account data the customer has authorised a provider to share, for the purpose they agreed to. It must never hold the customer's bank login, reuse the data for other purposes, or authenticate payments in the customer's place.
How does open banking access actually work?
The customer tells a provider, such as a lender or a budgeting app, that it may see their accounts at another bank. The customer then authenticates with their own bank, which issues the provider a time-limited permission. The provider calls the bank's interface with that permission and receives the data. At no point does the provider see the customer's password. The mechanics are explained in what open banking is.
The agent sits inside the provider. It works with the data the provider has received under that consent. It does not hold a separate key, and it does not reach the bank directly. That structure is what keeps the agent's access bounded: it can see only what the customer agreed to share, for as long as the permission lasts.
What is the difference between reading data and initiating a payment?
Open banking supports two broad things: reading account information and initiating payments from the customer's account.
Reading is the lower-risk side. The agent can analyse transactions, confirm income or check a balance. If it misreads something, the effect is on the analysis, which can be reviewed.
Initiating a payment is different. The money leaves the customer's account. Even when an agent prepares the payment, the customer must approve it with their own bank, using strong customer authentication. The agent cannot complete that step for them. Treat payment initiation as a money-moving capability with its own bounds, separate from reading.
What may the agent do, and where must it stop?
| Task | The agent | Where it stops |
|---|---|---|
| Reading balances and transactions | Reads them under the customer's consent, at depth 1 | Data outside the consented accounts or period |
| Categorising spending | Sorts transactions and summarises income and outgoings | Drawing conclusions about health, beliefs or other sensitive matters |
| Using the data for the agreed purpose | Feeds it into the affordability check or budget the customer asked for | Any other use, including marketing |
| Preparing a payment | Drafts amount, payee and reference for the customer to approve | Approving or authenticating it |
| Renewing consent | Tells the customer when consent is due to expire | Pressuring the customer or renewing it for them |
| Storing the data | Keeps what the purpose needs, for as long as it needs it | Keeping full histories indefinitely |
Sensitive inferences deserve a specific mention. Transaction data can reveal medical payments, religious donations or trade union subscriptions. An agent that summarises spending must not turn those into labels, because that creates special-category data the customer never agreed to share.
A worked example
Take an online lender assessing a personal loan. The applicant agrees to share twelve months of current account data through open banking.
The agent reads the transactions and identifies regular salary credits, rent, utility payments and two existing credit agreements. It drafts an income and expenditure summary for the affordability check. It notices a recurring payment to a clinic, and leaves it in the general "other outgoings" total without labelling it.
The applicant's consent covers the loan assessment. Three months later, the marketing team asks whether the same data could be used to offer the customer a savings product. The agent's role scope does not include that purpose, so the request is refused, and the record shows why.
What controls keep it within bounds?
- Consent-scoped access. The agent's access follows the customer's consent: which accounts, which data, for how long. The platform checks it on every read.
- Purpose limitation. Under GDPR Article 5 and its UK equivalent, data collected for one purpose should not be used for another. Encode the purpose in the agent's scope, not just in a policy.
- No credentials. The agent never asks for or stores the customer's bank login. Any agent that does is outside the open banking model.
- Access requests through the proper route. If the agent needs broader internal access to do its job, it should ask through your access management process, as described in letting an AI agent request access through your access management system.
- A full record. Each data request, the consent it relied on and what was done with the data are filed.
The same discipline applies inside a bank: our answer on whether an AI support agent can access customer account data covers the internal case, and AI agents in banking: what they may and may not do sets out the wider limits.
Questions people ask
Can an agent act as the customer's open banking provider?
The provider is a regulated firm, not an agent. An agent can work inside a provider's service, within the permissions that firm holds and the consent the customer gave it.
What happens when consent expires?
Access stops. The agent can tell the customer that their consent is due to lapse and explain how to renew it, but the renewal is the customer's decision, made with their bank.
Can the agent use open banking data to monitor the customer for fraud?
Only if that use falls within the purpose and legal basis the provider relies on. Fraud monitoring may have its own lawful basis, but it should be set out clearly rather than assumed.