Fwd: Re: [Aqbanking-user] Request for support for a GSOC project to improve the quality of financial applications

Ralf Habacker ralf.habacker at freenet.de
Mon May 4 07:42:01 BST 2020


Hi all,

During the presentation of the GSOC project I received the following 
feedback from the aqbanking maintainer, which could help to adapt and/or 
extend the GSOC project.

Regards
  Ralf

-------- Weitergeleitete Nachricht --------
Betreff: Re: [Aqbanking-user] Request for support for a GSOC project to 
improve the quality of financial applications
Datum: Wed, 29 Apr 2020 17:01:59 +0200
Von: Martin Preuss via Aqbanking-user <aqbanking-user at mailman.aqbanking.de>
Antwort an: Martin Preuss <martin at aqbanking.de>
An: aqbanking-user at mailman.aqbanking.de

Hi,

Am 29.04.20 um 10:22 schrieb Ralf Habacker via Aqbanking-user:
[...]
> aqbanking uses bank data in its libraries and tools (https://github.com/aqbanking/aqbanking/tree/master/src/libs/plugins/bankinfo/generic), which are currently outdated.
[...]

Correct, unfortunately...

[...]
> ● Replace the currently used text bankdata files with an SQLite database with support for validity period checking. The database should be generated and updated from the bank data retrieved from ​Deutsche Bundesbank​.
[...]

I'm against pulling sqlite as a default dependency to AqBanking for the 
sole purpose of providing access to quite simple structured data like 
BLZ<->Bank name, especially with a finate and relatively low amount of 
data (normally the number of German banks doesn't change dramatically, 
although it might during the current corona crisis...).

However, I also see the problem of having old data in AqBanking. I think 
updating of the bank data should be decoupled from AqBanking updates.

That's why I was contemplating providing some service like libofxhome 
where you can query a bank data provider. Then you would only need to 
update the data in one place (on the server).

In such a case your database would be an excelellent data source, and 
that bank data service could use sqlite or whatever you choose as a 
storage backend.

[...]
> ● Make changes in the library to use the generated database as the bankdata file in place of the text files.
[...]
> ● Add support for additional countries to the checking library. The bankdata files also need to be added corresponding to these countries.
[...]

That's what AqBanking already provides. However, I just removed the bank 
data for Swiss, US and Austrian banks some time ago since nobody seemed 
to use it and keeping those files updated is quite a bit of work when 
supporting multiple countries). But for German banks that code is still 
in use, and it could be used for other countries again (the code itself 
wasn't changed).

We could of course add an optional plugin to AqBanking which uses your 
databank approach, but I don't see the need for a completely new API, 
since at least for AqBanking there already is one (which can of course 
always be adapted as need arises).

 From my point of view it would be best if we could use your database as 
a stand-in for e.g. ktoblzcheck (which we formerly used to check bank 
German account numbers); as a separate library which can be used by 
applications or other libraries (like AqBanking).

Looking forward to see the results/work-in-progress (will there be a git 
repository for it?)


Regards
Martin


-- 
"Things are only impossible until they're not"
_______________________________________________
Aqbanking-user mailing list
Aqbanking-user at mailman.aqbanking.de
https://mailman.aqbanking.de/listinfo/aqbanking-user


More information about the Kde-finance-apps mailing list