The date of April 11th holds a special significance in the tech world.On this fateful day back in 1976, the original Apple computer was built, paving the way for Steve Jobs and co. to become the biggest company on the planet. Fast forward 40 years and India said “hold my chai” because they launched their own digital payment platform, the Unified Payments Interface (UPI) on this very date, in 2016. And boy, has UPI been killing it! 8.7 billion transactions were processed in March 2023, which is more than the number of people in the world today. The total value of these transactions was a whopping ₹14.05 trillion, which is almost as much money as Elon Musk has under his mattress.
Now that I have your attention, let me tell you that the reference to April 11 ends here. The rest of the article focuses on Open Banking (OB) with a specific focus on digital payments enabled through the OB framework. And in that sense, UPI can be regarded as a pioneer in this space. But before I get ahead of myself, let’s get the definitions out of the way.
Open Banking refers to the practice of banks sharing financial data through APIs (Application Programming Interfaces) with other companies, including competitors. This practice enables customers to share their financial data with other providers, facilitating new financial services and allowing for more personalized and competitive offerings.
By mandating the banks to connect to a common interface (UPI, duh!!) and leveraging existing payment systems like the Immediate Payment Services (IMPS), Aadhaar Enabled Payments Services (AEPS), etc. to ensure the integrity and routing of the transactions; UPI probably stopped a couple of steps before a fully open banking ecosystem. But two things are worth noting here. One, it was the first time that banks in India opened up a subset of their customer-oriented services to entities outside of the bank, and two, fintechs were allowed to leverage the interface to create value-added services for the end-customer and service them directly. It was a start.
Many other countries followed suit. The approaches taken for open banking were diverse, but they all share the goal of empowering customers and promoting innovation.
The regulators are all about driving innovation and competition in the financial world, and they leverage contemporary technology to keep things fresh and exciting.
The new kids on the block (fintechs and big-techs) are having a field day thanks to open banking. Suddenly, they’re able to offer all sorts of unbundled and innovative financial products and services that make the old-school banks look like they’re stuck in the Stone Age.
And let’s not forget about the customers – they’re loving it too! No more juggling multiple bank apps or having to drag themselves to a physical bank – it’s all at their fingertips now. Not just the little guys, even the SMEs, and corporates can now have a holistic, 360-degree view of their financial positions that can, in turn, be leveraged for faster internal decision-making and cheaper, faster procurement of loans with custom rates. The motivations for either of these customers are, hence, not hard to find.
But spare a thought for the poor, old banks. They’re not exactly thrilled about this whole open banking thing. After all, if fintechs can offer customers way more value than they can, how to prevent the bank’s offerings from being commoditized, and what’s to stop customers from jumping ship at the first sign of turbulence? And let’s not forget about all the juicy customer data that they could be missing out on. So, no more customer insights to build cross-sell opportunities, and no relationship to push the same. Oh, the horror!
The banks are stuck between a rock and a hard place. On one hand, they don’t want to be left behind in this new era of financial services. On the other hand, they’re still grappling with their outdated systems and culture. Talk about a midlife crisis!
But here’s the thing, – open banking is the future, whether banks like it or not. Customers are no longer blindly loyal to their banks like they used to be. They want convenience, they want innovation, and they want it now. So, the hands of the banks are tied. But there’s a whole world of opportunities waiting on the other side for the banks. There is an opportunity to monetize data and services, which needs to be enabled through a robust API portfolio exposed through a secure platform. Simultaneously, the banks need to enhance their own online platforms and collaborate with partners to augment offerings and create a compelling proposition for their customers.
Now that we have established the world of open banking, the rest of the articles does a deep dive into the PSD2 directives for payment initiation services. It will get a little bit technical from now onwards, so consider yourselves forewarned.
Let’s get the jargon out of the way, and there are quite a few.
Open Banking API specifications support Payment Initiation Services (PIS) that enable a PISP to initiate a payment order, with the PSU’s explicit consent, from their online payment account held at their ASPSP. Post initiation of the transaction, the PISP is then further able to retrieve the status of a payment order for continued convenience and update of the PSU.
The following are the foundational principles that form the basis of PSD2 Directives
The following are the possible options around which the flows have been created.
Account Selection at PISP
All information of a complete payment order is passed from PISP to ASPSP. No supplementary information is needed by the ASPSP to process a single payment on the default payment rails for the PSU.
User authentication happens in the ASPSP domain. Post successful authentication, the payment transaction is initiated. The ASPSP notifies the PISP once the transaction is initiated; and later (on request) for any change in the status. The PISP, in turn, would notify the PSU of the change in payment status, as applicable.
This is the most simplistic flow.
Account Selection at PISP – Supplementary Info
ASPSP does not receive all information from the PISP to successfully execute a payment transaction for the PSU. An additional step in the journey (postauthentication) is required to display supplementary information to PSUs. This supplementary information may be ‘view only’ for the PSU so that he/she can review/validate all the relevant information and confirm before the transaction is executed.
Typical supplementary information may be required for the following scenarios
This is an umbrella flow that has all the different components that make up the supplementary information, with only those relevant to that particular transaction being shown to the PSU for explicit approval.
Account Selection at ASPSP
This is the flow where the selection of the debiting account is chosen not at the PISP level but at the ASPSP.
Post successful authentication, the ASPSP will ask the PSU to choose the account (from the available multiple accounts of the PSU at the ASPSP). Subsequently, payment is carried out and confirmation is provided back to the PSU (through the PISP)
While confirming the payment status back to the PSU, the PISP may request the PSU to save the account details, so that there is convenience aligned to future transactions and possible refunds.
Schedule Payments at a Future Date
This is the flow where the PSU exercises the option of scheduling a payment transaction to happen in the future, through specific inputs provided to the PISP.
Post successful authentication, the ASPSP will need to display any supplementary information about any difference in the actual execution date. For example, if the future date chosen falls on a Sunday, the ASPSP is obligated to inform the PSU that the transaction will happen on the next business day subsequent to the chosen date.
Standing Orders
This is the flow where through a PISP, PSUs can set up an instruction to their ASPSPs to make a series of payments of a specified amount to a specified payee on a number of specified future dates or on a regular basis. The PISP may allow the PSU to customize the standing order by choosing:
Post successful authentication, the ASPSP will need to display any supplementary information about any difference in actual execution dates for each of the payments specified in the standing order.
International Payments
This is the flow where through a PISP, PSUs can set up a single international transaction, to be executed in any currency and to any country, using a number of routing options in order to meet the priority required, provided that functionality is available to PSUs when making international payments directly from their online payment account (at the ASPSP)
Post successful authentication, the ASPSP will need to display any supplementary information and seek an explicit go-ahead from the PSU. Necessary considerations would include the following:
Just like a domestic payment, an international payment can be scheduled to be paid at a future date. Standing orders can be set up on international payments as well.
Bulk and Batch Payments
This is the flow where through a PISP, PSUs can generate group payments in bulk or batches
Bulk or Batch Payments can be generated through UI but possibly a more convenient way is to upload a file with all details. The PISP should be able to process the file and parse the information in the form of payment instructions while redirecting to the ASPSP for fulfillment.
Post successful authentication, the ASPSP will need to display any supplementary information and seek an explicit go-ahead from the PSU. In addition to capturing any incomplete information, the ASPSP should display additional information such as the expected execution date, specific terms related to this payment type, charges, etc.
Bulk and Batch Payments may be associated with payments made on a future date or include international payments. If so, then the necessary aspects of those flows would also be relevant here.
Multiple Authorization Payments
This is the flow where through a PISP, PSUs can generate (or provide authorizations for) a payment transaction that requires authorizations from multiple parties.
Post successful authentication, the ASPSP will need to display any supplementary information and seek an explicit go-ahead from the PSU. The PSU needs to be informed (as part of supplementary information) about the multiple parties whose authorizations are needed to execute the transaction, the status of each authorization (highlighting pending ones), and the timeline by which all authorizations need to be completed.
It is to be noted that while this use case talks about generating a multi-auth payment, other related use cases in this domain would be notifying a delegated user of a pending authorization and allowing the same user to provide authorization to an existing transaction.
Confirmation of Funds from PISPs
This is the flow where PISPs can request confirmation of funds on a PSU’s payment account for the amount necessary for the execution of the payment transaction initiated through the PISP. This is only valid for single transactions (domestic or international) that may or may not have a future date of execution.
The primary objective is to ensure the availability of funds to increase the probability of success for the payment transaction. PISPs may choose to design various valueadded features for the PSUs based on this functionality. For example, PISP may notify a user to top-up their account just before the scheduled initiation of a future dated transaction.
The point to note is that when presented with a CoF request, the ASPSP may either evaluate and provide a Yes/No response to the PISP or provide the base details to the PISP to enable the latter to make an evaluation themselves.
Payment Refunds
This is the flow where the account selection happens at the ASPSP. It is the endeavor of the PISP to save the account details for the PSU for subsequent transactions and for the smooth execution of refunds, should such a situation arise.
It is to be noted that the actual refund process is beyond the scope of this use case. Rather, this only involves getting approval from the PSU in the payment initiation journey for saving the account details.
The flow requires the PSU to state the request upfront to the PSU before redirection to the ASPSP for authentication. It is also mandated that post the successful initiation of the transaction, the PSU should be notified that the account details have henceforth been saved for refund purposes and no misuse of this data would happen.
VRP Payments with SCA exemption
This is the flow where through the PISP, the PSU is allowed to set up a VRP Consent for a series of payments. The setup of the consent requires SCA authentication. However, on the successful setup of the consent, individual transactions under the VRP Consent do not require the SCA of the PSU by the ASPSP.
Some key considerations (Consent Parameters) form the VRP Consent setup and include identification of payee, limitations around individual payments, expiry dates, etc. The consent setup is the first flow in this category.
Once the VRP Consent is set up, the PISP can trigger subsequent transactions under the VRP consent, as per terms agreed upon with the PSU. Normally these transactions would be preceded by a CoF request with VRP generated once funds are found to be sufficient. The ASPSP validates the transaction without a specific authentication of the PSU, as long as the parameters are found to be in line with the consent form. The PSU is notified by the PISP on the initiation of the transaction.
VRP Payments under sweeping access
This is the flow which is a subset of the VRP Payments under SCA exemption, where further consent parameters are added to adhere to sweeping norms. Globally, these norms allow consumers or businesses to transfer, or sweep, money from one of their accounts to another – a ‘me-to-me’ payment.
The process is the same as before, with the additional sweeping consent parameters.
Once the consent is set up, the subsequent transactions are SCA-exempt as long as the parameters are found to be in line with the terms of the consent.
VRP Payments with delegated SCA
This is the flow where through the PISP, the PSU is allowed to set up a VRP Consent for a series of payments, with each individual payment requiring the application of delegated SCA Authentication, from the ASPSP to possibly the PISP.
The consent setup process is the same as that of SCA exemption and sweeping access, with the key considerations aligned to this requirement.
Once the VRP Consent is set up, the PSU can trigger subsequent transactions under the VRP consent, as per terms agreed upon with the PSU. This authentication happens at the PISP level, followed by a CoF request with VRP generated once funds are found to be sufficient. The ASPSP only validates that the parameters are in line with the consent, before initiating the transaction. The PSU is notified by the PISP on the initiation of the transaction.
Open Banking has started a money-go-round, creating opportunities for startups and established companies to offer more engaging and personalized financial products and services. As initiatives such as PSD2 continue to evolve and shape the future of payments, it is important for all stakeholders to stay informed and adapt to the changing landscape. While there are still many unknowns, the future of payments is becoming more open, secure, and customer-centric than ever before. Open banking has the potential to transform banking services and bank business models in days to come. And the ball has started to roll.
Leave a Reply