Money Go Round - A Look into PSD2’s Open Banking Payments

From the History Books

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.

A Norm, no longer an Aberration

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.

1. United Kingdom: The UK has been a leader in Open Banking since it launched in 2018. The Open Banking Implementation Entity (OBIE) was established to oversee the rollout of Open Banking, and it created the Open Banking Standard, which mandates that banks provide third-party providers access to customer data through APIs. The standard includes strict security requirements to ensure customer data is protected.
2. European Union: The European Union (EU) introduced the Payment Services Directive 2 (PSD2) in 2018, which mandates that banks in the EU provide third-party providers access to customer data through APIs. The PSD2 requires banks to establish secure channels for data sharing and imposes strong security requirements on third-party providers.
3. Australia: In 2020, the Australian government introduced the Consumer Data Right (CDR), which gives consumers control over their data by allowing them to share it with third-party providers. The CDR applies to the banking sector, and it requires banks to provide access to customer data through APIs.
4. Singapore: The Monetary Authority of Singapore (MAS) launched an Open Banking initiative in 2020 to facilitate the development of innovative financial services. The MAS requires banks to provide APIs for third-party providers, and it has established guidelines for API standards and security.
5. Canada: In 2021, the Canadian government launched the Consumer-directed Finance (CDF) initiative, which aims to give Canadians more control over their financial data. The CDF requires banks to provide customers with the ability to share their data with third-party providers through secure APIs.
6. Mexico introduced a ‘Fintech Law’ in 2018, Japan has been encouraging banks to publish their Open API policies and contract with registered third-party providers, New Zealand has been seeking voluntary support from banks and South Africa has been closely monitoring PSD2 for replication.

The motivation behind this transformation

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.

Deep-Dive in2 PSD2 – Payment Initiation Services

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

• Full Transparency, Mandatory Approval: It is important and necessary to make the PSU aware of all information and then make a conscious choice to proceed with the payment. Furthermore, the ‘Point of No Return” needs to be highlighted to the PSU before they make the final decision to proceed with the payment.
• Similar User Experience: The ASPSP is mandated to provide a similar experience and convenience to the PSU regardless of whether the transaction originates in the ASPSP proprietary channel or through a PISP. This creates a level playing field for all the PISPs while upholding the convenience of the PSU.
• Seek Information and/or Initiate Transaction: The PISPs are allowed to, depending on the exact requirement in the process flow, either retrieve information or seek to initiate a payment transaction on behalf of the PSU. Examples of the nature of the information sought are the status of payment transactions and confirmation of funds.
• Collaboration between the PISP and ASPSP for the benefit of the PSU: A healthy collaborative atmosphere should prevail in the relationship of such intermediaries towards customer (PSU) satisfaction. For any information that is pending in the request from PISP, the ASPSP should seek incomplete information from the PSU in the flow prior to the transaction initiation. Similarly, in the case of confirmation of funds, If the ASPSP does not have a system in place that enables it to adequately respond to a confirmation request, it must provide the PISP with the necessary data to determine the availability of funds.

The following are the possible options around which the flows have been created.

• Point of Account Selection – This can happen either at PISP or at ASPSP
• Completeness of the Information – Any supplementary information that the PSU needs to be aware of should be shared and approval sought. The nature of the information will generally depend on the type of transaction being pursued, the status of PSU’s account relative to the transaction, and any custom requirements/offerings on the part of the ASPSP
• Option to save the account details with the PISP, for convenience related to future transactions and refunds
• Option to seek confirmation of funds before initiating the payment transaction.
• Option to customize the payment and/or create different payment types
  • Choose Payment Rails – Any changes from the default either specified by PSU with the PISP or suggested by ASPSP for the nature of the transaction and for any other reasons
  • Choose Future Date for Single Transaction – The PSU may choose to schedule a transaction to happen at a future date.
  • Create a Standing order to make multiple payments (of a specified amount and to a specified payee) either regularly or on a number of specified future dates.
  • Create an international transaction i.e., debiting of the payer account and crediting of the payee account happen in different currencies
  • Make group payments in bulk or in batches. Bulk Payments are when multiple payments (to different creditors) are initiated from the same debit account. The amounts for each individual transaction may vary but the other properties (payment date, currency, etc.) remain the same for all transactions. Batch Payments provide additional advantages. Here multiple credit accounts can be paid from multiple debit accounts. Payment properties can change between multiple batches but possibly remain the same for all transactions in each batch
  • Initiate a payment transaction that requires authorizations from multiple users
  • Authorize a VRP consent setup to exempt SCA authentication, with subsequent payment transactions being exempted following a successful consent setup.
  • Customize a VRP consent setup (with SCA authentication exemption) to adhere to sweeping consents, with subsequent sweeping payments
  • Authorize a VRP consent setup with delegated SCA, possibly to the PISP

Detailed Use Cases

Single Domestic Payments

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

• Alert for overdraft (exceeding account limit) or exceeding overdraft limit with associated interests and maybe, fees
• For a change of the Payment scheme (rails) from the default
• Possible duplication alert
• Alert for fees and charges (possibly related to Forex) for international payments.
• Alert for payment completion date/time
• Custom user journeys for vulnerable customers
• Value adds

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.

Other Payments

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:

• Different dates for first and recurring payments
• Open-ended or finite (either through end-date or through # of payments)
• Frequency of payments

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:

• Indicative exchange rates. If actual exchange rates are provided, then the validity window needs to be specified as well.
• Total charges involved. The PSU gets the option to choose the charge model and check the impact of the same on the payment.

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 = A group of payments (e.g., in a file) to be paid to multiple creditor accounts from the same debtor account, on the same date, with the same currency, and through the same payment scheme.
• Batch = A group of payments (e.g., in a file) to be paid to multiple creditor accounts from multiple debtor accounts. These may involve different payment execution dates, currencies, and payment schemes.

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.

Variable Recurring Payments

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.

Wrapping Up

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.