A few months ago, when I wanted Cuéntamo to read my bank transactions instead of forcing me to upload a spreadsheet every month, I did what anyone would do: I asked for prices.
The answer made it pretty clear to me why the personal-finance app market is the way it is.
The toll
€600 a month, minimum. And that was the cheap one.
That price doesn’t buy you an open bar: it comes with a low cap on bank connections. If you also want card transactions, it goes up. If you want investment operations, it goes up again.
Let’s do the maths slowly, because that’s where it gets interesting. Six hundred euros a month is €7,200 a year in fixed cost. Fixed means it lands on the 1st of the month no matter how many customers you have.
If your app costs €5 a month, you need around 120 paying subscribers just to cover that bill. Not to make money: to avoid losing it. A hundred and twenty people paying, before you subtract VAT, the payment-gateway fee, the server, and of course before paying yourself a single euro for your hours.
And now the part that actually made me close the tab.
The squeeze
That fixed cost demands volume. You need hundreds of paying users to absorb it.
But the cheap tier has a low connection cap. So when you finally get those hundreds of users, they no longer fit in the plan and you jump to the next tier, which costs more. And back to square one.
It’s not that bank aggregation is expensive. It’s that it’s designed so you can’t start small. There’s no ramp. There’s a step, and either you clear it in one stride or you’re left out.
In my particular case there was a cherry on top: Cuéntamo handles investments (broker operations, positions, fixed income). So the expensive part of the catalogue, the surcharge for investment transactions, was exactly the part I needed. It wasn’t that the route was expensive for me: it was closed.
What this does to the market
When you lay this out, something that’s baffling as a user suddenly makes sense.
In the last few months a lot of personal-finance apps have appeared. If you look closely, you’ll see they split into two very clean groups: the ones that connect to your bank and the ones that make you upload a spreadsheet. There’s almost no middle ground.
It’s not that the latter are lazy or worse. It’s that, today, bank connectivity is only affordable to whoever arrives with serious funding behind them, or belongs to a group that already pays for that infrastructure for some other reason.
And here I want to be fair, because it’s easy to tell this as if there were a villain, and there isn’t.
PSD2 (the European regulation that opened bank data to third parties) did what it promised: it broke the banks’ monopoly over your transactions. And the aggregators operating on that route do real, far-from-trivial work: licences, security, and keeping dozens of integrations alive that break on their own. If you can pay for it and it solves what you need, it’s probably the right tool. I’m not saying they’re superfluous.
What I’m saying is something else: that entry cost has no ramp. Compliance (licences, audits, certifications, infrastructure) is so expensive that it only holds up when spread across many customers, and that turns the open door into a door with a bouncer. The data is yours, the law says you can take it with you, and even so, reading it programmatically starts at €7,200 a year.
There’s a second detail that took me a while to see, and that I find more important than the price: PSD2 only covers payment accounts. It doesn’t reach store cards, or investment statements, or pension plans, or invoices, or shopping receipts. Precisely the long tail of documents a user needs to have their finances complete. So even paying the toll, I wouldn’t have solved the whole problem: I’d have paid €7,200 a year for one part of it.
And to be completely fair: if you’re an individual and you only want your current accounts, there’s even a free route. Services like Enable Banking let you access the transactions of your own payment accounts under PSD2 at no cost. It’s genuinely useful and worth knowing. But it runs into the same wall: payment accounts and nothing else. No cards, no investments —which was exactly what I needed.
The way I turned it around
At some point I realised something that now seems obvious: when I log into my bank’s website, the data is already in my browser. I’m looking at it. It’s mine. It reaches my computer without any intermediary having to authorise it.
The intermediary isn’t needed to get the data. It’s needed to get it from a server, without me being there. And that’s a need of the business model, not of the problem.
So I built Habeas: a browser extension that reads your own data from your own session, on your machine, and drops it wherever you say (a folder, your Drive, or the app you use). No servers in the middle, no storing your credentials, no one else seeing them. I already explained in more detail why I made it, so I won’t repeat myself.
It’s worth saying what it is and what it isn’t. Habeas is not an alternative aggregator, nor does it compete with PSD2 on its own turf. It’s a different mechanism: personal data portability (Article 20 of the GDPR) carried out by the user themselves, in their browser. It doesn’t initiate payments, it doesn’t aggregate anything on a server, and it isn’t subject to that regulation because it doesn’t do what that regulation regulates. For an entity that needs continuous, unattended access to payment accounts, the regulated route is still the right one. But it reaches the long tail the other doesn’t cover, and it doesn’t ask you for €600 to get started.
What I didn’t say in that earlier article, and it’s the reason for this one, is that it doesn’t have to be just for me.
If you build a finance app, this is yours too
Habeas is free software (AGPL-3.0) and has been designed from the start so any application can use it. There’s no whitelist and no agreements: any website can ask its user’s Habeas for data, and can only receive it on its own domain (that rule is in the code, not in a contract).
In practice that means:
- Integrating it is an afternoon’s work. Your app requests permission, the user approves on a Habeas screen, and from then on you receive the transactions at an endpoint of yours, already normalised. It’s all explained, with the two integration models and copy-paste code, at habeas.dev/developers.
- Adding a bank is writing a definition file, not maintaining a fragile scraper. It’s data, not executable code, and it lives in a community catalogue.
- And it’s a selling point for your users, not just a saving for you: their credentials never leave their browser, and there’s no third party piling up anyone’s financial history.
And adding a service that isn’t in the catalogue yet doesn’t require coding either: with a session recording-and-detection system, the user can generate the source themselves from how they use the service; or send their anonymised session to the Habeas team so we build the adapter for a service that isn’t supported yet. The catalogue grows with use, not just with whoever writes code.
Here comes the ask, and I’ll make it plainly: if you run a personal-finance app and hit the same pricing wall, let’s talk. The more of us there are, the more banks the catalogue covers, and an adapter you write serves the rest of us too. It’s one of the few cases where collaborating with the competition pays off: adapters are shared plumbing, and where we really compete is on the product.
What I won’t sell you
It wouldn’t be honest to finish without the limits, because there are some:
- The user has to log in themselves. Habeas doesn’t store passwords or sign in on its own; if there’s no active session, it opens the bank’s tab and waits. That’s a design decision, not a shortcoming, but it means there’s no silent sync at three in the morning.
- If the bank changes its website, the adapter has to be updated. The difference from an aggregator is that here you can fix it yourself instead of waiting for it to come up on their roadmap.
- Each service has its own terms of use, and complying with them is the responsibility of whoever uses it. Habeas operates on your own data and in your own session, which is exactly what the GDPR right to portability contemplates, but it’s not an open bar.
All in all, I prefer these limitations to the alternative, which was not being able to offer the feature at all.
If you build something and want to integrate it, start at habeas.dev/developers. The code is at github.com/habeas-dev/habeas, under AGPL-3.0. And if the number at the start rang a bell because you’ve seen it in a quote too, write to me.
Leave a Reply