Taking charge and reducing charges

Friction in online journeys can be caused by many things, and often in financial services we can feel like we’re balancing between meeting our regulatory requirements and introducing too much complexity into our online journeys. Using open banking is one way we can significantly reduce this friction, whilst also reducing the charges that are associated with taking payments from customers.

I transferred some money to a relative in Canada recently, using Wise (formerly TransferWise). The last few times I’ve done this I’ve had the choice between using a debit card within the app or website, or noting down a bank account number, sort code and reference number to set up a Faster Payments transfer from my current account. On one side I’ve faced higher fees and on the other, increased complexity and having to switch in and out of different apps. Wise chooses to give me the choice and passes the costs and benefits on to me as the customer.

A major feature of Open Banking is relatively underused – Payment Initiation Services

This time was different though. I had the option to authorise the payment from my bank account using open banking. I selected my current account provider from a list and was transferred to my bank. Logging in with my online banking credentials, I clicked to authorise the transfer and that was it. I was passed straight back to Wise – no double-checking of reference numbers before transferring, no needing to remember to log in to my bank to make a payment, no uncertainty about whether the payment was received.

Payment Initiation Services (PIS), part of the Second Payment Services Directive (PSD2), notes that “[access to] a user’s payment account to initiate the transfer of funds on the user’s behalf, [requires] the user’s consent and authorisation”. This can be implemented within a mobile app or as part of another online journey. PIS can be used for a broad range of payment types, from single payments (instant or future-dated) through to setting up standing orders and processing bulk or batch payments. Additionally, the same framework supports confirmation of funds requests, and more complex multi-step authorisation processes.

This framework is a part of open banking, the definitions and standards of which are published and maintained by the Open Banking Implementation Entity (OBIE) with the aim to open up the communication layer between large entities to customers and small and medium-sized enterprises. The use of open banking-enabled products doubled in the six-month period from January 2020, according to data from the OBIE.

Imagine if a customer could make a payment into their ISA from within your app, just by selecting an amount and an account and confirming it with a fingerprint. You can show them the current balance of their account before they confirm, either through your own interface or their bank’s when confirming the payment. Imagine batching refunds to customers. Imagine the autonomy of pull-based recurring payment collections, with the shorter clearing times and reduced potential for chargeback or refund claims inherent in push payments. Imagine reducing your online card processing fees, whilst retaining the user within your application, thereby reducing the number of abandoned online journeys.

By offering these services to customers, providers can take ownership of the payments-in process. If you are providing a customer with an ISA for example, and you show them their current account balance (as an Account Information Service Provider/AISP), the next logical step is to own that payments-in process (as a Payment Initiation Service Provider/PISP). Rather than send the customer away to someone else’s site or app to make a transfer or force them to dig out their debit card, allow them to set the details of a transfer from within your app or website. This way, the only time they leave your process flow is on your direction, to authorise the payment at their other provider. Once authorised, they are returned to your site. Friction on the payment is reduced and the customer’s attention is retained within your app.

Integrating PIS into existing or future flows is achieved via open banking application programming interfaces (APIs). In most organisations with a mature API-based system architecture, adding PIS as a means to take payment should be a case of implementing a small new internal service to consume instructions internally and drive the payment initiation API interaction. It also adds a suitable workflow to the user interface to support this. Alternatively, a number of providers exist who will provide you with a simple API for use within your user-facing application and handle the payment initiation API on your behalf.

This is one example of how API-driven communication is having a major impact on the financial services industry. How many direct debits or debit card payments will this replace in 2021? Will we look at these in 2025 in the same way we now look at cheque payments? Supported as legacy for only a few customers, with the hope of phasing them out as soon as possible to save time and cost? Reducing friction for customers benefits us all as an industry but on a more personal note, perhaps my family and I will benefit from easier, cheaper payments as well!