What co-lending actually requires from your tech stack

Co-lending is easy to pitch and hard to run. The pitch is clean: a bank brings cheap capital, an NBFC brings origination and last-mile reach, and a regulator-blessed sharing arrangement splits the loan between two balance sheets. The reality is that you are now operating one loan across two institutions, two ledgers, two risk appetites, and two sets of regulatory obligations — in near real time, for the life of the asset.

Most stacks were built to originate and service loans the lender owns outright. Co-lending breaks that assumption at the data layer. If you have not modelled the split as a first-class concept, you will end up bolting reconciliation onto a system that quietly assumes single ownership — and that is where co-lending arrangements rot.

The data model is the whole game

In a co-lending arrangement, a single borrower-facing loan is two economic interests stitched together. Your data model has to represent that natively, not as an afterthought.

Concretely, every loan needs to carry:

• The sharing ratio — and the fact that it can differ by product, by tranche, even by drawdown. A blanket 80:20 stored as a config flag will not survive contact with reality.
• Per-partner economics — the blended rate the borrower sees versus the rate each partner earns, plus the fee split, the spread, and any guarantee or first-loss arrangement.
• Independent accounting per interest — interest accrual, principal outstanding, DPD, and provisioning calculated separately for each partner, because each carries the asset on its own books under its own norms.
• Ownership at the cashflow level, not the loan level — when a borrower pays ₹10,000, that single inflow has to fan out into principal, interest, fees, and penalties, then split each component by the applicable ratio, then route each slice to the right partner.

If your schema treats a loan as one owner with one schedule, none of this is expressible without ugly workarounds. The arrangement should be modelled where the loan lives — alongside the borrower, the product, and the schedule — so that every downstream calculation inherits the split automatically.

Reconciliation is daily, two-sided, and unforgiving

The hard part is not booking the loan. It is keeping two institutions agreeing about it every single day.

A co-lending stack has to reconcile at least three things continuously:

1. Disbursement. When the loan goes out, each partner's share has to be funded and recorded on each partner's CBS. A disbursement that posts on the NBFC's books but lags on the bank's side is a break that compounds.
2. Collections. Every repayment has to be apportioned and settled to each partner, with a clear audit trail from the borrower's single payment to the two resulting positions. Partial payments, prepayments, and bounced instruments all need deterministic apportionment rules.
3. Position. At any point, both partners must be able to assert the same outstanding, the same DPD, and the same provisioning — and reconcile their internal CBS against the shared view.

Where most stacks fall short is here: they can originate a co-lent loan but cannot prove, on demand and at scale, that both ledgers agree. Reconciliation gets handled in spreadsheets between operations teams, breaks accumulate, and the arrangement becomes a monthly fire-drill rather than a daily settled truth.

Compliance can't be a wrapper

The regulator does not see a "co-lending feature." It sees two regulated entities each reporting on their share of an asset. That means the returns each partner files have to be generated from the same underlying ledger that drives settlement — not reassembled afterwards from exports.

This is the same argument we have made about lending infrastructure generally: compliance can't be a wrapper around a lending platform. For co-lending it is sharper, because the regulatory view is split too. If the RBI returns are not built from the split-aware data model, you are manually rebuilding the apportionment a second time for reporting — and now you have two sources of truth that disagree.

Where this lands

This is precisely why CortexData ships Co-Lending as one of five composable modules rather than a feature bolted onto origination — and why every RBI return is built into the platform from the start. Co-lending sits on the same stack that handles origination, management, and securitisation, so the split is expressed once, in the data model, and inherited everywhere: in collections, in settlement, and in every return each partner files.

The test for any co-lending stack is simple. Pick one borrower repayment and trace it, end to end, into two reconciled partner positions and two correct regulatory returns — without a spreadsheet in the middle. If you can't, you don't have a co-lending stack. You have an origination system with a co-lending problem.

If you are building or operating in this space, we'd welcome the conversation — get in touch, or read more of our thinking on regulated rails.