If you run Actual Budget, Firefly III, Beancount, or any other self-hosted finance tool, you probably woke up one morning in mid-2025 to find your free bank-data pipeline broken. GoCardless quietly killed the Nordigen free tier, and with it the easiest way for hobbyists and self-hosters to pull live transactions into their own infrastructure.
This is the post-mortem and the way forward. I'll cover what actually happened, why the obvious "just get your own PSD2 certificate" fix is a trap for individuals, and the realistic cert-free options that still work for self-hosted setups in 2026.
What happened: Nordigen → GoCardless → no more free tier
Nordigen was the darling of the self-hosted finance community. Founded in Latvia, it offered a free Open Banking API covering 2,300+ European banks under PSD2. For years it was the recommended backend for Firefly III's Nordigen importer, for Actual Budget's sync, and for countless Beancount importers and personal scripts.
In 2022 GoCardless acquired Nordigen. For a while the free tier survived as a "free forever" loss-leader on top of GoCardless's paid Instant Bank Pay product. Then, through 2025, the free plan was wound down: usage caps tightened, the self-service signup path degraded, and by mid-2025 new free accounts were effectively closed off and existing ones migrated to paid GoCardless Bank Account Data pricing.
The community fallout was real. Firefly III's documentation flipped from "use Nordigen, it's free" to warnings that the integration may stop working. Actual Budget users saw broken syncs. Reddit's r/selfhosted and r/FireflyIII filled with "what do I use now?" threads. A whole generation of self-hosters had built on a free tier that was always a marketing budget, not a sustainable product.
The lesson, painfully learned: a free tier owned by a publicly-traded payments company is not infrastructure you can build a personal finance stack on.
The real barrier isn't the API — it's the certificate
When the Nordigen free tier died, the obvious-sounding fix was "just become an Account Information Service Provider myself and connect directly to banks." Anyone who looked into it hit the same wall: eIDAS certificates.
Under PSD2/Open Banking, to connect directly to a bank's API as a regulated Third Party Provider you need:
- A QWAC (Qualified Website Authentication Certificate) — proves your identity for the TLS connection.
- Often a QSeal certificate — for signing API requests.
- An AISP registration with your national regulator (the FCA in the UK, Finanstilsynet in Denmark, BaFin in Germany, etc.).
The certificates are the killer. They're issued by Qualified Trust Service Providers and they are not cheap. A QWAC from a recognised QTSP runs roughly €3,000–€15,000 per year depending on the issuer, validity period, and whether you need the eIDAS-qualified variant. On top of that you have regulator fees, audit/compliance overhead for some jurisdictions, and the operational pain of renewing and rotating certs.
For a fintech building a product, that's a cost of doing business. For someone who just wants their Beancount ledger to auto-import their checking account each night, it's absurd and prohibitive. This is the gap Nordigen's free tier filled, and it's the gap that's now open again.
This is why the answer for self-hosters is almost never "get your own certificate." It's "use a service that already has one, and exposes a clean API on top."
The realistic cert-free options for self-hosters in 2026
Here are the paths that actually work today for aggregating your own bank data into self-hosted tooling, ranked from most to least practical.
Option 1 — A cert-free aggregation API (the Nordigen replacement)
Several regulated providers expose an AIS (Account Information Service) API without requiring you to hold your own PSD2/eIDAS certificates. They're already licensed; you authenticate, consent per bank, and call normalised REST endpoints. This is functionally what Nordigen's free tier did, minus the "free" part — but at price points that make sense for personal use (a few euros per month rather than five-figure annual certs).
The workflow looks like this regardless of provider:
- Sign up and get an API key.
- Initiate a consent/redirect flow per bank (standard Open Banking SCA).
- Poll or receive callbacks; pull
/accounts,/accounts/{id}/balances,/accounts/{id}/transactions. - Map the normalised JSON into your tool's import format.
The big advantage over the free-tier era: these are paid products, which means they're maintained. When a bank changes its API (and they do, constantly), the provider absorbs the breakage instead of your cron job silently failing for two weeks.
Option 2 — Bank-provided CSV/MT940 export + scripted import
The unglamorous fallback that never breaks: most banks offer scheduled statement exports by email or download. You write a small importer (Firefly III has a generic CSV importer; Beancount has bean-extract; Actual Budget accepts OFX). Costs nothing, needs no third party, and is fully offline-capable.
The trade-off is that it's manual or semi-manual, format-fragile (every bank's CSV is subtly different), and gives you no normalisation across multiple banks.
Option 3 — Screen-scraping (use with caution)
Some tools still scrape online banking HTML. This is fragile, frequently breaks on bank UI changes, violates many banks' terms of service, and can get your account flagged. I mention it for completeness — for self-hosted personal finance in 2026 it's the option of last resort, not a strategy.
Why "self-host your own TPP connection" is usually wrong
You can technically run your own eIDAS-certified TPP infrastructure. A handful of very determined hobbyists do. But the cost/benefit is brutal: thousands of euros a year, regulator paperwork, cert renewal ops, and per-bank integration maintenance — all to avoid a €3/month aggregation API. Unless aggregating bank data is literally your job or your business, this is the wrong layer to self-host.
Comparison: self-hosted aggregation paths in 2026
| Approach | Cost | Cert-free? | Live data? | Multi-bank normalisation | Setup effort |
|---|---|---|---|---|---|
| Cert-free aggregation API | ~€3–15/mo | ✅ Yes | ✅ Yes (refreshed) | ✅ Yes, one schema | Low–medium |
| Bank CSV/MT940 + scripted import | Free | ✅ N/A | ⚠️ Periodic, manual-ish | ❌ No (per-bank formats) | Medium (per bank) |
| Self-hosted TPP (own eIDAS certs) | €3k–15k/yr + reg fees | ❌ No (you hold certs) | ✅ Yes | ✅ Yes (you build it) | Very high |
| Screen-scraping | Free | ✅ N/A | ⚠️ Fragile | ❌ No | Low, but brittle |
For the vast majority of Actual Budget / Firefly III / Beancount users, the first row is the sweet spot.
Wiring it into your self-hosted stack
The good news is that once you have a normalised JSON feed, plugging it into your tool is straightforward. A minimal pattern for Firefly III:
# 1. Fetch transactions from your aggregation API
curl -H "Authorization: Bearer $API_KEY" \
"https://api.example-openbanking.io/v1/accounts/$ACCOUNT_ID/transactions?from=2026-07-01" \
-o /tmp/txns.json
# 2. Transform → Firefly III's expected schema (jq one-liner sketch)
jq '[.transactions[] | {amount:.transaction.amount, description:.remittanceInformationUnstructured, date:.bookingDate, source:"Checking"}]' /tmp/txns.json > /tmp/firefly-import.json
# 3. POST to the Firefly III API
curl -H "Authorization: Bearer $FIREFLY_TOKEN" -H "Content-Type: application/json" \
-X POST "https://firefly.example.com/api/v1/transactions" \
-d @/tmp/firefly-import.json
For Beancount, point bean-extract or a custom importer at the same JSON. For Actual Budget, the same feed drives its sync endpoint. The point is that a single normalised API replaces a zoo of per-bank scrapers and CSV parsers.
End-to-end-encrypted options are worth specifically seeking out for self-hosters: a few providers let you hold the decryption keys client-side, so even their servers can't read your transaction data. For anyone self-hosting finance tooling precisely for privacy, that property matters more than saving a couple of euros.
Disclosure: I maintain open-banking.io, a roughly €3/month cert-free aggregation API with client-held encryption keys — built largely because the Nordigen free tier's disappearance left my own self-hosted setup stranded. I'm flagging it because it's directly on-topic, not as a sales pitch. The options and comparison above stand on their own; pick whichever fits your stack.
Choosing well
A few rules of thumb after living through the Nordigen shutdown:
- Prefer paid and boring over free and exciting. A €3/month service that's a real product outlasts a free tier that's a marketing line item.
- Check who actually maintains the bank integrations. Open Banking APIs break constantly; you want a provider that fixes breakages, not you.
- Decide on privacy up front. If you're self-hosting for privacy, don't then hand plaintext transactions to a third party — look for client-side encryption.
- Keep an export path. Whatever you choose, make sure you can get your data out (CSV/JSON export). Vendor lock-in on top of a self-hosted tool defeats the purpose.
The takeaway
The Nordigen free tier is gone and it isn't coming back. The honest options for self-hosted bank account aggregation in 2026 are: pay a small amount for a cert-free aggregation API that's actually maintained, fall back to scripted CSV/MT940 imports, or — for the truly determined and funded — take on eIDAS certificates yourself. For most Actual Budget, Firefly III, and Beancount users, the first of those is the clear winner: it restores exactly what the Nordigen free tier provided, with the bonus that being a paid product means it's treated like real infrastructure rather than a giveaway.
Your self-hosted finance stack deserves a data pipeline that won't evaporate on a corporate decision. Build accordingly.
If this was useful, I write about Open Banking, PSD2, and practical fintech for self-hosters and small businesses — questions welcome in the comments.
Top comments (0)