The 15-Day Booking Window Is Four Events, Not One

Under the RBI Co-Lending Directions 2025, the partner RE's share must be booked within 15 calendar days. But a 'booking' the regulator will accept is four separate events that must each land inside the window — and the one that slips is almost never the one your dashboard watches.

Co-LendingAssureLocker Team·7 min read
Published: 21 July 2026

What the Directions actually require

The RBI (Co-Lending Arrangements) Directions, 2025 — effective for new arrangements from 1 January 2026 — require the partner RE's share of each loan to be taken onto its books within 15 calendar days of the qualifying event, backed by an irrevocable commitment given before disbursement. Calendar days, not working days: the clock runs through weekends, holidays and batch windows.

On expiry, the consequence is structural, not procedural: the loan stays wholly on the originating RE's books and can thereafter move only under the Transfer of Loan Exposures framework — it exits co-lending treatment entirely. It cannot be force-fed to the partner late. For an NBFC that originated expecting a bank to fund 80%, a failed window is a balance-sheet event, and the funding carry is real: at a 10% annual cost of funds, carrying ₹100 crore for the full 15 days costs roughly ₹41 lakh.

“Booked” is four events

Here is the operational trap. Between the borrower receiving money and the partner's auditors seeing an asset, four distinct things happen — usually in four different systems:

  1. Disbursement — the originating RE releases funds to the borrower. This starts the clock.
  2. Partner acceptance — the partner RE accepts its share. In most stacks this is an API acknowledgement inside co-lending middleware.
  3. Reimbursement — cash actually moves to the originating RE through the escrow account.
  4. GL posting — the partner's core ledger recognises the asset. This is the book the regulator and the statutory auditor read.

A window test that watches only one timestamp — usually the middleware acceptance — will happily show green while the booking fails. The canonical failure mode looks like this: the loan disburses on day 1, the middleware ACK lands on day 2, cash reimburses on day 13 — and the GL posting slides to day 17 through a weekend batch run. Every message in the integration looked on-time. The booking, in the sense that matters at inspection, was late.

The evidence question

The uncomfortable audit question is not “was it booked in time?” but “show me.” Showing it needs all four timestamps, from their respective sources, tied to the same loan — the disbursement record, the acceptance event, the escrow credit, and the GL posting reference. In practice these live in an LOS, a middleware platform, a bank statement and a core banking extract, keyed by different identifiers.

Three evidence rules make the test honest:

  • A missing point is not a passing point.If the window has expired and a GL posting was never evidenced, the verdict is a failure — an unevidenced booking is not a booking. While the window is still open, missing points are “awaiting”, not green.
  • Sequence matters. A GL posting timestamped before the cash moved, or a reimbursement before the acceptance, is not early — it is evidence that the timestamps were backfilled or mis-mapped, and the record cannot be trusted as booked.
  • The commitment must pre-date the disbursement. The 2025 regime is ex-ante: the partner commits first, then the loan disburses. A commitment recorded after disbursement fails regardless of how fast the booking followed.

What good looks like operationally

Pairs that run this well treat the window as an ageing pipeline, not a month-end report: every disbursed loan carries its four-point status; anything missing a point at day 10 is on an exception queue with an owner; anything late is a finding that cannot be quietly dismissed — it can only be remediated, with the trail preserved. The test runs daily, because a clock measured in calendar days does not pause for your batch schedule.

This is the discipline AssureCLA's four-point booking control applies — independently recomputed from each side's evidence, with the paragraph citation attached, and with “unknown” honestly reported as unknown rather than averaged into green. The REs keep the book, the pricing and the decision; the control plane keeps the proof.

Continue reading

See AssureLocker in action

Book a 30-minute live walkthrough tailored to your lending use case.

Book a demo →
AssureLocker
Right Vectors India
3rd floor, Innov8, SKCL Tech Square,
SIDCO Industrial Estate, Guindy,
Chennai, TN 600032

AssureLocker is a verification & orchestration platform — not a lender. It supplies verified evidence and risk signals checked against authoritative sources (GSTN, MCA21, EPFO, CERSAI, Account Aggregator) and orchestrates the assessment room. It does not lend, hold or move funds, operate escrow, set advance rates, or make the credit decision — the lender's system of record makes that decision and disburses. Right Vectors India, the provider of AssureLocker, operates strictly as a Technology Service Provider. Every signal is labelled by evidence tier — registry-verified, lender-side, issuer-confirmed, document-signed or self-declared (missing where unresolved); some integrations are in sandbox, lender-side or pilot, and records are written to an immutable registry (hashes only — never raw PII). Signals and figures are point-in-time and consent-bound; confidential to the named parties.

Explainable, evidence-tiered signals — auditable on request. Our algorithmic-accountability approach →

© 2026 Right Vectors India. All rights reserved. · Site version: al-20260721-155225-34ff216c8

Aligned with India Stack. Made in India.