Every bank and NBFC in India runs a regulatory-returns workshop the last week of every month. Six to ten people pull data from four to six systems, reconcile in Excel, classify by hand, and stitch together the IRACP return that’s due to RBI by the 7th of the next month. Then they do it again for PSL Form A quarterly. Then DSB daily. Then OSS-3 quarterly.
This is the most-automatable workflow in lending operations, and most institutions are still doing it manually.
This post is for operations, compliance, and credit-ops teams that are tired of the cycle — and for the technology teams trying to fix it.
The four returns that consume your operations team
IRACP (Income Recognition, Asset Classification, and Provisioning) — monthly. Asset classification per RBI’s Master Direction (Standard / SMA-0/1/2 / Sub-Standard / Doubtful / Loss), provisioning at UCB rates, secured/unsecured cuts, by product, by geography. Submitted to RBI by 7th of the following month.
PSL Form A — quarterly. Priority Sector Lending achievement: micro, small, agricultural, weaker-sections, total. Submitted to RBI by quarter-end + 30 days.
DSB / Form B — daily. Statement of banking advances by category, used for RBI’s daily liquidity monitoring. Submitted by next-day.
OSS-3 — quarterly. Off-site supervision statement of advances. Granular sector cuts (more than PSL), geography rollup (RBI 4-tier: rural / semi-urban / urban / metro), large-exposure flagging at ₹5 Cr threshold, QoQ growth.
The data source for all four is the same: your loan book. The classification logic is the same: RBI Master Directions. The output formats are RBI-prescribed.
In a well-designed platform, these returns are generated in seconds. In most institutions today, they’re assembled over person-days.
Why the manual approach persists
Three patterns explain why so many institutions are still doing this manually.
Pattern 1: Multi-system data fragmentation
The loan data lives in 6+ systems: legacy LOS, current LOS, LMS, CBS, KYC, recovery, restructuring. Each system has its own snapshot logic, its own day-count, its own classification rules. Stitching them together for a single return requires:
- Daily snapshots from each system.
- Matching keys (account number, customer ID) that don’t always agree across systems.
- Reconciliation of duplicates and missing rows.
- Manual classification overrides for special cases.
The team that owns the IRACP return spends 80% of its time on data plumbing and 20% on classification. The plumbing never gets automated because the systems are owned by different vendors and replacing one is too expensive.
Pattern 2: Classification logic encoded in operations memory
The classification rules in the Master Directions look simple. In practice they have edge cases:
- A loan is 89 DPD on month-end. SMA-2 or Sub-Standard? Depends on the day-count convention.
- A restructured loan: when does the higher provisioning kick in? When does it taper?
- A gold loan with LTV breach: does asset classification change before or after the margin-call cure period?
- A co-lending loan: is the classification the bank’s or the partner’s?
In most institutions, these edge cases live in the operations team’s shared memory. The classification gets done correctly because the same person has been doing it for 8 years. When that person leaves, the next person re-discovers each edge case the hard way — usually after an RBI inspection finding.
Pattern 3: Output format mechanics
RBI prescribes output formats precisely. IRACP wants a specific Excel template with specific columns in specific orders. PSL Form A wants another. DSB wants yet another. OSS-3 wants a fourth.
In most institutions, a power-user maintains the Excel templates. Every quarter, RBI updates a column. The power-user updates the template. The historical comparability of the data fragments. The audit trail of “what we sent in Q3 vs Q4” is unclear.
What the automated pattern looks like
A modern lending platform — CortexData being our reference, but the pattern generalises — solves this with three principles:
Principle 1: Source-of-truth data, single system
All loans live in the LMS. Origination feeds in (from LOS or import); collections feed in (from channels); restructuring + write-off + recovery happen in the LMS. The IRACP classifier reads from the LMS directly, daily, on every loan. There’s no “which system has the latest balance” question.
If your LMS doesn’t cover all loans (because legacy products are still in a parallel system), the path forward is migration — not hand-stitching.
Principle 2: Classification logic encoded as code, versioned
The IRACP classifier is a pure function: classifyAsset(loan, asOfDate, productClass) → AssetCategory. The rules are encoded once, regression-tested per edge case, version-controlled. RBI updates a rule? You change one function, run the regression suite, deploy. Every loan reclassifies overnight.
The same applies to PSL classification: classifyPSL(loan, customer, product) → PSLCategory. Pure. Testable. Versioned.
Principle 3: Returns generated, not assembled
The IRACP return generator is another pure function: generateIRACPReturn(loanBook, asOfMonth, locale) → DocumentBytes. Inputs are the LMS state and the month-end. Output is the regulator-ready document. Run it on the 1st of the month — return is ready. Run it on the 7th — same answer (idempotent, because the pure function depends only on its inputs, and the LMS state at month-end is fixed).
The platform generates EN/KN/HI versions in parallel. It produces the customer-acknowledged copy of any disclosure within the return. It hashes the document and stores it in the audit chain.
What changes for operations teams
The IRACP team that took 6 person-days per month becomes a 1 person-hour review per month. The 5 saved person-days redirect to:
- Edge-case investigation: when the classifier flags an unusual loan, an analyst investigates the loan, not the classification.
- Trend analysis: month-over-month NPA migration, by product, by geography.
- Underwriting feedback: which segments are migrating to NPA at 90 DPD? Feed it back to the credit committee.
This is the difference between operations as cost-centre and operations as insight-centre.
The migration path
For institutions that don’t have an automated pipeline today, the migration path is concrete:
- Identify your source-of-truth book: which system has every active loan? If two systems have overlap, reconcile and decide on a single owner. Migrate the rest.
- Encode classification rules: implement IRACP, PSL, DSB, OSS-3 as pure functions. Build a regression suite from your historical returns (every loan’s historical classification becomes a test case).
- Build the return generator: takes the source-of-truth + as-of-date + locale → produces RBI-format document.
- Parallel-run for 3 months: generate the new way alongside the manual way. Reconcile differences. Investigate the differences (usually the manual way had edge-case errors). Once aligned, retire the manual process.
- Monitor: dashboard tracking month-over-month NPA migration, PSL achievement, DSB liquidity bands.
Most institutions can complete this migration in 2-4 months once they have the right platform. CortexData ships steps 2-4 as default; step 1 is the customer’s data-migration exercise.
How CortexData operationalises this
CortexData LMS ships all four return generators as default behaviour. The platform’s test suite includes RBI-format regression cases. New banks deploying CortexData have their first month-end IRACP return generated automatically, in seconds, on their first month of operation.
If you’re running a regulatory-returns workshop the last week of every month — and you’d like to retire that workshop — request a demo. We’ll show you the return generation on a working environment with sample data shaped like yours.