The Don't-PSD2-me-Register requires data filtering. In order to know how this needs to be developed technically, we want to know better how the communication between account information service provider and bank takes place. In this article we will elaborate on how the PSD2 will be technically developed. To do so, we need to enter the code. For this we use the public API documentation that banks make available. We only focus on the AISPs, the account information services.
Would you like to help us with the technical side of the Don't-PSD2-me register? Are you at home in APi's and code? Then send an email to mailto:firstname.lastname@example.org.
Bank and AISP talk via an API
In order to better know which information of a bank is shared with an AISP, we have looked at several APIs of banks watched. The AISP and the bank communicate via an API. The API defines what a request looks like, and what information the bank sends back. There seems to be not to be an industry standard used by all banks. Every API will be different, but the functionality will match because it is described in the PSD2 and the RTS.
Hardly any restrictions possible within API
As soon as a customer wants to use an account information service, he will authorise an AISP and confirm this to the bank (see also the article PSD2 and privacy). Via the API, the AISP and the bank talk to each other. What the API looks like determines which information is transferred. For example, an AISP can make the following request. We have a piece of code converted to more readable text. The content of the request is shown below.
- iban:...an IBAN,
- balances:iban:...an IBAN,
- transactions:iban:...an IBAN,
- recurringIndicator:true, (may also be false)
- validUntil:2019-05-30, (there is no default value, but there is a maximum of 90 days)
- frequencyPerDay:4 (number of times data can be retrieved)
AISP can request data once or periodically and for a maximum of 90 days
Which account details be shared?
In their information, banks ambiguous which data can be retrieved.
To get a better understanding of what this means and how detailed data is, we have made a normal bank payment to Privacy First. Then we downloaded the transaction to a .csv file and MT940 file. We assume that no other data will be shared. The account statements show the following information:
What does a donor see on the statement of account
What does Privacy First see on the account statement?
(In bold the elements that can also be received via the API).
|Account number||NL17TRIO1234567890 (IBAN adapted)|
|Amount||3 (debit and credit can be derived from the +/+ or -/-)|
|Debit / Credit||Debit|
|Name contra account||Foundation Privacy First through Mollie|
|Counter account||RABONL2U NL70RABO0115600000|
|Description||Order number M1661161M12LSZDX / Transaction number 0020002514859230 / 16-07-19 11:28 / anonymous privacyfirst.com|
When we compare the normal bank statements with the API, it looks like the API shares less data than you can now see in the transaction. Some fields can be deduced from the transaction, such as debit or credit and a type such as a transfer or direct debit. It is not clear if the description is shared as well.
What about location data?
Location data can be derived from the location of an account holder, such as an (online) shop, catering establishment or pin device. These location data deserve further investigation because it is questionable whether they can be deduced from the account statements when the description is not given.
ING shares differently than expected
The ING indicates that in the mijnING environment "you always have an up-to-date overview of your credits and can print them out. For your payment account you can look back at the current year and the 9 years before that". However, under the heading Country specific information in the API documentation it says that ING can receive 2 years of Transaction history available after SCA. How about this? This will have to be investigated further.
What do we do with Mollie and Buckaroo?
How should we deal with account numbers of intermediaries like Mollie and Buckaroo? For example, the political party D66 uses a Buckeroo account. For a transaction, the remarks field includes 'Political Party Democrats 66: Contribution D66, February 2020', but the contra account of Buckaroo. In this case, inclusion in the register on the basis of the contra account would not be correct because Buckeroo is also used by other organisations. For reasons of purity, we choose not to include the Buckaroo account at this time. However, this means that information about the membership remains in the description field.