Executive Summary

  • RBI mandates banks to control accounts of ecommerce operators (clients of banks) in order that money to merchants is transferred in T+2 or T+3 days
  • This requires intelligence in the bank systems about operator transactions and all their events. This is not desirable considering the volume of transactions as well as the privacy concerns of the operators.
  • Implementation of these nodal accounts becomes excessively complex
  • Proposed solution for banks to implement event driven settlement systems to work in sync with the clients’ order management systems.
  • The client settlement systems generate events and related data and send the same to the bank’s settlement system. Such data is summarized / aggregated merchant wise.
  • A value addition for the clients may also be in the form of the settlement system generating the GST data formats and interfacing with the GST network.
  • These settlement systems may be offered as services with additional revenue opportunities for banks.

RBI Notification for Banks on Accounts for Ecommerce Operators
As per an RBI notification of 24-Nov-2009 titled “Directions for opening and operation of Accounts and settlement of payments for electronic payment transactions involving intermediaries”, banks are to maintain accounts that are to be used by ecommerce operators for collection and payment of monies in the process of effecting online sales, where the ecommerce operator intermediates between the merchant and the customer. As per the RBI notification, such accounts are not to be under the control of the ecommerce operators (intermediaries, the clients of banks), but the bank shall treat these accounts as internal accounts and control the transactions in these accounts. The notification further specifies that the bank shall do the settlement and pay the merchants within T+2 or T+3 days (under different circumstances), where T is the time at which the transaction is deemed to be completed. Further the banks are supposed to audit these accounts quarterly and submit the reports confirming proper operations in such accounts to RBI.

An online shopping transaction occurs over several days (in some cases even several months). While, normally a transaction is deemed to be complete when the product or service is delivered, there is a possibility that the customer is unhappy with the delivery and may seek a return and refund. A reasonable time frame may be assumed to allow for this possibility and then the transaction may be deemed to have completed.

Implementation Problem for the Banks
The problem from the bank’s perspective is that the various progressions of the shopping transactions occur within the intermediary’s order management system and may be known to the bank only upon intimation by the intermediary regarding the same. Getting information that leads to accounting entries on every event of every transaction would cause a tremendous load on the bank’s systems.

The bank systems processing every transaction of the ecommerce operator also is questionable from the perspective of the data privacy concerns of the ecommerce operators.

In addition, given that a sale transaction is protracted over a period of time, even the intermediaries have an issue of proper settlement of monies received and reconciling the same with the transactions [ please see the accompanying document on multi party settlement ]. The banks need to ensure that their ecommerce operator clients do proper settlements based on the events (Approval, Dispatch, Cancellation, Delivery, Returns, etc) that the individual transactions go through. Further, they need to ensure that these settlements are reflected properly in the internal accounts of the bank representing the clients’ and clients’ merchants’ accounts.

The Opportunity
To address this scenario, the banks may provide their ecommerce operator clients with a settlement system that works in tandem with the client’s order management system and performs the settlements in line with the Tax and RBI guidelines, as well as keep them updated with evolving norms and regulations. The scenario envisages a module that is implemented by the bank at the intermediary’s location that works seamlessly with the bank’s settlement system. This solves not only the problem of management of the intermediary accounts as per regulations, but also offloads an important pain point from the intermediary’s order management system. The bank may offer this “Settlement Service” at a suitable fee. There is substantial revenue addition while implementing appropriate controls in line with the regulatory guidelines

In addition, the GST bill (draft version) has special sections for the ecommerce operators. They would need to deduct the GST from the merchant’s share of the transaction and deposit the same along with statements with details of the online transactions for all merchants. This is likely to add further processing and complexity overloads to the operations of the ecommerce operators. The settlement systems implemented by the banks may offer GST interconnectivity easily since they process all the data and it would be rather simple for the settlement systems to report the same to the GST network.

The Solution
The Bank would implement a central settlement system that is fed with the Bank Settlement events – that is, events that are relevant for ledger entries to be passed at the bank. These events, along with all the required information would be fed from the client settlement systems that are implemented by the bank as a service to its ecommerce operator clients. These events need not be passed on to the bank for every event occuring on every shopping transaction (that would impose a tremendous load on the bank’s systems). Instead, these bank settlement events could be the summarized events that cover the merchant accounts as well as the operator’s nodal account. For instance, the total credits for a given merchant of an ecommerce operator can be sent as a single event (say “NewOrder” event) that would result in a credit of the summarized amount to the merchant’s account. Similarly, the events that would trigger the payout (say “Payment” event) could be sent in by the client settlement system indicating the amount that needs to be released to the Merchant.

The client settlement systems, on the other hand, would account every event of every online shopping transaction and keep track of the details. Each of these, further, would also be mapped to the summary event transactions sent to the bank. A summary event and its accounting in the bank ledger can be traced back to all the constituent events of individual transactions. The client settlement systems would work mostly with pre-configured rules with certain modifications for adapting to client systems.

The client settlement systems work seamlessly and harmoniously with the bank’s settlement system. The bank, on any given day, would have an accurate indication of the clients’ accounts as well as the clients’ merchants’ accounts. These could be tracked back to all the individual transactional events in the client’s settlement system. The backward and forward references maintained between the client and bank settlement systems would help maintain settlement integrity across the client and bank systems.

Most importantly, the specific details remain private with the client, while the required information resides at the bank.

The connectivity with GST, provided as an additional service by the bank would make the proposal very attractive to the clients. This is because the sections related to the ecommerce operators in the GST draft bill impose upon the ecom operators to deduct GST and also upload transactional details. The settlement system that has in its control all of the data can seamlessly integrate with the GST network providing great relief to the clients. This would add lot of value to the bank’s services.