Add open-banking.io as a native data provider

[nicolaj-hartmann]

Reference issues and PRs

Addresses the recurring request for a GoCardless/Nordigen automated-import alternative (e.g. discussion firefly-iii/firefly-iii#11875). Matching docs PR: firefly-iii/docs#247.

Note on process: I see the template asks to talk to you first before adding a new third-party provider / for PRs over 25 lines — apologies for jumping ahead. Please treat this as a complete, tested starting point; I'm happy to move to a discussion, hand it over, or whatever you prefer (details at the bottom).

What does this implement/fix? Explain your changes.

Adds open-banking.io as a native Data Importer provider (flow key obio), alongside GoCardless, Enable Banking, SimpleFIN and Lunch Flow.

open-banking.io is an affordable, certificate-free open-banking API covering the EEA and the UK (2,600+ banks). It's a fit for the seat GoCardless is vacating ("shifting away from their Bank Account Data products") — self-hosters who can no longer open new GoCardless accounts can point Firefly III at open-banking.io instead.

How it works

• Credential-based, no OAuth redirect. The user exports a credentials.json bundle (API key + a private key) and pastes it on the authenticate screen. Modelled on the Lunch Flow provider (conversion_before_mapping), so it reuses the generic account-selection + date-range configure steps.
• Zero-knowledge. API responses are encrypted envelopes; sensitive fields (amounts, IBANs, names, remittance) never travel in cleartext. They're decrypted locally with the user's private key (ECDH P-256 → HKDF-SHA256 → AES-256-GCM). The decryptor (App\Services\OpenBankingIo\Crypto\Envelope) is ported in-tree from the official open-banking.io PHP client, so there is no new Composer runtime dependency (uses ext-openssl, already required).
• Mapping. external_id de-duplication; creditDebitIndicator sets deposit/withdrawal; a counterparty IBAN matching one of the user's other asset accounts becomes a transfer (guarded against source == destination). The statement is paged (offset loop + safety cap), and a record that fails to decrypt or has an unusable direction/amount is skipped with a warning rather than aborting the import.

Surface: new module app/Services/OpenBankingIo/**, new config/obio.php, registered in config/importer.php, and wired into the flow like the existing providers (ConversionRoutineFactory, ImportJobRepository, ImportServiceAccount, CollectsAccounts, MergesAccountLists, Configuration, the authenticate/service/validation/upload/configure/map controllers, the flow enum in resources/schemas/v3.json, and the en language strings).

Tests: crypto wire-format interop (EnvelopeTest); the real enc fixtures through the actual Request classes with mocked HTTP, covering decryption, pagination and skip-bad-record (RequestDecryptionTest); the transfer/self-transfer guard (GenerateTransactionsTest); and the fake_data demo flow (DemoModeTest). PHPStan (.ci/phpstan.neon) and php-cs-fixer are clean; phpmd is advisory-clean. Verified end-to-end against a live staging environment: a real 262-transaction account imported into a real Firefly III, pagination exercised, external_id de-dup confirmed on re-run.

AI usage disclosure

I used AI assistance for:

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

This PR was written with heavy AI assistance (Claude), directed and reviewed by me. It follows the existing Lunch Flow provider's structure, ships with the tests described above, and I verified it end-to-end against a live open-banking.io staging environment before submitting.

Any other comments?

Disclosure: I maintain open-banking.io. I'm happy to do this however works best for you — treat it purely as a reviewable starting point, hand it over entirely, or move the conversation to a discussion/email. I can provide a staging account + a test credentials.json with a connected bank so you can review against real (decrypted) data end to end.

@JC5

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[JC5]

Hi there!

This is an automated reply. Share and enjoy

You triggered an automated reply, because it seems you removed or changed the AI assistance disclosure from the PR template. Without a valid disclosure, your PR cannot be processed.

Even if you did not use AI, this disclosure must be present. Please reply to your PR and explain your use of AI in any or all of the following areas:

1. Code generation (e.g., when writing an implementation or fixing a bug)
2. Test/benchmark generation
3. Documentation (including examples)
4. Research and understanding

There cannot be interaction with your PR without this disclosure.

If the disclosure is present but the bot did not pick up on it, please accept my apologies for the intrusion. Contrary to other bots, this one is just a simple `bash` script and it may be wrong.

[nicolaj-hartmann]

Thanks — and apologies: I replaced the template with my own description and dropped the AI usage disclosure, which tripped the bot. I've restored it in the PR description with all four boxes checked, honestly:

• Code generation — yes (Claude, directed and reviewed by me).
• Test/benchmark generation — yes.
• Documentation — yes (this PR + the docs PR Document the open-banking.io data provider docs#247).
• Research and understanding — yes (codebase + the open-banking.io SDK).

I also noticed the template asks contributors to talk to you first before adding a new third-party provider / for PRs over 25 lines — sorry for jumping ahead. Please treat this purely as a complete, tested starting point. I maintain open-banking.io and I'm glad to do this however you prefer: review it, hand it over, or move to a discussion/email — and I can give you a staging account + a test credentials.json to review against real decrypted data. @JC5

[JC5]

https://docs.firefly-iii.org/explanation/contributing/#no-ai-contributions