Enable Banking: configure the app credentials once (env vars) or save them per user, instead of re-entering them for every bank

I self-host MoneyMatter and link several banks through Enable Banking. Before sending any code I'd like the maintainer's opinion on how to approach this, since it touches how provider credentials are stored.

The problem

The Enable Banking connect form asks for the application ID and the RSA private key every time, for every bank connection. The country and bank list calls ask for them as well.

Those two values are credentials of my Enable Banking application, not of a bank: they are identical for every bank I link and for every user of the instance. Today:

I paste the same multi-line PEM key once per bank.
The key is stored encrypted on every connection row, so there are N copies, and rotating it means calling refreshCredentials once per connection.
On a household instance, each person has to hold and paste the key.

The other providers don't have this shape: Monobank, LunchFlow and SimpleFIN take a per-user token once per connection, and Walutomat's key pair belongs to the account. This is specific to Enable Banking, where one application credential serves many connections.

Two possible solutions (they can coexist)

Suggested precedence: environment variables, then saved credentials, then prompting the user.

Instance-level configuration through environment variables, for example ENABLE_BANKING_APP_ID and ENABLE_BANKING_PRIVATE_KEY, plus a _PATH variant for the key, because a multi-line PEM is awkward in an env var and a file works with Docker secrets. When set, the connect form skips both fields and the backend uses them for the country list, the bank list and the connection. ENABLE_BANKING_REDIRECT_URL is already read from the environment, so this extends an existing pattern.
Saved credentials when nothing is configured. After a user enters a valid app ID and key once (validated with the existing test call), store them encrypted per user with the same encryptCredentials, and pre-fill or skip the fields on the next connection. Settings would let the user replace or delete them, and replacing them would update their existing connections, so a rotation is one action. The same mechanism could serve any other provider that asks for reusable credentials.

Questions for the maintainer

Is either of these direction acceptable for the project, or would you rather keep the credentials per connection as they are?
If saved credentials: a separate per-user table for provider-level credentials, or keep them on BankDataProviderConnections and copy from the user's most recent valid connection?
For the env-var variant: is single-tenant (one set of app credentials per instance) fine for self-host only, or should it also be considered for the hosted version?

I'm willing to implement either of them, or both, in whichever shape you prefer. I'd rather agree on the direction first, as CONTRIBUTING.md suggests for non-trivial changes.