48. Settlement — Faster
In Chapters 5 & 6, I covered the Settlement Time and Settlement Amount. As per the standard process, a merchant receives the settlement on T+1 or T+2 working days. But what if the merchant wants settlement earlier than that? Or may be on a bank holiday?
Before we get into more details… why does the merchant want an early settlement? Ans: For fulfilment of financial obligations — a hyperlocal merchant wants to make payments to its vendors, a gaming merchant wants to disburse winnings to its users while an NBFC will use those funds to issue more loans.
Definitely, a merchant can use its own funds to complete these obligations but a merchant may not have that kind of liquid funds and also, there is opportunity cost involved in using its own funds.
The problem with payment gateway settlement
Just because a transaction is successful in real-time, doesn’t mean the payment aggregator will receive the funds immediately. Banks, wallets or other payment service providers take different time to give settlement to the payment aggregator which in turn will take time to give settlement to the merchant.
If you are completely risk averse, then better to wait till you receive funds from your banking partners and then do the settlement to the merchants.
How to address this requirement?
This seems like a deadlock — merchants want funds earlier but banks won’t give it faster. In that case the solution is that the payment aggregator can settle the funds to the merchant in advance and then recover it from the merchant’s settlement amount.
Below are the details related to early / instant / faster settlement
A. Settlement Type:
Merchant wants early settlement but that definition can vary a lot… It can be
- Period: Every 1 hour or 6 hour
- On-demand: Only when needed (e.g. only on bank holidays)
B. Fund Source:
The Payment Aggregator needs to pre-fund these early settlements. Payment Aggregator has two options… (a) use own funds — But can it do that considering a payment aggregator is not a licensed lender (b) Use borrowed funds from an NBFC/Bank and repay it back.
Option (a) is neither clean nor scalable, so no need to bother with that but option (b) is clean, interesting and scalable.
C. Underwriting:
As you realised, early settlement is nothing but unsecured lending. But who is the borrower in this model? Payment aggregator or the merchant?
- Usually the aggregator will be the borrower on the file — NBFC/Bank will issue the loan to the aggregator who in turn use it for pre-funding for early settlement
- Although merchant is not the direct borrower, NBFC/Bank may put restrictions in terms on merchant categories (e.g. gaming not allowed) or put a limit per merchant.
D. Commercial Model:
The NBFC/Bank will have interest charges that may vary from 12–18% per year (or 0.032%-0.049% per day). The payment aggregator will recover it from the merchant and by adding some margin, the aggregator will make profit.
With Example: Let’s say two transactions of Rs.10,000 each done using credit card and debit card. PG charges for CC is 1.80% and DC is 0.90%. The merchant is availing early settlement at 0.10% charges.
Let’s make it complex:
Above calculation looks simple but it is not. Let us assume a merchant is availing early settlement at 0.10% and the aggregator’s borrowing rate is 0.05%. Let’s assume the transaction is done on Friday and assume Saturday & Sunday are bank holidays. The merchant receives the settlement on Friday. But the aggregator can recover that amount only on Monday when banks do the settlement.
In above case, aggregator will charge merchant Rs.10 but NBFC will charge merchant Rs.15 for the same amount. So the charges for such early settlement cannot be linear and at the same time, you cannot show complex calculation to the merchant.
A simpler way to avoid any revenue leakage would be having differential pricing on working and non-working days.
Let’s make it more faster / Efficient:
Why does the merchant want funds faster… because the merchant has financial obligations to fulfil (e.g. paying to vendors or disbursing funds to the winners). So the received funds will be pushed out…thus, a merchant can simply connect the settlement to a payout account (source account for the payout/disbursement solution) and disburse the funds.
Conclusion:
I wrote about the payment aggregator’s revenue model in Article 19. These revenue models keep changing or evolving. Example: Reverse plough from banks is not followed since 1st Jan 2020 after GOI revised rates for RuPay debit cards and UPI.
But there is a new revenue stream i.e. early settlement charges.
Payment aggregation business is more or less a commodity… payment aggregators hardly make any profit (if they make at all). Additional services such as early settlement can improve the ‘top line’ and also, there is ample opportunity to make good margins on early settlement fees.
Remember, early settlement has value because banks struggle with inefficiencies and limitations in terms of fund movement but things may improve. For example: now we have 24x7 NEFT and RTGS to move funds. So, in the near future, banks may find a way to settle funds to aggregators/merchants faster. If that happens, the early settlement will lose its value. But surely, it will take time…
Meanwhile, as they say “make hay while the sun shines”.
