NPA classification is an engineering problem, not a reporting one.

Every NBFC engineering team has lived through this conversation. The compliance officer asks for the NPA dashboard at 10:00 AM. The dashboard shows X. The collections head's mid-day review shows X+12. The CFO's GL provisioning shows X-7. Three numbers, three sources of truth, all derived from the same loan book.

The cause is architectural. NPA is computed once, in a batch job, written to a reporting table, and then everyone, collections, GL, comms, pricing, reads stale snapshots that drift independently. The fix is not a better dashboard. It's making NPA a first-class event with downstream consumers subscribed in real time.

Why batch NPA breaks the platform

NPA is not a slow-moving classification. A loan that crosses 90 DPD overnight changes provisioning, collections priority, customer treatment, and pricing eligibility, all within hours. A nightly batch loses that window every single day.

• Collections work tomorrow's plan from yesterday's bucket transitions
• GL provisioning accrues against last-week's classifications
• Customer-facing comms still treat the borrower as standard while collections has flagged them
• Restructuring eligibility decisions ride on stale data
• Pricing on top-up loans references outdated risk classification

What "NPA as a first-class event" looks like

Every EMI event, payment, partial payment, bounce, restructuring, emits an NPA-evaluation trigger. The classifier runs on every relevant trigger. Every state change (Standard → SMA-1 → SMA-2 → NPA → Sub-standard → Doubtful → Loss) emits a domain event with timestamp, before/after, and evidence.

Downstream consumers subscribe to NPA events the way they'd subscribe to any first-class platform signal. Collections subscribes for bucket re-allocation. GL subscribes for provisioning recomputation. Comms subscribes for customer treatment. Pricing subscribes for top-up eligibility. None of them poll for NPA snapshots, they react to events.

IRAC alignment is implementation, not aspiration

IRAC norms specify Standard / Sub-standard / Doubtful / Loss with DPD thresholds. The classification logic is mechanical, but the evidence trail is what passes audit. Every classification event must capture: timestamp, EMI/payment events that triggered re-evaluation, days-past-due at evaluation, prior class, new class, classifier version.

When RBI inspects, the question is not "is this loan NPA?", it's "why was this loan classified NPA on this date?" An event-sourced LMS answers that in seconds. A batch-job LMS reconstructs the answer through engineering archaeology.

Real-time provisioning

When an NPA event fires, GL provisioning recalculates within minutes, not at month-end. Your CFO sees the same provisioning number as the regulator's view. The board pack uses live numbers, not last-month's snapshot.

The downstream effect is that period-close becomes an event-completion check, not a reconciliation marathon. Period close on T+1 is achievable when GL has been live throughout the period.

How to migrate without disrupting servicing

1. Build the new event-sourced LMS NPA module alongside the legacy batch classifier
2. Run both in parallel for one full month, diff outputs daily
3. When divergence is zero across all bucket transitions, switch downstream consumers to the new event stream one at a time (collections first, then GL, then comms, then pricing)
4. Keep the batch classifier alive as a sanity check for one more month
5. Decommission the batch classifier once parity is verified across two full close cycles

When this matters most

If your NBFC is over ₹500Cr AUM, the case for event-driven NPA is unambiguous. Below that, the case for migrating depends on collections sophistication and GL parity tolerance. Above ₹1,000Cr, batch NPA is operationally indefensible, your collections platform is making allocation decisions on stale data that's costing you recovery rates.