Why your budgeting app should not need your bank login

Automatic transaction import is the headline feature of nearly every budgeting app. Connect your bank, and every purchase appears categorised without you lifting a finger. It's genuinely convenient, and the convenience is real.

It also has a price that doesn't appear on the pricing page. Worth knowing what it is before you decide it's worth paying.

What "connect your bank" actually does

Two mechanisms are in play, and they're very different.

Open banking APIs (PSD2 in Europe, similar frameworks elsewhere) are the good version. You authenticate directly with your bank, the bank issues a scoped token, and the app gets read-only access to transaction data for a limited period — typically 90 days before you must re-consent. Your credentials never touch the app. This is regulated, auditable, and revocable from your bank's own interface.

Screen scraping is the other version, still common in markets without a mature open banking regime. You give the app your actual online banking username and password. It stores them, logs in as you, and reads the screen.

If you're going to connect an account, it matters enormously which of these you're agreeing to, and the signup flow rarely makes it obvious. The tell: if you type your bank password into the app's own interface rather than being redirected to your bank's site, it's scraping.

The aggregator in the middle

Here's the part most people don't realise: your budgeting app probably isn't the one connecting to your bank. It's using an aggregator — Plaid, Tink, TrueLayer, Salt Edge, Yodlee and a handful of others sit between essentially every finance app and essentially every bank.

So your transaction history is held by at least three parties: your bank, the aggregator, and the app. Each has its own privacy policy, its own retention period, its own breach history and its own corporate future. You agreed to one of those policies attentively and two of them by reference.

This isn't a claim that any specific company is careless. It's a structural observation: the number of organisations holding a complete record of your spending is larger than the number you chose.

What a transaction history reveals

It's worth being concrete about the sensitivity of this dataset, because "financial data" sounds abstract and it isn't.

A year of transactions shows where you live and work, when you travel and where, what you eat, your medical appointments and often what they were for, which pharmacy you use, whether you drink, whether you gamble, which charities and political causes you support, when your relationship status changed, whether you're job hunting, and when your income dropped.

Very little else you produce is this revealing. It's arguably more revealing than your browser history, because it's verified — a purchase is an action, not a click.

Where the business model points

Free budgeting apps have to make money somehow, and there are only a few options: sell subscriptions, sell you financial products on commission, or sell insights derived from your data.

The third is common and usually disclosed in language that's technically accurate and practically opaque — "anonymised and aggregated analytics shared with partners". Anonymisation of transaction-level data is notoriously fragile; a handful of merchant-plus-date pairs is often enough to re-identify an individual within a large dataset.

The second is subtler and more consequential day to day. If an app earns a commission for referring you to a credit card, a loan or an investment product, then its recommendations have an interest that is not identical to yours. That's not fraud; it's just an incentive worth knowing about while you read the advice.

The question to ask of any free finance app is simply: what pays for this? If you can't find a clear answer in under two minutes, you probably are it.

The case for typing it in yourself

Manual entry sounds like a step backwards. In practice it has three properties automatic import doesn't:

No third party. If nothing connects to your bank, there's no aggregator, no token, no stored credential and no breach surface beyond your own device. The privacy guarantee stops being a policy you have to trust and becomes an architectural fact.

You notice your spending. This is the one people don't expect. Typing an amount at the moment you spend it creates a small feedback loop that automatic import removes entirely. Imported spending is reviewed weeks later as a list of numbers; entered spending is felt. Several studies of payment friction point the same direction, and most people who switch report the effect within a month.

Nothing breaks. Bank connections fail constantly — re-authentication expiring, a bank changing its API, an aggregator dropping an institution. Anyone who's used an import-based app for a year has had the experience of discovering three weeks of missing data. Manual entries don't have an upstream to break.

The obvious cost is effort. Realistically it's five to ten seconds per transaction, twenty to forty transactions a month, so a few minutes monthly — assuming your app is built for fast entry rather than thorough entry. Fixed and predictable costs like rent should be recurring entries you set up once and never touch.

A reasonable middle position

This isn't an argument that automatic import is indefensible. It's an argument for choosing deliberately.

A defensible setup for most people:

• Use open banking, never credential scraping. If the app asks you to type your bank password into its own form, decline.
• Prefer read-only access, and check your bank's connected-apps page every few months to revoke what you no longer use.
• Know what pays for the app. Paid is often the more private option, oddly.
• Keep the sensitive accounts manual. Many people happily import the everyday current account and keep savings, investments or a business account out of it entirely.

And if you'd rather not have your spending history sitting on anyone's server at all — that option exists too, and the trade is a few minutes a month.