56. Virtual Accounts

Let’s say few of your friends go out for dinner (aah… Such a pre-2020 thing). Typically, there will be 4 types of people. First — who eats and drinks without thinking much. Second — one who stays sober till the end and cross-checks the bill to make sure the waiter hasn’t added an extra plate of Kababs. Third one — jumps to pay the bill (someone who loves credit card reward points). Then when it comes to splitting the bill, you have the fourth one who says: I don’t believe in UPI — I will do bank transfer (weirdos).

Let’s say you paid the bill and each one owes you Rs.800. If two people do a bank transfer without adding any remarks, then how will you know who transferred the amount.

Let’s move the same problem to the business world (not the party thing but bank transfer). Imagine, you are collecting funds from multiple parties and if everyone does bank transfer, then how will you reconcile (who paid and how much). Of course, they have to inform you offline and then you have to sit and match the transfers.

To solve this problem, we have a Virtual Account concept.

Stage 1: Creating Virtual Account numbers (and IFSC) for each customer and communicating it to customers (through App or mail)

Illustration: Creation of VAN and sharing with users

Stage 2: Customer to add this virtual account to her bank account as beneficiary

Stage 3: Transfer money to the beneficiary a/c from net-banking either by IMPS or NEFT or RTGS or Fund Transfer

Illustration: Transferring funds to assigned VAN

Note: It is possible to enforce remitter lock i.e. few banks (Yes and IDFC) pass the name of the customer sending money to the virtual account, with string match logic PAs/Banks can accept the funds only from whitelisted accounts. This is emulating TPV (Third party Validation) flow of net-banking which is quite important feature for regulated investment (MF, Stocks) merchants

Settlement to Merchant

Although some of these rails work in real time or with 30mins delay and also 24x7, that doesn’t mean the merchant will receive funds immediately.

Usually Payment Aggregators or the bank will do settlement to the merchant a couple of times on a working day.

Note: Payment Aggregators park the received funds in a dedicated wallet of a merchant. Merchant can withdraw the funds to settlement account any time.

Refund:

There is nothing called ‘refunds’ for this solution. In case, the merchant has to refund then simply do payout to customer’s bank account via IMPS, NEFT channels. Remember: PA/Bank will charge for these payouts.

Commercials:

Think of it, there are no real commercials for anyone involved.

Customer used her bank account to transfer funds to the beneficiary via rails which are very much free.

There are no free lunches… so banks or PAs charge the merchant for the service. Ideally the commercials will be flat rate (e.g. Rs.1) or can be more creative and offer a differential flat rate based on the amount (e.g. Rs.1 up to Rs.10,000 and Rs.3 for above Rs.10,000)

Benefit:

• Unlike NB which is limited to 45+ banks, Auto collect can be used by customers of smaller banks , thereby increasing the penetration
• Lower commercials

Limitations:

As they say in the wild west, “don’t carry Tuna to a gunfight”… So just because there is a solution which is economical that doesn’t mean you should offer it to everyone.

Especially considering below limitations of this solution:

• Adding Beneficiary: Customer has to add the virtual a/c as a beneficiary. Most of the customers will do it if they have a need to transfer funds regularly (no one will do it for one time transfer)
• Broken Flow: PG transaction starts and ends in a single flow meaning when the customer clicks ‘pay’ then the merchant knows that something is going to happen. But in this solution, merchants are clueless when transfer will be done.
• Open Flow: Also, when a customer transfers funds, the merchant gets to know the fund is received and from whom but won’t get to know for what? In Payment Gateway, a unique order ID ties a payment to an order but there is no order ID here. So the customer has to write correct remarks before a transfer.

Use cases:

There are some really good use cases where the solution works flawlessly:

1. Investment: Customers can transfer funds to the wallet of an investment firm/brokerage and use those funds to purchase. This is quite prevalent in Mutual Fund/Stock brokerages and even crypto exchanges or ideal of gold harvest type investments
2. B2B Payments: Transferring funds towards pending invoice.
3. Loan repayment: Repaying monthly instalment (why use Payment Gateway, just transfer funds by logging into your bank account)
4. Wallet Top-up: Economical way to top-up the wallet balance.
5. Education Institutes: One of the traditional models for fee payment is challans. A student/parent will get challan and they have to deposit money in the bank against that Challan. Instead, Virtual Account can be printed on those challans and parent/student will deposit or transfer against that a/c. . Easy to reconcile than challans

UPI:

How can we not talk about the prodigal son of India’s payments ecosystem.

Yes, a similar solution can be built on UPI where a merchant will create a virtual UPI ID for each customer (retail or stores) and the customer can make a payment to that UPI ID. This virtual UPI ID can be generated as a QR Code and the same can be pasted all over the places (E.g. KiranaTech companies or offline QR payments companies use this solution)

How is it different from standard UPI ID or static QR Code?

Virtual UPI ID: ABC.merchanA@bank

Standard UPI ID: Merchant@bank

Hope you noticed the difference between these two.

To create standard UPI ID or static QR, merchants would need to have an account and provide KYC (as needed by the acquiring bank). This can be a time consuming process. But Virtual UPI ID is created based on merchant (e.g. KiranaTech) company’s KYC and account. So easy to create thousands of Virtual VPAs within no time and scale the roll out.

Commercials for this solution are zero (as per GOI guidelines) but banks/PAs charge nominal charges for the APIs, infrastructure, reconciliation and support efforts. Sometimes the fee structure can be VPA creation fee and transaction fee. Transaction fee can be flat or percentage or even possible to have amount based slab wise flat fee.

Final word:

This is an important solution, not because it has tremendous value (sure, it has ‘some’ value but not ‘tremendous’) but it is important as this completes all the solutions that I have seen for collections. Uff.. If I have missed something then do let me know.

See you soon with another topic.