BT-REQ-3972 PSD3 Impacts v6(without crop marks) RL - Flipbook - Page 17
17
HL | PSD3 Impacts
9. TPP dashboard
(PSR Art 43)
Overview
ASPSPs will need to provide a customer
facing dashboard that enables PSUs to see
and manage the consents they have granted
to TPPs (and to cancel them).
ASPSPs and TPPs will need to communicate
to ensure the data on the dashboard is
accurate and live.
This is not subject to the corporate optout.
What is changing?
The proposed PSR imposes a new obligation on
ASPSPs to provide a “dashboard” as part of their
online service to enable PSUs to:
see and manage the consents they have granted
to TPPs to access their accounts (i.e., who, what,
why, when); and
allow cancellation and re-establishment of those
consents in the ASPSP domain.
ASPSPs and TPPs will be required to co-operate to
ensure the information on the dashboard is live
and to communicate changes in permission/new
permissions to each other.
Specifically, TPPs will need to disclose the purpose
of permissions and the duration of the consent.
The EP Text proposes:
minor changes to reflect the scope of the
ASPSP’s ability to control the TPP/PSU
relationship (for example, a dashboard can’t
enable a PSU to re-establish consent once
cancelled);
to allow PSUs to opt out of data sharing with
third parties generally (for both present and
future access requests);
that the EBA introduces guidelines on the data
that the dashboard will cover; and
to impose obligations on TPPs to stop using,
and to withdraw and erase all data following
cancellation by the customer.
Interestingly, the Council Text also plans ahead
for the eventual enactment of the draft FIDA,
requiring TPP dashboards to be consistent with
FIDA equivalents, and to allow PSUs to manage
data permissions pursuant to both the PSR and
FIDA through a single dashboard.
What is the impact?
Unless a market solution emerges, ASPSPs could
be put to significant cost to provide a solution that
enables the necessary communications between
themselves and TPPs to ensure that PSUs can
cancel the permissions they have given to TPPs
and that details of ongoing consents remain
accurate and current.
Further clarity is needed around scope – for
example, it would be logical for the dashboard to
be limited to permissions granting ongoing access
rather than onetime, limited access to initiate a
payment.
ASPSPs in the corporate space will need to
consider the effect on their current TPP solutions.
Such providers were not spared the expense of
having to permit TPP access to corporate bank
accounts under PSD2, and a new requirement to
provide a dashboard (and potentially move to a
dedicated customer interface) adds further cost
and operational complexity in a sector of the
industry in which TPPs have shown very little
(if any) interest to date. Such providers might
consider themselves better off applying to be
exempted from the requirement to provide access
(depending on the extent to which they might be
required to permit similar access under FIDA).
