Response to public hearing on the Consultation paper on the amendment of the RTS on SCA&CSC under PSD2
Go back
However, we have experienced widely over Europe, deviations in interpretation of the frequency on access of account information and propose to adjust additionally Article 36 with a refinement on the rules of SCA exemption to further standardize the implementation. (Reference: RTS on SCA and CSC – Article 36-5(b) Data Exchanges)
As highlighted during the Public consultation, a further refinement on the rules around SCA exemption could help better standardize the implementation of the logic on the ASPSP side
Referring to Article 36 "Data Exchanges" under which a provision is made to access PSU Payment account data not more than 4 times in a 24 hour period -
Consider the following scenarios where we see some anomalies in the way the ASPSPs have interpreted the provision regarding the 4 times free access per day when an active recurring consent from the PSU is presented to the ASPSP by the AISP
PSU-not-present scenario:
- Expectation from AISP perspective
o The maximum frequency of 4 TPP accesses per day is allowed with the access counter set per TPP-PSU-IBAN-Request Type combination
o Explanation:
This implies that the AISP is allowed to access PSU account information (incl. balances and transactions) up to 4 times per day (for each account that he holds with the said ASPSP).
This further implies that if the PSU were to hold say 2 accounts (say, Account A and Account B) with an ASPSP, then the AISP would be able to access Balance and transaction information for Account A up to 4 times per day and additionally access balance and transaction information for Account B up to 4 times per day
Concretely, we expect the following to be possible for an AISP, under the exemption rules
call get Balances up to 4 times in a 24 hour period for Account A
call get Transactions up to 4 times in a 24 hour period for Account A
call get Balances up to 4 times in a 24 hour period for Account B
call get Transactions up to 4 times in a 24 hour period for Account B
- Observed anomalous behaviour from ASPSPs
o TPP access is counted per TPP-PSU-Consent regardless of request type (get Balances / get Transactions) and regardless of the number of accounts held by the PSU at the ASPSP.
This means that for a given recurring consent (encompassing multiple accounts held by the PSU at the said ASPSP), each access (independent of request type, be it get balances or get transactions), is counted towards the final value of 4 (times in a 24 hour period).
Similarly, request for account information for each account (independent of the number of accounts held by the PSU at the ASPSP), is counted towards the final value of 4 (times in a 24 hour period).
In the extreme case, this results in the following anomalous behaviour
Counter Value
+1 ( = 1): get Account Balances (Account A)
+1 ( = 2): get Account Transactions (Account A)
+1 ( = 3): get Account Balances (Account B)
+1 ( = 4): get Account Transactions (Account B)
o Ideal response of the ASPSP should have been, a separate access counter per request type and per account, allowing for a total of 16 accesses for the 2 different request types (namely, get Balances and get Transactions) over the 2 Accounts (Account A and Account B) held by the PSU, as illustrated below:
Separate Counter for get Account Balances for Account A
• Counter Value 1: get Account Balances (Account A)
• Counter Value 2: get Account Balances (Account A)
• Counter Value 3: get Account Balances (Account A)
• Counter Value 4: get Account Balances (Account A)
Separate Counter for get Account Transactions for Account A
• Counter Value 1: get Account Transactions (Account A)
• Counter Value 2: get Account Transactions (Account A)
• Counter Value 3: get Account Transactions (Account A)
• Counter Value 4: get Account Transactions (Account A)
Separate Counter for get Account Balances for Account B
• Counter Value 1: get Account Balances (Account B)
• Counter Value 2: get Account Balances (Account B)
• Counter Value 3: get Account Balances (Account B)
• Counter Value 4: get Account Balances (Account B)
Separate Counter for get Account Transactions for Account B
• Counter Value 1: get Account Transactions (Account B)
• Counter Value 2: get Account Transactions (Account B)
• Counter Value 3: get Account Transactions (Account B)
• Counter Value 4: get Account Transactions (Account B)
Following this observed behavior, we would like to make a proposal for Amendment of Article 36.5(b) of the RTS for SCA and CSC
Account information service providers shall be able to access information from designated payment accounts and associated payment transactions held by account servicing payment service providers for the purposes of performing the account information service in either of the following circumstances:
(a) whenever the payment service user is actively requesting such information;
(b) where the payment service user does not actively request such information, no more than four times in a 24 hour period, unless a higher frequency is agreed between the account information service provider and the account servicing payment service provider, with the payment service user’s consent.
The abovesaid counter (four times in a 24 hour period) is to be applied as separate, distinct and independent counters, for each account information request type (for example, account balance request type, account transaction list request type) and for each payment account held by the payment service user for which the payment service user has provided explicit consent to the Account information service provider.
To mitigate the risk that the PSU may refuse to give consent for a longer duration (180 days instead of 90 days), ensure that the consent revocation functionality is enforced to be implemented in a uniform and standard way and advertised well in the market. Some widely used implementation specifications, like the Berlin Group NextGenPSD2 XS2A Framework specifications, already do make a provision for a revocation API to delete active consents. The ASPSPs should be encouraged to adopt these standards in to their own solutions.
Our expectation is that the revocation functionality is made available to the PSU, both through the AISP interfaces and through the ASPSP’s own user interface towards the PSU.
Our observation is that there is a wide variation on both fronts, namely, on the provision of a revocation API to the AISP by the ASPSP and in the provision of the revocation GUI on the ASPSP’s own portal.
Our recommendation therefore is to put an additional amendment to the RTS, enforcing the ASPSPs to provide a consent revocation function to the PSUs (both, through an API exposed to the AISPs and through the ASPSP’s own user interfaces).
Additionally, if the PSU were to revoke the consent directly at the ASPSP (for instance, on the ASPSP’s online portal), that the ASPSP provides a notification to inform the TPP about the revocation.
Q1. Do you have any comments on the proposal to introduce a new mandatory exemption for the case when the information is accessed through an AISP and the proposed amendments to Article 10 exemption?
We, at Worldline, fully support this initiative to make the exemption under Article 10 mandatory for the ASPSPs.However, we have experienced widely over Europe, deviations in interpretation of the frequency on access of account information and propose to adjust additionally Article 36 with a refinement on the rules of SCA exemption to further standardize the implementation. (Reference: RTS on SCA and CSC – Article 36-5(b) Data Exchanges)
As highlighted during the Public consultation, a further refinement on the rules around SCA exemption could help better standardize the implementation of the logic on the ASPSP side
Referring to Article 36 "Data Exchanges" under which a provision is made to access PSU Payment account data not more than 4 times in a 24 hour period -
Consider the following scenarios where we see some anomalies in the way the ASPSPs have interpreted the provision regarding the 4 times free access per day when an active recurring consent from the PSU is presented to the ASPSP by the AISP
PSU-not-present scenario:
- Expectation from AISP perspective
o The maximum frequency of 4 TPP accesses per day is allowed with the access counter set per TPP-PSU-IBAN-Request Type combination
o Explanation:
This implies that the AISP is allowed to access PSU account information (incl. balances and transactions) up to 4 times per day (for each account that he holds with the said ASPSP).
This further implies that if the PSU were to hold say 2 accounts (say, Account A and Account B) with an ASPSP, then the AISP would be able to access Balance and transaction information for Account A up to 4 times per day and additionally access balance and transaction information for Account B up to 4 times per day
Concretely, we expect the following to be possible for an AISP, under the exemption rules
call get Balances up to 4 times in a 24 hour period for Account A
call get Transactions up to 4 times in a 24 hour period for Account A
call get Balances up to 4 times in a 24 hour period for Account B
call get Transactions up to 4 times in a 24 hour period for Account B
- Observed anomalous behaviour from ASPSPs
o TPP access is counted per TPP-PSU-Consent regardless of request type (get Balances / get Transactions) and regardless of the number of accounts held by the PSU at the ASPSP.
This means that for a given recurring consent (encompassing multiple accounts held by the PSU at the said ASPSP), each access (independent of request type, be it get balances or get transactions), is counted towards the final value of 4 (times in a 24 hour period).
Similarly, request for account information for each account (independent of the number of accounts held by the PSU at the ASPSP), is counted towards the final value of 4 (times in a 24 hour period).
In the extreme case, this results in the following anomalous behaviour
Counter Value
+1 ( = 1): get Account Balances (Account A)
+1 ( = 2): get Account Transactions (Account A)
+1 ( = 3): get Account Balances (Account B)
+1 ( = 4): get Account Transactions (Account B)
o Ideal response of the ASPSP should have been, a separate access counter per request type and per account, allowing for a total of 16 accesses for the 2 different request types (namely, get Balances and get Transactions) over the 2 Accounts (Account A and Account B) held by the PSU, as illustrated below:
Separate Counter for get Account Balances for Account A
• Counter Value 1: get Account Balances (Account A)
• Counter Value 2: get Account Balances (Account A)
• Counter Value 3: get Account Balances (Account A)
• Counter Value 4: get Account Balances (Account A)
Separate Counter for get Account Transactions for Account A
• Counter Value 1: get Account Transactions (Account A)
• Counter Value 2: get Account Transactions (Account A)
• Counter Value 3: get Account Transactions (Account A)
• Counter Value 4: get Account Transactions (Account A)
Separate Counter for get Account Balances for Account B
• Counter Value 1: get Account Balances (Account B)
• Counter Value 2: get Account Balances (Account B)
• Counter Value 3: get Account Balances (Account B)
• Counter Value 4: get Account Balances (Account B)
Separate Counter for get Account Transactions for Account B
• Counter Value 1: get Account Transactions (Account B)
• Counter Value 2: get Account Transactions (Account B)
• Counter Value 3: get Account Transactions (Account B)
• Counter Value 4: get Account Transactions (Account B)
Following this observed behavior, we would like to make a proposal for Amendment of Article 36.5(b) of the RTS for SCA and CSC
Account information service providers shall be able to access information from designated payment accounts and associated payment transactions held by account servicing payment service providers for the purposes of performing the account information service in either of the following circumstances:
(a) whenever the payment service user is actively requesting such information;
(b) where the payment service user does not actively request such information, no more than four times in a 24 hour period, unless a higher frequency is agreed between the account information service provider and the account servicing payment service provider, with the payment service user’s consent.
The abovesaid counter (four times in a 24 hour period) is to be applied as separate, distinct and independent counters, for each account information request type (for example, account balance request type, account transaction list request type) and for each payment account held by the payment service user for which the payment service user has provided explicit consent to the Account information service provider.
Q2. Do you have any comments on the proposal to extend the timeline for the renewal of SCA to 180-days?
We, at Worldline, fully support this initiative to extend the timeline for the renewal of SCA to 180 days since it would definitely improve the customer journey. However, we would additionally like to raise the point that we have experienced fragmented solutions in the market on the revocation of consent which – with a longer duration – would need to be standardized.To mitigate the risk that the PSU may refuse to give consent for a longer duration (180 days instead of 90 days), ensure that the consent revocation functionality is enforced to be implemented in a uniform and standard way and advertised well in the market. Some widely used implementation specifications, like the Berlin Group NextGenPSD2 XS2A Framework specifications, already do make a provision for a revocation API to delete active consents. The ASPSPs should be encouraged to adopt these standards in to their own solutions.
Our expectation is that the revocation functionality is made available to the PSU, both through the AISP interfaces and through the ASPSP’s own user interface towards the PSU.
Our observation is that there is a wide variation on both fronts, namely, on the provision of a revocation API to the AISP by the ASPSP and in the provision of the revocation GUI on the ASPSP’s own portal.
Our recommendation therefore is to put an additional amendment to the RTS, enforcing the ASPSPs to provide a consent revocation function to the PSUs (both, through an API exposed to the AISPs and through the ASPSP’s own user interfaces).
Additionally, if the PSU were to revoke the consent directly at the ASPSP (for instance, on the ASPSP’s online portal), that the ASPSP provides a notification to inform the TPP about the revocation.