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.
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.
- accounts:
- 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
A provider may specify whether data one-off or periodic and how long the permission remains valid. this can't be more than 90 days.
The time an AISP has access to the account is 90 days, unless the AISP indicates that time may be shorter. Many banks seem to be based on the maximum term.
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).
| Book date | 16-7-2019 |
| 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 |
| Code | ID |
| 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 debits and credits and you can print these out. For your current account you can look back at the current year and the 9 years before that." But, in the API documentation, under the heading Country specific information, it says that ING has 2 years of Transaction history available after SCA. We reported this to them, it is of course important that the documentation is in order.
What do we do with Mollie and Buckaroo?
How should we deal with account numbers from intermediaries such as Mollie and Buckaroo? For example, the political party D66 uses a Buckeroo account. In the comments field of a transaction, it says 'Politieke Partij Democraten 66: Contributie 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.