How PSD2 and GDPR may improve retail payments for all?

Following my time setting up a new community bank (credit union) on an out sourced banking platform to UK consumers I have been watching the developments in retail payments from a distance.  As the team have now delivered a new Financial Institution to Bank of England standards with the help of our suppliers it is time to put pen to paper on the retail payments market again.

There is much talk about Payment Service Directive 2 (PSD2) and the opportunities, threats and costs to meet this regulation.  However, when PSD2 is coupled with the requirements of General Data Protection Requirements (GDPR), significant challenges emerge for retail payments.  These regulations impact how and what payment data is being passed between organisations and the necessary consents from who this data relates to in a payment transaction.

The pressure from PSD2 and GDPR requirements for changes in retail payments I foresee these in three areas.  Firstly the information provided to the parties sending and receiving the payments from a post payment statement line by default to a real time payment notifications by default.  Secondly the use of real time location data gathered when a notification is provided to a mobile device or a separate device is used to improve the security of payment transactions. Thirdly the upgrading or replacement of many legacy payment infrastructures to meet the regulations and facilitate the provision of enhanced services to all parties involved in payments.

Let me set the scene.

Everyone wants safer, simpler and convenient payments that work everywhere for everyone. Other stakeholders want richer data about the payment ultimately to add value to the transaction in some way.

So some retailers want more payment transaction information and other retailers just want other things faster throughput (contactless) or to accept as many methods that their customers want to use.  There has also been a number of repeating stories about the security and the way customers currently use contactless payments[1], “retail staff routinely complete contactless transactions without showing the amount on the handset to the paying customer.” 

I believe the people either sending or receiving payments do not just wants easier, simpler or more secure payments but more certainty and control over the payment.  By certainty I see this as a confirmation they have paid the right person the right amount. By control I see this as choices about how they are told of what they have purchased, their receipts, either electronically, paper or both. Finally mixing both certainty and control is knowing their rights if things go wrong. 

The other stakeholders include the payment scheme including all parties associated with payments ecosystem that provide value add services to any payment scheme. For payment card schemes and other payments schemes this includes 3rd parties providing Business to Business (B2B) or Business to Consumer (B2C) services.  This could be in terms of an out sourced data processor, a provider of richer data or a service improving the security of transactions to reduce r fraud.  All this has to be delivered at a cost that is affordable and a consumer experience that both the sender and receiver of funds are happy to adopt.

Meeting regulatory challenges

In the EU / UK the challenges are the processing of the payment data under the GDPR with the encouragement of more completion through the PSD2.  This is also coupled with the external pressures on costs of payments costs in the EU[2] and other national governments attention to these costs.

In the technology space retail payments are struggling to keep up with the new environments, new interfaces and how different types of people and organisations interact with payment services.

This is all coupled with probably the widest age group and demographic of individuals using electronic payments from children telling their parents how to make a payment for say a game through, generation X,Y and Z  to the elderly and disabled .  All these people have lived with payment cards for all or a significant part of their lives and online bank payments for the last 15 years or so.

Each group of individuals (market segment) have different appetites to change, risk and cost of payment transactions to each of them.

Let us look at the issues for retail payments

Firstly when moving money from one account to another account or to cash[3] will always have a variety of risks associated with the transaction.  This is further complicated where the transfer is to pay for goods and services.

Secondly who pays the costs for the processing payment and how the costs are attributed to make a payment.  This is the seller of goods or services for card schemes. But or more generic payments this primarily[4] the sender of the payment or the organisation that holds the senders account. In most schemes the fees are applied to businesses including the receiver of funds.

Thirdly why are there rules, regulations or agreements between parties.  This is mainly to establish trust between either the seller and buyer or sender and receiver of funds.

Lust us look at where payment technology is going?

At the highest level I see:

• Enhanced end user communication channels between each of the parties and systems
• Enhanced authentication techniques being delivered with technologies available to end users
• Enhanced and more varied interfaces between humans and systems used by organisations

In this article I am not going to discuss these new tools such as distributed ledgers, biometrics and other techniques but look at the generic issues for general retail payments in each of these areas for technology and generic stakeholder.

I have attempted to model risks and potential enhancements for payment schemes in a simplified way.  Together with a summary of the challenges PSD2 and GDPR regulations brings to retail payment environments. 

The high level risks in moving money from one account to another are grouped under three area s that mitigate these risks: 

1.       End User Comms – such as the costs to provide information to parties involved in a payment for example providing a statement of transactions at the simplest level.

2.       Authentication – such as the costs to deliver, maintain and manage an authentication method such as  Personal Identification Number (PIN)

3.       Interfaces – such as the costs to define, implement and maintain data communication interfaces between parties such as Fasterpayments in the UK

Risk

Wrong amount is transferred between parties?

End User Comms 

Use of transaction confirmation messaging via a trusted channel

Authentication  

Out of transaction band authentication and communication with the Payer or a token requesting a previously agreed payment amount.    

Interfaces 

Support end notifications before or after he transaction, emails etc..

Support validation of payment amounts.

Risk  

Payment account takeover for whatever purpose including transferrin the value into Cash

End User Comms   

Use of transaction confirmation messaging through trusted channel or channels dependant on transaction type.

Authentication  

Out of transaction channel authentication using appropriate methods. Also extra transaction checks on extra data sources.

Interfaces

Support new types of data to provide more information about the transaction. To the party authorising the payment.

Risk

Payment is sent to the wrong account, a non-existent account and fraudulent accounts including accounts taken over by fraudsters.

End User Comms

Provide information on the owners of accounts involved in the payment both ways e.g. senders information to recipient and vice versa.

Messaging through trusted channel or channels to each party in the payment.

Authentication 

Ability for authorisation of the payment after payer verifies the details of beneficiary.

Use of multiple sources of information to prove the identity of account owners both on account establishment and on each transaction such as location etc..

Interfaces

Support data about beneficiary not just limited account owners name but also extra information around type of account or customer etc..

Provide the ability to reject transactions following or check information on transactions.

Risk

Fraudulent account ownership

End User Comms

Use of different channels to deliver different types of transaction data.

Note comms channels to be authenticated as owned by end user.

Authentication 

Advanced identity checking of all parties using multiple data sources.

Clearer identification of sender and beneficiary of payments.

Interfaces

Sharing fraud info between and with all relevant parties.

Needs real time checking of account information during payment.

For each of these three areas the analysis now shows what each generic stakeholder may have to invest in implementing enhancements to improve payments.   As mentioned earlier there are two generic business models for payment transactions either the receiver / beneficiary pays for the payment or the sender or pays the majority of the payment transaction costs via the payment scheme. 

End User Comms

Sender of funds (Payer)

Establishment of trusted comms channel

 i.e. sharing email addresses, downloading applications etc..

Receiver of funds (Payee / Beneficiary)

Accepts how they are informed of receiving funds. If required in real time setting up of trusted comms channel i.e. sharing data, implementing systems, downloading applications etc..

Scheme (Mover of funds)

Defining and certifying the channels of, methods of communication and payment transactions that are trusted by all parties.

Account provider (Holder of funds)

Establishing the communication channels with the account and operating the services e.g In app notification, email, call services etc…

Authentication

Understands why and the value of transaction authentication being asked for at that time for this transaction and costs if applied.

Receiver of funds (Payee / Beneficiary)

Accepts that any authentication is worth the cost both in terms of the ‘Senders’ experience ease of use etc.. if paying the costs i.e in a Card Scheme.

Scheme (Mover of funds)

Defining and certifying the authentication methods are trusted and the rules about when and when not they are enforced.  

Account provider (Holder of funds)

Implements the authentication methods including the identification of and managing the end users experience and tools. 

Interface

Acceptable user experience in terms of ease of use and trusts in the service.

Receiver of funds (Payee / Beneficiary)

Accepts the costs to implement and transact with the scheme being matched by the value returned.

Scheme (Mover of funds)

Pays for the establishment and operation of the scheme for the payment fees received.

Defines any changes to the scheme technically, commercially and manages interfaces.

Account provider (Holder of funds)

Pays costs to interface to the scheme and receives business value in schemes adoption.

Finally for each stakeholder group the purpose of PSD2 and GDPR regulations is summarised here:

Sender of funds (Payer)

PSD2 

To increase competition and options available for retail payments.

To mitigate risks on sender being legitimate owner of the account and the receiver being the intended party.

GDPR

Improved user data security and transparency on the use of the payment data.

Receiver of funds (Payee)

PSD2 

To increase competition and create a stable technical platform for a defined set of transaction types.  This could include what processes and the systems requirements to perform each transaction type.  For example relevant senders authentication being needed to perform a transaction.

Increased security and transparency on the use of the payment data.

GDPR

For Receiver pays schemes where the payer provided payee with their details may require the receiver or an agent of them gain consent to hold these details from the Payer.   

Scheme (Mover of  funds)

PSD2 

Challenges schemes to meet the requirements without increasing costs to each party involved in the transaction.

Potentially requires interface upgrades to help account providers meet the challenges they face.

GDPR

Challenges schemes to ensure the privacy of the user data is controlled and relevant permissions have been established by all partners / parties involved in a transaction.

Account Provider (Holder of funds)

PSD2 

Upgrade low level infrastructure links to updated schemes and create interfaces for third parties to interface to accounts with relevant permissions from the account holder.  

GDPR

Requires increased consents, permissions and protection of the account holders data.

Conclusions

1. Technologies that improve communication between the end parties of a payments are likely to be the largest area of value add and new service innovation.  These improved communication services will help the implementation of the relevant PSD2 and GDPR requirements.

2. The use of unique device identifiers, location data and the use of different end user transaction confirmations will deliver strong enough user authentication for different retail payment transactions.

3. The Schemes are under threat from new providers that provide improved tools to enhance end user experiences.

4. Existing Account Providers may be challenged or threatened by new providers interacting with their customers or can see it as an opportunity to partner with new entities in the value chain.

5. There may be more fragmentation on who uses what payment method based on the end user demographics based on their access to technology and real time communications channels.

I foresee the followingchanges in retail payments: Firstly the information provided to the parties sending and receiving the payments from a post payment statement line by default to a real time payment notifications by default.  Secondly the use of real time location data gathered when a notification is provided to a mobile device or a separate device is used to improve the security of payment transactions. Thirdly the upgrading or replacement of many legacy payment infrastructures to meet the regulations and facilitate the provision of enhanced services to all parties involved in payments.

[1] http://www.irishtimes.com/opinion/letters/contactless-payments-and-retail-etiquette-1.3061102

[2] http://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:32015R0751

[3] Including Wire transfer, Informal Value Transfer Networks, Virtual Currencies such as Bitcoin or Linden Dollars (other virtual currencies)

[4] In some schemes the account holder of the beneficiary account may pay some fees to the payment scheme to share the costs if funds flow primarily in one direction.