Subscription overload: why I'm done linking my bank to apps
Subscription-tracker apps usually solve the problem by asking for your bank login. In 2026 there's a calmer way — on-device bill scanning, no Plaid, no aggregator.
I counted my subscriptions last Sunday. I’d been telling myself “maybe ten, fifteen.” It was twenty-six. Spotify, Netflix, two cloud storage tiers I forgot existed, a domain registrar from a side project I shelved in 2023, ChatGPT, a meditation app I haven’t opened in eight months. The total wasn’t catastrophic. It was invisible — that’s the part that bothers me.
This is the problem every “subscription tracker” app tries to solve. And in 2026, the default solution is still: give us your bank login. I’d like to argue that this is worse than the problem.
The aggregator pattern, briefly
Most subscription trackers in the App Store and Play Store use the same architecture. You install the app, it asks you to connect your bank account, and it routes that connection through an aggregator — Plaid in the US, Salt Edge in Europe, Truelayer in the UK. The aggregator scrapes your transactions, the app reads them, and you get a list of recurring charges.
The product is genuinely useful. The price is your entire transaction history flowing through one or two extra companies, indefinitely, with limited insight into what they retain and what they don’t.
In return for “did I forget I’m paying for Apple Music?” you’ve handed three parties:
- The app itself
- The aggregator
- Whoever the aggregator partners with
read-only access to everything you’ve bought this month. Groceries, healthcare, where you went out for dinner, the political donation you’d rather not have on a third-party log. The aggregator pinky-promises to throw away anything not related to subscriptions. They probably do. They also keep enough metadata to power a thriving fraud-detection-and-marketing-attribution business on the side, which tells you what they consider valuable.
What I’d actually need
The honest job of a subscription tracker is small. For my twenty-six subscriptions I need four fields each:
- The service name
- The amount and currency
- The billing cycle (monthly, yearly)
- The next charge date
That’s it. To get those four fields, I do not need my bank’s transaction stream piped through someone in another country. I need a way to get the data into the app without typing it.
This is where the “we’ll scan your email” alternative comes in. Some apps ask for Gmail/Outlook OAuth and parse the receipts you’ve been sent over the years. It’s better than bank-linking — your email provider already had those receipts — but you’ve now given a third party scope to read every email you’ve ever received. That’s a smaller breach surface, but it’s still a breach surface. The app’s privacy policy might say “we only read receipts.” The OAuth grant says you trusted them with the inbox.
The third option, which is the one I went with
There’s a third option that’s been sitting in plain sight: point your camera at the bill.
Every subscription you have sent you something — a confirmation email, a renewal reminder, an invoice, a receipt. On your phone, that something is two taps and a camera shutter from being a row in a subscription tracker. On-device OCR reads the text, a small extractor pulls the four fields out, and you confirm with a tap. No bank linking, no email scope, no aggregator.
I built Subly on this principle. The architecture is the privacy policy:
- The bill image is processed locally on your device with Google’s ML Kit.
- The extracted fields are saved on the device. There’s no server.
- The captured image is not uploaded and is not kept after processing.
- There is no account to create, no OAuth grant to revoke later, no aggregator in the loop.
What you give up is “automatic detection of new subscriptions.” If you sign up for something tomorrow, Subly doesn’t know until you scan or add it. That’s an honest trade-off and the app is built to make manual entry fast: you’ll snap a bill in 5 seconds; you’ll add one manually in 15.
The “but it’s just metadata” defense
The standard defense for bank-linking is: it’s only transaction metadata, not the money itself, and the aggregators are regulated. Both true.
The problem isn’t that today’s aggregator is malicious. The problem is that you don’t get to time-travel forward to see who they sell to, get acquired by, or get breached by. A 2025 study by the German Federal Office for Information Security found that the average European had their banking data exposed through some third party at least once in the previous five years, usually via a downstream partner of an aggregator they connected to and forgot about.
You can stop using the subscription tracker tomorrow. You can revoke the bank connection. The records the aggregator already has? Those are out there, governed by retention policies that change every time the aggregator updates its ToS.
The most private byte is the one that never leaves the phone.
Reducing the number of parties that ever touch your transaction stream is the cleanest privacy win available. The number is one less if your subscription tracker doesn’t read your bank at all.
”But the categorization is so good!”
It is. I’ll concede it. Bank-linking apps know that a $9.99 charge from “Spotify USA Inc.” on the 14th of every month is Spotify. With OCR + manual entry, you tell the app what it is, once.
Two things lessen the pain:
- Once per subscription, not per charge. You scan one receipt; the next twelve months are tracked.
- OCR + service dictionary. Subly’s dictionary recognizes the top 200 subscription services from the receipt text and pre-fills the name and category, so you usually just confirm.
The result is roughly the same number of taps over a year — minus the chunk of your life that lives in an aggregator’s log file forever.
What this changes about pricing
A side effect of refusing bank-linking: the business model gets simpler. There’s no aggregator API bill to amortize, no monthly per-connection cost to the third party, no compliance surface around financial-data brokering. The app is a one-time-purchase or modest subscription, the developer doesn’t need a Series A to keep the lights on, and the alignment between what the app sells (helping you track subscriptions) and what the company makes money from (you paying for the app) actually matches.
The “free” subscription trackers that bank-link are not free. You pay with the recurring privilege of being a data point in someone’s enterprise sales deck.
The honest pitch
Here’s the pitch, with the trade-offs on the table:
- Pros: No bank linking. No aggregators. No email OAuth. No account. Your subscription list never leaves your phone. The receipt photo is processed and discarded.
- Cons: You have to scan or type each subscription once. New subscriptions aren’t auto-detected — you add them when you see the confirmation email.
For me — and, I’d guess, for anyone who’s read this far without rolling their eyes — that’s the right trade. I’d rather take twenty seconds to scan a Spotify receipt than spend the next decade with a copy of my bank statement in someone else’s database.
If you’ve been on the fence about installing one of the bank-linking apps because something about it feels off: trust that instinct. The technology lets us do this differently in 2026. Subly is one way; even if you don’t use Subly, demand the same architecture from whoever you do use. Ask the simple question: does the data leave my phone? If the answer is yes, ask why — and what they’d have to do to make the answer no.
The right answer is usually “less than they think.”
// Related reading
More from the journal
Privacy-first OCR on Android: how Subly reads bills without the cloud
A practical 2026 guide to on-device OCR on Android with ML Kit Text Recognition — the setup, the code, and the field extraction tricks that keep user data off your servers.
Reliable Android reminders in 2026: WorkManager, exact alarms, and the new battery rules
How to ship reminders on Android in 2026 that actually fire — WorkManager vs AlarmManager, SCHEDULE_EXACT_ALARM, POST_NOTIFICATIONS, and the OEM quirks that still bite.
Local-first Android in 2026: SQLite, Room, and keeping user data on the device
A 2026 guide to building local-first Android apps with Room and SQLite — schema design, migrations, WAL, exports, and when (and when not) to add sync.