Loan System vs General Ledger: Data Reconciliation and EWS Failure
The DFI runs its ₹68,000 crore loan book on a core lending system, but project monitoring is done in Excel. A reconciliation shows that 14 of 230 projects have different outstanding balances between the loan management system and the general ledger, with a net difference of ₹340 crore; six differences exceed ₹20 crore. The last full reconciliation was 45 days ago, and the interface log shows three failed batch jobs that were not escalated. The DSCR dashboard uses static monthly uploads, and its data owner is the business team. The early-warning system did not flag three accounts that became SMA-2 last quarter, although their DSRA was fully drawn and their milestone reports were 60 days late. The CRO wants a two-week remediation plan and a permanent data-governance model.
1. Triage the issue. What should be fixed in the first 48 hours, what in the first two weeks, and what should wait?
Read the worked answer
First 48 hours: freeze the DSCR dashboard and label it 'unreconciled'; stop any decisions based on it. Isolate the three failed interface jobs, rerun them in a controlled environment, and reconcile the six exposures above ₹20 crore line by line to the general ledger. Confirm whether the ₹340 crore is a timing difference, a mapping error, or a real unrecorded transaction. Escalate to the CRO and CFO; do not book manual adjustments without maker-checker approval.
First two weeks: reconcile all 14 projects, document root causes, assign data owners, and produce a signed-off exception report. The long-term fix - master data management, automated reconciliation, and a new EWS - should not be rushed into the two-week window. The priority is to restore a trustworthy number for risk reporting and regulatory returns, not to build a new dashboard on top of bad data.
2. Design the permanent data-governance model: ownership, golden source, reconciliation cadence, controls and KPIs.
Read the worked answer
Data governance needs clear ownership and controls. Create a single project master with a unique project ID used by the loan system, GL, and project monitoring. Define the golden source for each data element: outstanding balance from the GL, repayment schedule from the loan system, milestone status from the project monitoring unit. Assign a business data owner and a data steward, with IT accountable for interfaces and audit logs.
Reconcile daily for balances and monthly for exposure; any break above a threshold should create a ticket and be escalated. Data quality KPIs: percentage of projects reconciled, unresolved breaks, failed interfaces, ageing of exceptions, and late milestone updates. The business team can own the data definition, but it should not be able to upload static DSCR files without validation. Add a change-control process for repayment schedules, and require audit trail for manual overrides. This is a BCBS 239-style principle: risk data must be accurate, complete, and timely, with clear ownership.
3. Redesign the early-warning system so that the three SMA-2 accounts would have been flagged earlier. Specify indicators, thresholds, escalation and validation.
Read the worked answer
Design the EWS around leading indicators, not just overdue interest. Candidate indicators: DSRA utilization above 50%, milestone delay greater than 30 days, DSCR headroom below 10%, off-taker payment delay above 45 days, sponsor leverage above 4x, and sector watch-list flags.
Set thresholds at green/amber/red, with an owner and escalation path for each. The three SMA-2 accounts would likely have triggered on DSRA drawdown and 60-day milestone delay before the payment default. Use a combination of rules and a scorecard; avoid too many alerts. Validate the EWS on historical data to measure false positives and false negatives. Require data lineage from the source system to the dashboard, and a monthly review by the risk committee. The EWS should generate an action - covenant check, site visit, independent engineer review - not just a colour on a screen.