As UK Finance sets out its proposals to transition the Open Banking Implementation Entity into a service company model, Altus Digital Consultant Peter Stonham looks at how the Payment Initiation Services within the Open Banking framework can help to reduce friction in customer journeys, at the same time as benefitting the financial institutions offering these services.
Friction in online journeys can be caused by many things, and Financial Services must tread a fine line between meeting regulatory requirements and adding complexity to those journeys. Using Open Banking is one way to significantly reduce this friction, whilst also reducing the charges that are associated with taking payments from customers. The service has been criticised by some as too immature for mainstream adoption, but the publication this month of detailed proposals for a new service company to support Open Banking addresses that charge head-on. Replacing the entity overseeing the implementation of Open Banking with a longer-term model shows Open Banking is taking its place as a mature industry technology.
Payment Initiation Services, part of PSD2, “[access] a user’s payment account to initiate the transfer of funds on the user’s behalf, with the user’s consent and authorisation“. This can be implemented within a mobile app or as part of another online journey. Payment Initiation Services can be used for a broad range of payment types, from single payments (instant or future-dated) to setting up standing orders and processing bulk or batch payments. Additionally, the same framework supports the 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 currently published and maintained by the Open Banking Implementation Entity with the aim to open up the communication layer between large entities to customers and small and medium-sized enterprises.
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 Payment Initiation Services into existing or future flows is achieved via open banking APIs. In most organisations with a mature API-based system architecture, adding Payment Initiation Services 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, and adding 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.
With technology readily available and regulatory structures in place, firms will be able to move quickly to reduce cost and improve customer experiences. By 2025, direct debits and debit card payments could go the way of 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 and as customers. To see UK Finance continuing to support this framework and setting out its vision for an entity ‘at the heart of the Open Data and Payments market’ is cause for celebration indeed.
