Mkey ... In case anyone else in Sweden finds this thread, the unnamed PSD2
proxy only features integration with a handful of Swedish banks:
```
$ cat banks.json | jq -r '.[] | select(.countries | index("SE")) | .id'
AIRWALLEX_AIPTAU32
AMERICAN_EXPRESS_AESUGB21
N26_NTSBDEB1
PAYSAFE_NETEGB21
PAYPAL_PPLXLULL
PLEO_PLEODK00
PAYSAFE_SKRLGB2L
STRIPE_STPUIE21
WISE_TRWIGB22
```
On Fri, Apr 28, 2023 at 2:37 PM Cristian Klein <cristikl...@gmail.com>
wrote:
> Thanks Anselm and Frank! You confirmed my assessment that PSD2 cannot be
> used directly by end-users.
>
> @Anselm: Could you share who is the "API proxy for interested developers /
> end users" provider? (Perhaps as a private email, if that is sensitive.)
>
> Why would I trust a third-party to proxy my banking info? I'm split. On
> one hand, I really shouldn't. On the other hand, I read somewhere that PSD2
> only allows TPPs to store banking information for as long as needed for the
> intended purpose of the customer. Hence, it almost feels like I have a duty
> towards my fellow citizens to test the privacy and security of PSD2. 😀
>
> Best,
> Cristian
>
> On Thu, Apr 27, 2023 at 5:50 PM Anselm Martin Hoffmeister <
> ans...@hoffmeister-online.de> wrote:
>
>> Hallo Cristian,
>>
>> PSD2 does not help end users (account holders) to obtain their data from
>> the bank directly.
>>
>> This is related to the political intention behind mandating the PSD-API
>> for (all?) EU banks.
>>
>> There are certain agents in the financial market that profit from access
>> to customer data (and aggregation thereof). Think of fintech lender
>> companies that can check the credit worthiness of an applicant by
>> accessing their spending history from their main account via
>> standardized means. Those are the ones that profit from the API.
>>
>> For private customers there is **absolutely no way** to access a bank
>> API directly. This is only open to (somewhat) trustworthy parties that
>> prove their proficiency in banking language, have some kind of
>> insurance, and put money into that process way above any regular monthly
>> salary... and are a registered _company_.
>>
>> We had a discussion on aqbanking list about one certain fintech company
>> that plays kind of API proxy for interested developers / end users, at
>> the moment even for free. This may seem a wonderful prospect, accessing
>> all the banks' transaction data even from those that do not regularly
>> offer their customers any digital data, let alone structured information.
>>
>> The consensus was - iirc - that developing an aqbanking interface to
>> that service helps mostly _their_ business model, not necessarily so
>> much the users, and everyone would pay with their banking data.
>> Depending on what that is worth to you, you might look into it - I did
>> not any further.
>>
>> In case your Nordea account offers CSVs, you might better work with
>> those, in a half-automated fashion?
>>
>> Lucky me has a german banking market that has a (rather national) data
>> access standard, FinTS, that mostly works quite well - nearly all
>> established checking account banks offer it. The newer fintechs mostly
>> do not have that access though - one more reason to not bank with them,
>> I imagine. Sorry this does not help with the swedish market.
>>
>> Best regards
>>
>> Anselm
>>
>> Am 26.04.2023 um 23:01 schrieb Cristian Klein:
>> > Hello,
>> >
>> > TL;DR: Given infinite development bandwidth, can one even dream of using
>> > PSD2 for Online Banking with GnuCash?
>> >
>> > I wanted to improve visibility into my spendings (what do you know, it's
>> > 2023 😀) and wanted to try using GnuCash again ... after a 10-year
>> break.
>> >
>> > However, my life situation changed, and I no longer have the time (nor
>> > patience) to manually enter all transactions into GnuCash. Therefore,
>> > hearing about all the hype around PSD2, I thought maybe GnuCash already
>> > supports pulling all transactions from my bank (Nordea, Sweden, EU).
>> >
>> > Why don't I just hack a PSD2 backend for AqBanking?
>> >
>> > So ... I read up on PSD2 and here is what I understood:
>> >
>> > - It introduces a heck of a lot of acronyms.
>> > - It essentially mandates an open API for access to my transaction
>> > information.
>> > - TPP = "Third Party Provider", i.e., the entity who -- upon my
>> consent
>> > -- gets access to my transaction info.
>> > - XS2A = "Access to Account" is an API to essentially retrieve
>> > transaction information.
>> > - TPP needs to onboard at two levels:
>> > - First, the TPP needs to get some kind of certificate ("QSealC
>> eIDAS
>> > Public certificate" -- in case anyone Googles this message) from
>> the
>> > National Financial Authority, e.g., BaFin in Germany,
>> > Finansinspektionen in
>> > Sweden, etc.
>> > - Second, the TPP needs to get onboarded with each bank.
>> >
>> > I learned these by reading the following documents:
>> >
>> > -
>> >
>> https://medium.com/@mpn123/building-an-open-banking-access-to-account-xs2a-api-as-a-bank-or-aspsp-479f26b91a43
>> > -
>> >
>> https://www.openbankingeurope.eu/media/1176/preta-obe-mg-001-002-psd2-xs2a-tpp-user-management-guide.pdf
>> > -https://developer.nordeaopenbanking.com/pitching-form/compliance
>> >
>> > Does this essentially mean that PSD2 and XS2A is only usable for
>> accounting
>> > software delivered as SaaS and useless for accounting software
>> delivered as
>> > desktop applications like GnuCash?
>> >
>> > Any insight is appreciated.
>> >
>> > Best,
>> >
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
>
> --
> Cristian Klein
>
--
Cristian Klein
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
