Regulation 2.0 for Payment Aggregators: Reimagining the role of PAs and what still needs to change

Asheeta Regidi Head, Fintech Policy at Cashfree.

This article was first published on Medianama, dated May 29th, 2020.

By Asheeta Regidi and Reeju Datta

The RBI’s new Guidelines on Payment Aggregators (PAs) and Payment Gateways (PGs)1 are welcome in several ways. Serving as a ‘Regulation 2.0’ for PAs/PGs, these move past protecting customer funds alone (as per the RBI’s 2009 Directions for Electronic Payment Transactions involving Intermediaries2 or the ‘Intermediary Directions’), to an express recognition as authorised entities, and grant flexibility and control with operations and funds management. Key changes made now allow the reimagining of the role PAs/PGs play in the financial ecosystem, while a by-and-large consolidation of existing practices eases the compliance burden imposed on the industry.

Concerns have also emerged (around the single escrow account requirement or the overlap with the RBI’s 2015 norms for Import and Export Payments facilitated by Online Payment Gateway Service Providers3 or the ‘OPGSP norms’), leading banks and industry bodies like the IAMAI to approach the RBI for clarifications.

Bringing in clear authorization and recognition

The formerly applicable Intermediary Directions solely aimed to secure customer funds and introduce some accountability. The result was that permissions from the RBI to the PAs were not actual authorisations under the Payments and Settlement Systems Act, 2007 4 (‘PSSA’). These instead read like NOCs, with brief directions to comply with the Intermediary Directions and requirements like security and KYC. This made applicable compliance obligations vague and difficult to ascertain (consider ‘system provider’ obligations under the PSSA). It also led to hiccups with engaging with banks, which sought to serve authorized entities.

There is thus a change in regulatory attitude with the 2020 norms, through an unambiguous recognition of PAs as authorized entities (authorization will be via an application to set up a payment system through Form A5, PSS Regulations6 ), a specific compliance framework and increased flexibility. The move from nodal to escrow accounts in particular reflects this.

Flexibility with funds management

The primary mandate of the Intermediary Directions was the use of nodal accounts to handle customer funds, with rules pertaining to their operation. This was restrictive since the accounts were (structurally) owned by the banks. This prevented PAs from managing or operating the accounts themselves without the bank’s permission.

The move to escrow accounts is thus a significant change. Escrow accounts are owned by the parties involved (including the PA). A clarification needed here is whether the accounts are to be tri-partite (this was optional in the initial Discussion Paper7, but the final norms are silent). 

Regardless, the entailed flexibility with control, together with key changes discussed below, enable several new uses for PAs, beyond their traditional role for payment related collections and settlements:

  • Settlement Timelines

The Intermediary Directions previously mandated settlement within 2/3 days from the payment date (T+2/T+3). This prevented use cases where merchants prefer the PAs holding the funds for longer. An example is security deposits (say for car/furniture rentals) which are routinely refunded to customers. For the merchants, this would ease accounting since the deposits need not be recorded on their books, except on the occasion the deposits are retained.

The new norms ease this, allowing settlement upon shipment, delivery or refund (Ts+1/Td+1/Tr+1). They also allow the contractual determination of settlement periods upto the refund period, bringing in the required flexibility. For the PAs, this also provides an important risk mitigation technique for discharging their obligation towards refunds, disputes and chargebacks. Higher risk merchants, for instance, can be offered delayed settlements.

  • Permissible Credits and Debits

To safeguard customers, the credits and debits that can be made to PA operated accounts are restricted. Among changes introduced here is a new permitted credit allowing PAs to pre-fund the escrow account with their/ the merchant’s funds. This is complemented with new permitted debits to any accounts specified by the merchant.

The significance is that this allows disbursals on a much broader scale. PAs can disburse the funds pre-funded into the account, and for any purpose, as opposed to only for settlement of a payment transaction. This, for instance, enables certain API-based banking services by PAs, such as large-scale payment disbursals like employee salaries, marketplace vendor settlements, wage payments to contractual/gig workers, bulk refunds for cash-on-delivery orders, etc. It also allows PAs to offer new services to the financial industry, like loan disbursals or insurance claim settlements.

Other new permissible credits and debits also include payments for promotional activities, incentives, cashbacks, and so on.

  • Refunds

The norms also allow merchants to directly manage refunds themselves, subject to the customer being made aware of this. This brings in the scope of innovation with refunds processing, allowing a merchant to select a separate refunds service provider, say for benefits like faster refunds.

Another norm is that refunds are to be sent by default to the original mode of payment, unless the customer specifically agrees to an alternate. This brings in consent based flexibility for the customer, but also brings a risk component for merchants and PAs, since it exposes them to chargebacks (say for a disputed/fraudulent refund, since refunds are chargeback-proof).

  • Earning interest

Under the final norms, neither loans nor earning interest against the escrow account funds is permissible. The PA’s operations will also constitute designated payment systems8. Interest, however, can be earned over a ‘core portion’, computed on the basis of the average daily outstanding balance and transferred to a separate account- creating a new avenue of income for the PA. Previously, interest could only be earned on the PA’s commissions.The delayed movement of funds for settlement, along with the ability to pre-fund also allow greater average outstanding balances, thus increasing the ability to earn.

Single escrow account with one bank

A major change that must be reconsidered is the restriction of operations to a single escrow account with a scheduled commercial bank. The Yes Bank fiasco9 clearly demonstrates the continuity issues that arise. Even independent of this, technologically, it isn’t feasible to handle the volumes of transactions that PAs process with a single account and maintain reliable service levels. Use of a secondary or even a tertiary account is common.

For instance, large internet companies across ecommerce, travel, mobility, lending, etc., use PAs for high volume payment disbursals like contractor wage payouts, vendor settlements, or bulk refunds. During peak times like end-of-month cycles, transaction volumes can exceed 10 lakhs daily. Such high volumes exceed the peak transaction handling capabilities of bank APIs at present. The transaction load needs to be distributed across multiple bank accounts.

Standardising practices across the industry

The risks involved with being a payments intermediary meant that numerous requirements in the new framework were already imposed on existing players, albeit from other sources, like industry standards (PCI-DSS) or varying contractual requirements (say merchant/bank agreements). The new framework brings in uniformity and a baseline standard across the industry. Simultaneously, sufficient flexibility in the framework prevents a major upheaval to existing arrangements:

  • Merchant on-boarding

PAs take on some risk while on-boarding merchants, given that they are responsible for refunds, chargebacks, customer disputes, etc. Even prior to the norms, merchant on-boarding involved RBI-imposed KYC requirements and bank-imposed due diligence/screening requirements. These were extensive but varied, including  merchant identity verification (licensing/registration), credit checks, merchant website content requirements, security audits, etc. Active monitoring of the merchants is also required. For instance, PAs are required to terminate relationships in case of illegal transactions, fraudulent activity like excessive chargebacks or if website content or business models are changed without intimation.

The new norms now require a board-approved merchant on-boarding policy. There is scope for existing practices to continue, though the now mandated background and antecedent checks will necessitate an increased element of risk assessment. New checks like checking domain name purchase dates, reviewing social media activity, reviewing customer product reviews, etc., can come in.

While this risk assessment is welcome, industry stakeholders have highlighted that this can act as a bar to financial inclusion, particularly for small sellers, freelancers, casual sellers, and the like. The norms, however, do not mandate a uniform policy across all merchants, indicating that PAs can take a varied approach to the antecedent checks based on their risk appetite. Some clarity from the RBI here would be welcome.

  • KYC compliance

Merchant funds flow directly from the PA’s nodal/escrow account to the merchant’s bank account. This bank account will be KYC compliant, as per law. Banks are also required to ensure that the KYC details are updated and conduct prescribed AML/CFT checks periodically. Even so, PAs/PGs are mandated10 to undertake the same process again, prior to on-boarding. A waiver from the RBI of the KYC requirements under the new norms would help avoid the duplication. Operationalising C-KYC11or legal entities would also be a step towards easing this.

  • PCI-DSS compliance and security standards

The handling of card data requires PAs to be empanelled as payment facilitators12 with card networks. Requirements like verifying PCI-DSS compliance of merchants, setting up merchant management systems, etc., are thus already imposed. Further, this requires PAs themselves to be PCI-DSS compliant, making the now prescribed baseline technology recommendations13 easier to comply with. Self-imposed industry practices like ISO compliance also add to the ease. Some features are nevertheless new, like incident reporting and governance requirements. 

Here, the RBI needs to reconsider the blanket prohibition introduced against merchants storing card data. Given that existing practices and even the Discussion Paper allowed this subject to the merchant’s compliance with PCI-DSS, the rationale for discontinuing the practice is unclear. This can, for instance, hamper smooth checkout processes for customers.

  • Customer grievance redressal

The prescribed customer grievance redressal and dispute management frameworks are also previously imposed, though scattered (varying requirements via bank/merchant contracts, under the PSSA, under Ombudsman Schemes, etc.). The norms again, establish basic requirements (internal framework, nodal officer, etc.), but retain flexibility which helps account for varying obligations (resolution timelines for instance are not prescribed).

Cross-border Payments – Overlap with the OPGSP norms

A proposed restriction on dealing with merchants with no physical presence in India was thankfully withdrawn from the final norms, allowing cross border payment and settlement services to continue. The Discussion Paper had also proposed exempting the application of the norms to Online Payment Gateway Service Providers (‘OPGSPs’). The final norms however direct that the domestic leg of import and export related payments facilitated by PAs fall within its scope – this provision leads to certain ambiguities.

First, it is unclear whether or not the provision is intended to apply to PAs’ services as OPGSPs, since there is no direct reference to the OPGSP norms14. To illustrate, certain transactions that have an export/import element to them are dealt with as a domestic service, outside of the OPGSP norms (this is as per industry practices). For instance, the purchase of a ticket on an Indian ticketing platform like MakeMyTrip using a foreign-issued card, which can very well be done by a person located outside India, making it an export of the ticket-booking service. The ‘domestic leg’ of export/import transactions could thus also be a reference to such transactions.

Assuming instead that the direction does apply to OPGSP services, this raises a different set of conflicts. First, the OPGSP norms require separate accounts to be used for domestic and cross-border transactions, which clashes with the single escrow account permitted in the new norms. It is unclear if now even OPGSP processing has to be done via the same single escrow account, or if the export and import collect accounts are to be separate escrow accounts.

Rules like merchant on-boarding, KYC, net worth, etc. can be easily adapted for OPGSP services as well. Difficulties arise with other rules, like the variation in permitted credits and debits, and the settlement timelines. While the OPGSP norms were more aligned with the Intermediary Directions, it is unclear if the new norms’ benefits such as extended settlement periods, pre-funding, etc., are to be extended here as well (See table below).

An extension of the settlement timelines, for instance, will be beneficial here as well, to protect against chargebacks and refund issues. Order fulfilment and shipping for imports, for instance, can take between 7-21 days.

Non-Withdrawal of Intermediary Directions

Finally, the non-withdrawal of the Intermediary Directions is an issue, since it creates the possibility of entities that are intermediaries but not PAs, which will be obligated to use nodal accounts in the payments cycle. The similarity in the two definitions, however, makes it difficult to envisage such an entity. For instance, intermediaries’ functions are to (i)collect monies from customers and (ii) facilitate its transfer to merchants in final settlement. PAs, similarly, (i) receive payments from customers, (ii) pool them and (iii) transfer them to merchants after a time period. 

To avoid an overlap, it would be best that the RBI clarifies whether the Intermediary Directions are to continue, and if they are, to also illustrate the nature of entities that are to comply with them.

A welcome step forward

Overall, the norms are a welcome step forward for PAs and PGs. The flexibility brought in, and also the exemption to PGs (these can now choose to act solely as tech providers, instead of money handlers), demonstrate an attempt at regulation that is more in sync with the industry. Another important feature is the indication of some stakeholders suggestions being taken into account (the lowered net worth, the removal of the merchant physical presence requirement, etc.). The RBI must give similar consideration to concerns with the final norms, and issue the required clarifications.

  1. RBI Notification: Guidelines on Regulation of Payment Aggregators and Payment Gateways, RBI/DPSS/2019-20//174, dated March 17, 2020.
  2. RBI Notification: Directions for opening and operation of Accounts and settlement of payments for electronic payment transactions involving intermediaries, RBI/2009-10/231, dated  November 24, 2009.
  3. RBI Notification: Processing and settlement of import and export related payments facilitated by Online Payment Gateway Service Providers,RBI/2015-16/185, dated September 24,2005.
  4. The Payment and Settlement Systems Act, 2007.
  5. RBI Documents: Application Form For Authorisation to Set Up Payment System, issued under Regulation 3(2), The Payment and Settlement Systems Regulations, 2008.
  6. The Payment and Settlement Systems Regulations, 2008.
  7. RBI Document: Discussion Paper on Guidelines for Payment Gateways and Payment Aggregators, dated September 17, 2019.
  8. Section 23A: Protection of funds collected from customers, PSSA, 2007, inserted vide The Payment and Settlement Systems (Amendment) Act, 2015, dated May 13, 2015.
  9. Media Article  by Pratik Bhakta: Yes Bank crisis: A look at the impact on the fintech ecosystem, Money Control, dated March 6,2020.
  10. RBI Notification: Master Direction – Know Your Customer (KYC) Direction, 2016, RBI/DBR/2015-16/18, dated February 25, 2016.
  11. Website of CERSAI: Central KYC Registry.
  12. Report: The Visa Payment Facilitator Model: A framework for merchant aggregation, Visa.
  13. Annex 2: Baseline Technology-related Recommendations, RBI Guidelines on Regulation of Payment Aggregators and Payment Gateways.
  14. RBI Notification: Processing and settlement of import and export related payments facilitated by Online Payment Gateway Service Providers, RBI/2015-16/185, dated Sep 24, 2015.
Asheeta Regidi Head, Fintech Policy at Cashfree.