Managing Consent under PSD2

Ensuring seamless consent management is a cornerstone of PSD2 implementation. Here, Oliver Dlugosch, CEO of ndgit, explains how dedicated APIs can help banks reduce complexity and make processes smoother.

PSD2 is driving a myriad of new service opportunities between banks and third-party service providers (TPPs). But before they can commercially exploit an open financial service ecosystem, they must have robust customer consent mechanisms in place to ensure that access to bank account information and payments made on their customers’ behalf are fully compliant.

Customer’s permission must be explicit

Whether it’s a consumer that wants to shop online without a payment card, receive a consolidated view of their bank accounts or use a tool to analyse spending patterns; a financial services firm seeking rapid customer-checks; or a small business trying to arrange credit with an alternative provider, the customer must always provide explicit consent.

Consents must meet a range of rules on security, providing scope to cancel initiated transactions, and enabling traceability and the mitigation of fraud risks. Current parameters include:

• The TPP’s identity e.g. who the customer wishes to share data with

• What data they wish to share e.g. payment details

• How frequently e.g. monthly

• When consent will expire e.g. after 12 months.

What it doesn’t include is disclosure of information relating to the identity of the customer, such as their address, date of birth and social security number. This is because that information is not necessary or requested to initiate a payment or access account details.

When consent has been granted, consumers can exercise the account information or payment initiation service of the TPP. The TPP can then process the information request to the respective bank to see whether consent has been obtained. The bank then verifies whether consent has been granted and belongs to this person.

The bigger data picture

But PSD2 requirements are only part of the consumer consent story. There are important overlaps with the new General Data Protection Regulation (GDPR) which creates a regulatory framework to protect customers’ personal data, ensuring it is “freely given, specific, informed and unambiguously”.

GDPR also means consumers must have the ability to view, edit, download and delete all personal data (including their consent settings) that are being held on their behalf. This effectively puts banks in the position of data controllers of their customers’ information and makes them responsible for the purposes and the manner in which personal data is processed and shared.

Owning the consent process

While TPPs will likely initiate the process of securing customers’ consent, including consent for their own activities and use of the data once obtained, banks will ultimately remain responsible for confirming, or otherwise separately obtaining, the consent directly with their customers.

That means they must be able to deliver, via online banking, the tools that enable customers to opt-in and give consent for others to access financial data or make authorised payments on their behalf.

In addition, under PSD2, banks must either enable third party access to the data through the same interfaces they use for interacting with customers or alternatively develop a new 'dedicated interface' for that purpose.

Removing complexity

It’s clear that managing PSD2 and GDPR compliant, multi-channel consents and their lifecycles, with a myriad of TPPs, across a vast customer base, is a tremendously challenging process. This is not helped by the fact that banks are complex organisations with many internal services and IT silos.

To succeed, they will require innovative ways to request, record and immutably prove customer consent and to manage the use of customers’ personal data. This includes APIs that can be seamlessly embedded into their own existing, pre-authenticated customer touchpoints, as well as allowing TPPs to easily capture the customer consent via websites and user apps to facilitate their own services.

Getting the best out of APIs

To be sure of success, banks should look for well documented APIs, that:

• can capture consent in real-time

• generate auditable and immutable consent receipts

• connect quickly, seamlessly and securely into existing systems

• offer reliable, scalable, flexible and end-user centric platforms

• deliver customisable preference centres so customers can easily choose, amend and revoke consent.

To make consent process as frictionless as possible, some TPPs will opt to use their own direct consent APIs which allow users to initiate payments/instructions, without visiting a banking channel.

In practice, however, most will prefer a two-part process, whereby the TPP initiates consumer’s consent using an API granted by the bank, and the bank remains responsible for confirming it directly with the customer. This will afford all parties the most protection from fraud. This is where ndgit comes in. ndgit’s API management platform includes well-tested consent management to help Banks make the permission process as secure and frictionless as possible.