42. Pay-OUT

42nd article… 42 is an interesting number… those who have read The Hitchhiker’s Guide to the Galaxy know what I am talking about…

Considering 42 is one of my favourite numbers, I decided to write something different… about payments (of course) but different types of payments

Similar to two sides of a coin, ‘payment’ also has two sides — collection and disbursement. So far I have covered ‘collection’ related topics because they are important, visible and of course, are ‘about revenue/sales’.

Disbursements or payouts work behind the scenes and generally, do not get the attention they deserve. So let’s talk about disbursements

Disbursement Use cases

Every industry has both collections and disbursement use cases.

Illustration A: Few payout use cases from various sectors

Now we know there are abundant use cases for disbursements even in traditional sectors such as Insurance and NBFCs.

These use cases are not the same as they vary in terms of:

a. Periodicity:

Few are periodic (e.g. delivery person’s incentive) and few are random (e.g. game winnings). Few are uniform across a time period (e.g. Travel operator’s payout) but few are skewed (e.g. insurance agent incentives) and few are simply random (e.g. COD refunds post a big sales campaign)

b. Number of Payouts in a time frame:

Few payouts are of smaller volume (E.g. agent incentive in an insurance company) but few cases have large volumes (e.g. Fantasy game winning post an IPL match)

c. Value of payouts:

Few are small ticket payouts (e.g. doctor appointment fee) and few are large tickets (e.g. insurance claim settlement)

d. Criticality:

Few cases are not time sensitive (e.g. policy refund) but few cases are super time sensitive (e.g. partner truck/lorry driver payout)

e. Who is disbursing the funds?

Some use cases are straight forward where a merchant does the disbursement (E.g. Swiggy doing payout to restaurants) and in some cases, someone else will do the disbursement on behalf of the merchant (e.g. TPA initiating payout on behalf of an insurance company)

Here is one more example: I invest in PPFAS MF via Zerodha. So I make payment to Zerodha but when I withdraw the MF on Zerodha site then will I get funds from Zerodha or PPFAS or someone else?

f. Cost:

What is the cost of disbursement? Few modes may be cheaper and few are expensive. Few modes may ‘look free’ but there are no free lunches, especially if the merchant wishes quality solutions that meet merchant’s requirements. But still cost does play an important part.

Illustration B: Patterns of payout & examples

That’s not it… We will add more complexities on the way… It is payments, so what is fun without a bit of complexities and exceptions

Now, we know ‘disbursements’ are not ‘that simple’… disbursement will impact revenue and operations. If your delivery person doesn’t get incentive on time then he will go to another company. If your lorry partner doesn’t receive funds then he won’t move the lorry and you will lose that order (or may be that customer). In today’s super competitive world, these things matter.

What are the solutions:

Firstly, we need a payment instrument to which the merchant can push the money and then a method or rail to push the money from the merchant’s source account to that payment instrument… once you figure out these things then ‘just’ make it ‘efficient’.

Here is the combination of payment instruments and supported rails.

Illustration C: Instruments, payout rails and features

Note: Some of the wallets allow to do payouts to those wallets directly (e.g. PayTM and AmazonPay). These payouts work in real time and have dependency on KYC compliance and wallet limit.

Who provides payout solutions?

Merchant can avail these solutions from banks, payment aggregators or a combination of both.

Working:

To make the disbursement, a merchant needs

a. Source account (where funds are parked): It can be merchant’s own account or merchant needs to park the funds in the payment aggregator’s account

b. Payment instrument details (to which funds are pushed): It will depend on the payment instrument (E.g. in case of UPI:UPI ID and for bank account transfer: account number and IFSC)

c. Relevant rail to push the funds: Depending on the payment instrument, you would need a rail to push the funds (refer illustration C. )

If you notice illustration (c ), IMPS and NEFT also can be used to push the funds to Credit Card… i.e. because every credit card issuer has IFSC (e.g. IFSC for HDFC Credit Cards is HDFC0000128 and ICIC0000103 is IFSC for ICICI Credit Cards). So you can push funds to a credit card if you have the 16 digits of the card (just a heads up… it is not that simple also to pass the 16 digit card numbers due to stringent PCI-DSS compliance)

Commercials:

Let us start with the premise that there will be charges and typically these are flat fees (i.e. fixed amount irrespective of ticket size). Charges are deducted in two ways (a) upfront debit (b) invoicing

Let me explain both the methods with examples where the merchant has to disburse Rs.1000 and the payout charge is Rs.10 and GST is 18%

a. Upfront debit: Charges are deducted when the payout is done. E.g. Using the above example, total Rs.1011.80 (Rs.1K + Charges + GST) from the source account

b. Invoicing: Charges are invoiced to the merchant. E.g. Using above example, Rs.1000 disbursed to beneficiary and merchant is invoiced Rs.11.80

We got the basics in place.. now, let’s talk about efficiency

Illustration D

Payout is dependent on multiple entities (as shown in above illustration) and each entity is a potential failure point. Processing bank(s) may go down, or even NPCI and at times, destination bank(s) may go offline. This is apart from aggregator and merchant’s own systems that could go blank. Below are some of the points that need to considered when we talk about the ‘efficiency’ of a payout system.

1. Availability

Payments (whether collection or payout) should work each time and all the time. If payouts are critical, then availability becomes super crucial. If any of the entities involved goes offline, then payouts are stalled.

2. Load capacity

Again, every entity has its own load processing capacity and depends on infrastructure and also, liquidity with clearing houses. Load handling capacity is crucial as there is a huge difference between processing 10,000 payouts in a day Vs. in an hour.

3. Reconciliation

There will be reversals and pending cases and it is important for the service provider (bank or aggregator) to reconcile those cases so merchant can initiate appropriate actions.

4. Success rate

Similar to PG, even here, success rate is an important performance indicator. There are few steps that can be taken to improve the success rate.

• Adding more banks to do payout, so dependency on a single bank is lowered
• Retrying and queuing of payout instructions
• Validating beneficiary’s instrument details (e.g. validating bank account, beneficiary name and UPI ID/VPA) before initiating payout to those instruments

Note: Bank account validation is a solution where token amount (Rs.1 or more) is transferred to the beneficiary’s bank account to check the validity of that account including beneficiary name as per bank records. Similarly merchant can validate a UPI ID before initiating the payout to that UPI ID

There are merchants who receive money from users and then do payouts to vendors or partners. Also, there are merchants who disburse the money first and then start the collections… Irrespective of the direction, the funds keep moving in and out, and this movement should be seamless and efficient, else it will impact business.

With more & more payout use cases coming up and merchants wanting to achieve higher efficiency & scalability, ‘Payout Solutions’ will become as important as the ‘PG solutions’.