What Payment Aggregators Don’t Cover: The Recurring Collections Gap In Your Payments Stack

Most fintech lenders and NBFCs in India have their payments stack figured out, or think they do. A payment aggregator handles the inbound flows. The collections team handles the follow-up. Somewhere in between, a meaningful portion of monthly EMI value quietly falls through the gap, and nobody has clearly owned that space long enough to fix it.

The problem is not that these platforms are built badly. It is that they are built for something different. Understanding that distinction is where most collections conversations need to start.

What a Payment Aggregator Is Actually Designed to Do

A payment aggregator sits between merchants and the banking network, routing customer-initiated transactions through the appropriate payment rail, whether that is UPI, cards, netbanking, or wallets. The model works elegantly for one-time or customer-triggered payments. A borrower opens an app, taps pay, and the platform processes the transaction.

That is precisely the use case it optimises for. Speed of checkout, transaction success rates on customer-initiated flows, settlement timelines, and reconciliation. These are the metrics a payment aggregator is built around, and on those parameters most established platforms perform well.

Loan collection sits outside that design entirely. The borrower is not initiating the payment. The lender is. And the payment aggregator limitations that follow from that distinction- mandate management, pre-debit notifications, retry logic on failed debits, escalation paths when automation does not resolve the account- are not what most platforms provide at the depth regulated lenders actually need.

Where the Gap Becomes Visible in Practice

The gap becomes clear the moment a borrower misses an EMI.

The platform processes the failed transaction and returns a status code. What it typically does not do is trigger a structured follow-up sequence, log the interaction in a format auditable under RBI’s Digital Lending Guidelines, or route the delinquent account into a prioritised workflow based on DPD bucket and risk profile.

That absence is not a flaw. It is a scope boundary. The platform processed what it was asked to process. What happens next sits outside its remit.

For a lender collecting from tens of thousands of borrowers every month, that boundary has measurable consequences. Failed debits that do not trigger automated follow-up within the early delinquency window, typically the first seven to fourteen days, age into the next bucket. Each additional week of unresolved early-bucket delinquency reduces settlement probability and increases recovery cost.

The Mandate Management Problem That Gets Left Behind

Recurring collection at scale requires mandate infrastructure, not just transaction processing. These are related but distinct capabilities, and the distinction matters for any lender running UPI Autopay or eNACH as a collections instrument.

Most payment aggregators support mandate registration as part of their feature set. What most do not provide is the operational layer on top of mandate execution: monitoring mandate health across a live portfolio, identifying mandates approaching expiry before they lapse, and handling the workflow when a bank rejects a debit with a return code suggesting a retriable failure versus one signalling the mandate needs re-registration.

That distinction between retriable and structural failures, handled correctly, is worth real money in a portfolio of meaningful size. Ignored, it becomes a delinquent account with an unnecessary DPD count attached. These limitations are not always visible until a lender is operating at volume and edge cases start compounding into something material.

What the Orchestration Gap Actually Costs

The recurring collections gap is not about the payment rail itself. UPI Autopay and eNACH are robust instruments. The gap is in the orchestration layer that turns a successful mandate registration into a functioning, auditable, self-correcting collection programme.

That layer needs to route failed collections by failure type rather than status code alone, generate pre-debit notifications with logged delivery confirmation, maintain the audit trail co-lending partners and rating agencies ask for, and flag mandate anomalies early enough for intervention rather than discovery after the fact.

The platform processes the transaction at the point of execution. The orchestration work happens before and after that point. Recognising that boundary is not a criticism of the platform. It is a prerequisite for building a collections operation that actually performs at scale.

Conclusion

The question for any NBFC or fintech lender reviewing its collections infrastructure is not whether its payment aggregator is performing. It is whether the infrastructure around it is doing the work that turns processed transactions into a predictable, compliant, and genuinely optimised collections programme.

The limitations are not a reason to abandon the platforms you have. They are a reason to be honest about where those platforms stop and where the collections problem actually begins. Lenders who have closed that gap consistently recover more, spend less on follow-up, and carry the audit documentation their compliance obligations require.