RBI Co-Lending Model: A Practical Implementation Guide for Banks and NBFCs

Co-lending is the most-misunderstood RBI framework in retail lending. The press release version sounds simple: a bank and an NBFC share a loan, the bank gets PSL credit, the NBFC gets cheaper funding, the customer gets faster service. The implementation reality involves three reconciliation problems, two compliance traps, and one operational pattern that decides whether your programme scales or stalls.

This post is the implementation guide we wish existed when we built CortexData Co-Lending. If you’re an NBFC product head, a bank CRO, or a credit-ops VP standing up your first (or fifth) co-lending programme, here’s what actually matters.

What the Master Direction actually says

The RBI Master Direction on Co-Lending by Banks and NBFCs to Priority Sector (November 5, 2020) governs the framework. The headline rules:

• Two REs are involved: a scheduled commercial bank and an NBFC. Either can be originator; the other is the partner.
• Joint underwriting is mandatory: both REs apply their own credit appraisal before sanction.
• 80:20 split is typical (80% bank, 20% NBFC), but the ratio is configurable per programme.
• Single customer interface: from the customer’s perspective, the loan is from the originator only. Back-end book-splitting is invisible.
• Settlement and reconciliation between bank and NBFC is mandatory at the agreed cadence.
• Customer grievance routes through the originator, but partner satisfaction obligations apply.
• Each RE reports its own portion for IRACP, PSL, and exposure norms.

What the Master Direction doesn’t prescribe — and where most implementations stumble — is the operational mechanics. Let’s walk through them.

Operational mechanic 1: Joint underwriting without throughput collapse

Joint underwriting is a hard requirement. Both REs must independently appraise the loan. Done naively, this means every application goes through two separate underwriting workflows — and your throughput halves while your decision-time doubles.

The right pattern is a parallel-with-shared-context workflow:

1. Originator captures the application + KYC + documents.
2. Originator runs its scorecard / underwriting + makes a preliminary call.
3. Originator-call goes to partner, with all underlying data shared under valid consent.
4. Partner runs its scorecard / underwriting + applies its credit policy.
5. Both REs must arrive at “approve” for the loan to proceed. Either rejection terminates the application.

In production, this means:

• A consent-aware data-sharing layer (the customer consented to the originator; the partner needs explicit consent for KYC re-use).
• Two independent decisioning workflows operating on a shared application object — neither overrides the other.
• A latency budget: most programmes target 24-48 hours from application to joint-decision. A poorly-built workflow stretches this to a week.
• Per-side rejection visibility — when partner rejects an originator-approved application, the originator’s underwriter sees why (broad bucket, not partner’s proprietary scorecard internals).

CortexData treats joint underwriting as a first-class workflow primitive, not as “two separate UIs in two separate systems”.

Operational mechanic 2: Escrow disbursement and the “both REs ready” gate

This is where most programmes leak operational risk. Funds need to flow:

1. Bank pre-funds its share of the principal into an escrow.
2. NBFC pre-funds its share of the principal into the same escrow.
3. Disbursement gate fires only when both REs have funded and the customer is ready to receive.
4. Disbursement: customer’s account credited from escrow.
5. Reversal-on-failure: any operational failure rolls back atomically.

What kills programmes here is one-sided escrow — bank funds first, NBFC takes 24 hours to fund, customer is told the loan is approved but the money doesn’t arrive. Customer complaint to Banking Ombudsman. Programme audit. Painful.

The platform mechanic that fixes this:

• A single escrow account per programme (not per loan), with daily netting.
• Dual-fund-arrival gate before disbursement attempt.
• Atomic disbursement across the originator-customer + partner-escrow movements.
• Reversal on any sub-step failure, with both REs notified.

Operational mechanic 3: Single customer interface — and what it actually means

RBI is firm: the customer sees one brand. This means more than “use the originator’s logo”:

• Sanction letter is from the originator only. The partner’s 20% interest is back-end book-only — not in the customer document.
• EMI deduction comes from a single mandate to the originator’s account.
• Statement of account shows the originator as creditor, full balance.
• Grievance routes to the originator’s contact. Internally, originator escalates to partner if needed.
• Closure / NOC is signed by the originator, single document.

The back-end book-split is a system-of-record concern only. The platform must split every event (disbursement, EMI receipt, fee booking, write-off, recovery) atomically and report to each side correctly — but the customer must never see the split.

Mistakes we’ve seen:

• Sanction letter mentions both REs. Customer complains they didn’t apply to the NBFC.
• EMI invoice shows two debits (one to originator, one to partner). Confused, the customer disputes both.
• Statement of account shows partial-balance from the originator’s perspective. Customer is told the balance is X but the actual liability is X + partner-share.

Each is a Banking Ombudsman case waiting to happen. The platform has to enforce single-customer-interface as an invariant, not as a UI choice.

Operational mechanic 4: Daily settlement and the reconciliation problem

This is the operational gravity well of co-lending. Every day:

• Customer pays X to the originator’s collection account.
• Originator’s LMS books X.
• Originator’s settlement engine splits X into 80% (own) + 20% (partner).
• 20% needs to flow to the partner’s account on the agreed window (T+0, T+1, T+2).
• Partner’s LMS receives the split, books it.
• Both sides reconcile their LMS book against the channel feed and the settlement transfer.

The cardinality is unforgiving. A programme doing 5,000 EMIs/day produces 10,000 reconciliation lines (originator + partner sides). At 20% mis-mapping rate (which is common in immature programmes), that’s 2,000 daily exceptions. No team can manually clear that.

The platform needs:

• Atomic split-and-transfer at the moment of EMI receipt.
• Per-channel adapters (NACH, UPI, IMPS, branch cash) that produce reconciliation-friendly identifiers.
• A bidirectional reconciliation engine that compares originator’s LMS, channel feed, settlement transfer, and partner’s LMS — and surfaces only the differences.
• An exception queue with categorised buckets: AMOUNT_MISMATCH, MISSING_AT_PARTNER, MISSING_AT_ORIGINATOR, DUPLICATE.

Compliance trap 1: Per-side PSL achievement tracking

The bank gets PSL credit for its 80%. The NBFC may have its own PSL targets (under the NBFC PSL framework). Both sides must independently track PSL achievement on their portion of the book.

This means:

• PSL classification at sanction (per RBI’s Master Circular on PSL) flows through to both sides’ books.
• Each side’s PSL Form A return reports its own portion.
• If reclassification happens (e.g. customer ceases to qualify as MSME), both sides reclassify in lockstep.

A common error: bank reclassifies, NBFC’s book still shows the loan as PSL. Audit catches it. Penalty.

Compliance trap 2: Exposure norms applied per-side

Bank’s exposure cap (single borrower, group exposure) applies to its 80%. NBFC’s exposure cap applies to its 20%. Some programmes mistakenly aggregate, others miss the per-side check entirely.

The platform needs to enforce both checks independently at sanction time, with clear messaging when one side hits a cap and the other doesn’t.

What “programme launch in 3 weeks” actually requires

Banks and NBFCs that have CortexData typically stand up a new co-lending programme in 2-3 weeks because the platform mechanics above are pre-built. What needs to happen in those 3 weeks:

• Week 1: Programme parameters defined (split ratio, settlement window, partner KYC, escrow account opening, single-customer brand). Joint underwriting policies agreed.
• Week 2: Configuration in CortexData (programme registry, partner credentials, channel adapters tested). UAT with sample applications.
• Week 3: Pilot with 5-10 live applications. Reconciliation runs for 5 business days. Production rollout.

Without the platform mechanics in place, the same programme launch takes 3-6 months because each operational primitive is bespoke.

How CortexData operationalises this

CortexData Co-Lending implements every mechanic in this post — joint underwriting, escrow disbursement, single customer interface, daily settlement reconciliation, per-side PSL tracking, per-side exposure caps — as the platform’s default behaviour. New programmes are configurations, not builds.

If you’re standing up your first co-lending programme — or your fifth, and you’re tired of the reconciliation pain — request a demo. We’ll walk through a live programme on the platform.