A personal finance agent that cannot move money

A personal finance agent is one of the more useful things you can build. It reads your accounts, tells you what changed, finds the subscription you forgot, and warns you before a bill lands in a thin week.

None of that requires the ability to move money.

That sounds obvious written down, and yet most people connect a banking integration with whatever permissions the quickstart asked for. Open banking gives you a cleaner option, and it is worth understanding because it is stronger than anything you can write in code.

Two consents, not one permission

Open banking regulation splits bank access into two separate regulated services.

Account information services, or AIS. Read balances, transactions, account details and standing orders. Read only. There is no write operation in this service.

Payment initiation services, or PIS. Start a payment from your account to someone else. A separate consent, a separate authorisation flow, and usually a separate approval in your banking app each time.

These are not two checkboxes on one screen. They are different permissions with different consent journeys, and a provider has to be authorised for each one separately.

Grant AIS and not PIS, and your agent cannot pay anyone. Not because a rule stops it. Because the capability does not exist in the access you hold.

Why a missing capability beats a good rule

You could grant full access and then write a policy that denies payments. That works, and it is a reasonable second layer.

But a rule is something you maintain. It can be edited, it can have a gap, and it sits in a file you might loosen one evening while debugging something unrelated. A consent you never granted has none of those properties. The bank will refuse the call.

Your financial data is also the most attractive thing an injected instruction could aim at. Your agent reads email, and email is writable by strangers. If a malicious message tells your agent to transfer money, you want the answer to be that no such operation is available, rather than a rule that has to be correct.

Use both layers. Grant AIS only, and add the deny rule as well. The general case for this kind of belt and braces is in API access control for AI agents.

What the aggregators call it

You will probably reach your bank through an aggregator rather than directly. Each one names the two services differently, which is where the confusion starts.

Look for the product split in their docs. One product covers balances and transactions. A different product covers moving money, and it usually requires extra onboarding, extra verification, or a separate contract. If payments need a separate signup step, that step is your control. Do not take it.

Two things to check on the consent screen when you connect an account:

• The permission list should mention accounts, balances and transactions, and should not mention payments, transfers or standing order creation.
• The consent duration. Open banking consents expire, often after ninety days, and you will be asked to reauthorise. That expiry is a feature. Put a note in your calendar rather than looking for a way around it.

In the United States the picture is less tidy, because much of the market still runs on screen scraping with your banking password rather than a regulated consent. If that is your only option, weigh it carefully. Handing over a password gives away far more than an AIS consent does, and it is not scoped to reading.

Read-only is not the same as harmless

Your transaction history is a detailed record of your life. Where you were, what you bought, who you pay, what you earn, which pharmacy you use, whether you gamble.

An agent that reads all of it and sends the lot to a hosted model has shared more than most people intend. So scope the data as well as the permissions.

Pull a date range rather than full history. Ask for the accounts you want analysed, not every account you own. Where the task only needs totals by category, compute the totals locally and put those in the prompt instead of the raw lines. An agent answering whether you overspent on groceries does not need to see the merchant names.

The checklist in a security checklist before connecting any AI assistant to company data works just as well for your own accounts.

Setting it up

npx swytchcode
swy login
swy init --mode=sandbox      # banking aggregators have sandboxes. Use them.

swy get <your-aggregator>
swy auth connect <your-aggregator>
swy auth status

swy discover "list accounts" --project <your-aggregator>
swy discover "list transactions for an account" --project <your-aggregator>
swy discover "get account balance" --project <your-aggregator>
swy list methods <your-aggregator>

swy info <canonical_id>
swy add method <canonical_id>  # accounts, balances, transactions
                              # nothing from the payments product

Use the sandbox first. Banking sandboxes come with fake accounts and fake transactions, so you can get the whole agent working without touching your real data. It is the one category where almost everyone has a test environment available and almost nobody uses it.

Credentials go into a local encrypted store and are attached when a call runs, so no banking token sits in a config file or passes through the model. See the authentication docs.

Then add the second layer:

{
  "id": "finance-agent-reads-only",
  "target": ["<aggregator>.*"],
  "when": { "field": "method", "operator": "in", "value": ["POST", "PUT", "PATCH", "DELETE"] },
  "action": {
    "type": "DENY",
    "message": "The finance agent is read-only"
  }
}

A deny rather than an approval prompt. There is no evening on which you want to be asked whether your agent may send money, so do not build a path where that question can be asked. Check the operators available in the policy reference, and keep the file in version control so you can see when it changed.

What to build with read access

1. A weekly money note. What came in, what went out, what was unusual. The unusual part is where the value is, because you already know roughly what your normal week looks like.
2. Subscription discovery. Find recurring charges, including the annual ones that renewed quietly eleven months after you forgot about them. This one usually pays for itself immediately.
3. A low-balance warning that understands your bills. Read your standing orders and direct debits, read your balance, and tell you when the next few days look tight. Much more useful than a threshold alert from your bank.
4. Receipt matching. Match transactions against receipts in your email and flag the ones with nothing to back them up. Useful at tax time and entirely read-only on both sides.

Notice that none of these want payment access. The pattern holds across most personal automation: the useful work is in reading and preparing, and the actions you would want to automate are the ones you should keep for yourself.

If you are building the same thing for a company rather than yourself, using bank APIs with treasury AI agents covers the corporate version, where the approval thresholds and audit requirements are stricter.

FAQs

Can an AI agent move money from my bank account?

Only if you granted payment initiation consent. If you granted account information consent alone, payment endpoints are not available to your credentials and the bank will refuse the request. Check which one you agreed to on the consent screen.

Why does my bank connection keep expiring?

Open banking consents are time limited, commonly ninety days, and need reauthorisation. This is deliberate, and it means an agent you abandon loses access on its own. Treat the reminder as useful rather than annoying.

Is screen scraping with my banking password acceptable?

It gives away much more than a read consent, and it cannot be scoped to reading. Where a regulated open banking connection is available, prefer it. Where it is not, understand that your password is now held by a third party and that nothing technical stops it being used for more than reading.

Should the agent see every account?

Connect the accounts the task needs. A spending agent needs your current account and credit card. It does not need your savings, your mortgage or a joint account belonging partly to someone else who has not agreed to any of this.

What if I want the agent to pay a bill?

Have it prepare the payment and tell you, then pay it yourself in your banking app. Two taps, and the agent keeps none of the capability. If you insist on automating it, read what a personal AI agent should never be allowed to do first, and gate it on known payees only.

Related reading

• Using bank APIs with treasury AI agents
• What a personal AI agent should never be allowed to do
• API access control for AI agents
• Policy-as-code for AI agents
• Browse all 300+ API integrations