Why no bank sync

Nothing in Badlen synchronises with a bank, because nothing in it signs in to one. There is no aggregator, no screen-scraper and no open-banking connector, so no balance and no operation ever arrives on its own from an account you hold elsewhere.

The reason is structural, and it applies to every self-hosted project as much as to this one. Four facts explain it:

• a European bank’s interface answers only a registered entity. No piece of software reaches an account on its own, whatever it is willing to pay;
• no self-hosted open-source project holds that registration;
• the projects that do synchronise hand the compliance to you, and the free tier that made this practical in Europe stopped taking new sign-ups;
• and the one thing this product is built not to do is ask you to put your bank access in the hands of a company you have never heard of: your credentials with some providers, and in every case a copy of your accounts on their servers.

The one exception is a crypto wallet. It is declared by its chain and its public address, and the Sync button on that account’s Settings tab asks the chain what the address holds. It needs no credential of yours, because a public address is not one.

A regulated activity in the Union

Reading somebody’s payment accounts for them is a regulated activity in the European Union. Directive (EU) 2015/2366, better known as PSD2, calls it an account information service (Article 4(16)) and the one who performs it an account information service provider. Article 67 gives you the right to use such a service. It does not give a program the right to be one.

The regime is deliberately light for whoever does only that. Article 33(1) lifts most of the authorisation procedure, and the minimum capital requirement is among the things it lifts: a pure account information provider needs no capital at all. What survives is an insurance obligation (Article 5(3), professional indemnity insurance or a comparable guarantee), a file on governance, security and incident handling, and a registration with the national supervisor, which in France is the ACPR, under article L. 522-11-2 of the monetary and financial code.

Up to here, it is paperwork and an insurance premium. What makes it impossible is a technical requirement.

Regulation (EU) 2018/389, the technical standards that go with PSD2, says what a bank checks when something calls its interface. Article 34(1) requires a qualified eIDAS certificate: an electronic seal, or a certificate for website authentication. Article 34(2) says what has to be inside it:

the registration number … shall be the authorisation number of the payment service provider issuing card-based payment instruments, the account information service providers and payment initiation service providers … available in the public register of the home Member State pursuant to Article 14 of Directive (EU) 2015/2366

The certificate carries a registration number, and that number is looked up in a public register of registered entities. Without a number there is no certificate, and without a certificate no bank in the Union answers, however good the software asking.

The seal goes further than the live calls. Article 30(3) requires a bank to hand the technical documentation of its interface over “upon request by authorised payment initiation service providers, account information service providers … or payment service providers that have applied to their competent authorities for the relevant authorisation”. Even reading how the interface works is reserved to those who are registered or in the process of becoming so.

Banks say the same thing in their own words. OP Financial Group, publishing its PSD2 interface, tells a developer that going to production means applying “for an AISP/PISP license from a financial authority” and obtaining “valid QWAC and QSEAL certificates”; only the sandbox is open to anyone (op-developer.fi).

So the barrier is the registration itself. PSD2 nowhere says that free software may not read an account. It organises access around a named, registered, insured entity, and the technical standards turn that registration into a cryptographic object the bank verifies on every call.

The certificate a self-hosted program cannot hold

A certificate belongs to somebody. It names an entity, that entity is registered, insured and supervised continuously, and it answers to its supervisor for every access made through it.

Badlen is a program a thousand people install on a thousand machines. There is no entity behind those thousand instances, so there is no registration number, so there is no certificate, so there is no bank on the other end of the line. The way the software is distributed rules it out, whatever the quality of the code. Shipping a connector that works out of the box would mean shipping a secret belonging to one registered entity to every user, which is exactly what a certificate exists to prevent.

Putting a real entity in the middle is possible. It would mean one operator standing between every user and their bank, holding the registration, seeing the accesses, carrying the liability. That is a centralised service with a self-hosted front end, and it is the opposite of what installing the software on your own machine was for.

Three routes the other projects take

Every comparable project gives the same answer: no self-hosted open-source finance project holds an account information registration. They fall into three cases.

They do not connect at all. Ghostfolio lists no bank synchronisation; its data comes in by import and export, and its outside sources are quote providers.

You bring your own aggregator. This is what makes a project look like it synchronises when it does not. Firefly III routes its data importer through third-party providers rather than through a bank, and Actual Budget states the rule plainly: “This integration relies on you providing your own API credentials that you will need to get by signing up with the service provider”. The project ships the plumbing; the user goes and becomes the aggregator’s customer. The registration, the contract and the liability are the user’s.

They speak a client protocol, where one exists. GnuCash, through AqBanking, supports FinTS/HBCI in Germany, EBICS in Austria, Switzerland, Germany and France (“usually available for business customers”), and OFX Direct Connect in the United States. Firefly III reaches FinTS the same way. These protocols predate PSD2 and authenticate the user with their own bank credentials rather than a provider with a certificate, which is why they work at all. Germany is the real exception: since 1 August 2019 FinTS access requires a registered product, that registration is granted free of charge by the Deutsche Kreditwirtschaft and processed in ten to fifteen working days (fints.org). It registers the client software rather than granting a provider status, and it covers one protocol in one country.

And the bring-your-own-key route has narrowed

Firefly III and Actual both leaned on GoCardless Bank Account Data, the one European aggregator with a free tier a private individual could sign up to. It stopped taking newcomers. GoCardless says so on its own page: “New signups for Bank Account Data are currently disabled” (bankaccountdata.gocardless.com). Firefly III’s documentation says “GoCardless is sunsetting this free service and registration is unfortunately closed”, and Actual’s provider list carries GoCardless marked “not accepting new accounts”.

What is left asks for a company. Enable Banking, the European aggregator those projects now point at, activates a production application “once you have signed a contract with Enable Banking and completed the KYB process for your company”, and prices by volume with a monthly minimum (enablebanking.com). A restricted mode exists for linking your own accounts only, and it is built for a personal tool or a prototype rather than for a product thousands of people install.

For the people Badlen is written for, households rather than businesses, that route is now closed.

Why Badlen chose differently

Everything above would still leave one option: ship the fields, let whoever can sign up with an aggregator paste their credentials in. Firefly III and Actual Budget do exactly that, and they are right to. They sell you control of your budget, and a detour through an aggregator serves that.

Badlen sells something else: that what you record stays on the machine you installed it on. A screen asking for an aggregator’s key would ask you to authorise a company whose name you learned on that screen to reach your bank for you, read every account and pass the contents along. Every figure in this product would then exist twice: once on your server, and once in a database you have no claim on.

This is a deliberate choice. Shipping a connector would mean giving up what this product is for, so it is on no list of work waiting to be done. If that ever changes, it will change in a legal text, and this page will say so.

Sources

Every claim above was read in the source named beside it. The primary texts:

• Directive (EU) 2015/2366 (PSD2), Articles 4(16), 5(3), 14, 33 and 67
• Commission Delegated Regulation (EU) 2018/389, Articles 30 and 34
• Code monétaire et financier, article L. 522-11-2, registration with the ACPR

The projects and the providers, each in its own documentation: Ghostfolio, Firefly III, Actual Budget, GnuCash, FinTS, GoCardless, Enable Banking, OP Financial Group.