An onboarding error that is caught by the QC AI is a problem solved. An onboarding error that appears in 18% of files every month, gets caught, gets corrected, and reappears in 18% of next month's files is a process design problem that catching has not solved. The Onboarding Quality Agent AI's error register is not just a quality management tool — it is a product improvement signal. Each error type, when traced back to its origin in the onboarding journey, points to a specific step that can be changed: a document request that did not specify the required date range, a form field that accepted any text rather than validating the input, a training module that did not cover the error type, a system that allowed NACH details to be entered manually. The feedback loop converts the error register into a product and process improvement roadmap.
An onboarding error that is caught by the QC AI is a problem solved. An onboarding error that appears in 18% of files every month, gets caught, gets corrected, and reappears in 18% of next month's files is a process design problem that catching has not solved. The Onboarding Quality Agent AI's error register is not just a quality management tool — it is a product improvement signal. Each error type, when traced back to its origin in the onboarding journey, points to a specific step that can be changed: a document request that did not specify the required date range, a form field that accepted any text rather than validating the input, a training module that did not cover the error type, a system that allowed NACH details to be entered manually. The feedback loop converts the error register into a product and process improvement roadmap.
The feedback loop: from error to root cause to fix
The error tagging system produces, at the end of each month, a ranked list of error types by frequency, by product, by branch, and by RM. The analysis that follows asks three questions for each top error: where in the onboarding journey does this error originate? who or what controls that step? and what change at that step would prevent the error from reaching the QC gate? The answers route fixes to the right team — a system change goes to the technology team, a training gap goes to the training programme, a process gap goes to operations, a communication gap goes to the onboarding UX team. Not every error has a single clean fix, but the top 5 errors are almost always fixable with a targeted change that reduces their frequency significantly within 60 days of implementation.
"The error register is a to-do list for the product team. Every error in the top 5 that has been in the top 5 for 3 consecutive months is a product design failure that has not been fixed."
The feedback dashboard: top-5 error improvements from QC-to-journey fixes
Rejection Reason Feedback — October 2025 → November 2025 Cycle
5 feedback loops initiated from Oct error data · 3 implemented · Impact visible in Nov error rate
23.8%Oct error rate
21.5%Nov error rate
−2.3ppImprovement (1 month)
3 of 5Fixes implemented
Loop 1 · Bank statement gap (ERR-INCOME-BST-GAP)
→ Onboarding UX / Multilingual AI
Root cause: the digital onboarding flow requested "12 months of bank statements" without specifying the required date range. Borrowers submitted 12 PDFs that covered 12 months in name but not in a contiguous 12-month window. Fix implemented October 28: the document request screen now says "Bank statements from [auto-calculated: November 2024] to [October 2025] — all months must be included. Missing months will cause a resubmission request." The date range is auto-calculated from the application date. Borrowers see the specific months required, not a generic "12 months" instruction.
Result: Bank statement gap errors: 24.1% (Oct) → 18.4% (Nov) · −5.7pp in one month · Further improvement expected as fix propagates
Loop 2 · NACH mismatch (ERR-LOAN-NACH-MISMATCH)
→ Technology / System change
Root cause: NACH mandate form allowed manual entry of bank account number and IFSC code by the RM — entered from borrower-spoken information during a client meeting. No cross-validation against the bank account details in the submitted bank statements. Fix implemented November 5: NACH bank details are now auto-populated from the Account Aggregator-linked bank account (the same account from which bank statements were pulled), with manual override disabled. RMs can see the pre-populated details but cannot change them without a supervisor approval that triggers a QC flag.
Result: NACH mismatch errors: 16.8% (Oct) → 12.1% (Nov) · −4.7pp · First-EMI bounce rate on November disbursements: down 34% vs October cohort
Loop 3 · KFS date compliance (ERR-LOAN-KFS-DATE)
→ Technology / System block
Root cause: the LOS allowed a sanction letter to be generated on any date, without checking whether the KFS had been issued and acknowledged before the sanction date. In some cases, RMs issued the sanction letter and the KFS simultaneously — or the KFS was generated first but the acknowledgement was captured later. Fix implemented November 10: the sanction letter generation button in the LOS is blocked until the KFS acknowledgement record shows a date prior to the sanction request date. No system workaround is possible — the sanction cannot be processed until the KFS pre-dates it.
Result: KFS date errors: 14.2% (Oct) → 10.4% (Nov) · −3.8pp · System block is a permanent fix — error rate expected to approach 0% as all legacy cases clear
Loop 4 · EC expiry (ERR-PROP-EC-EXPIRED) — fix pending
→ Operations / Process change
Root cause: Encumbrance certificates obtained at application become stale (older than 6 months) for applications that take more than 4 months to reach sanction — typically LAP and HL applications with complex title chains. No current trigger in the LOS alerts the operations team when an EC is approaching expiry relative to the expected sanction date. Fix designed but not yet implemented: a system trigger that fires when the application age exceeds 4 months with an EC on file, prompting a fresh EC request. Implementation target: December 15.
Result: Not yet implemented · EC expiry error rate stable at 14.2% · Expected improvement post-Dec 15: −6 to −8pp
Loop 5 · GSTIN filing gap (ERR-INCOME-GSTIN-GAP) — training fix pending
→ Training / RM education
Root cause: RMs check whether the borrower's GSTIN is active (registered and valid) but do not check whether all quarterly returns are filed and up to date. A GSTIN can be active with a gap quarter — the check the RM performs passes, the check the QC AI runs fails. Fix designed: add a GSTN filing status check (not just registration status check) to the RM pre-submission checklist for MSME applications, with a screenshot requirement as evidence. Training module update: December credit policy module to include GSTIN filing gap check procedure. Implementation: December 1 training update.
Result: Not yet implemented · GSTIN gap error rate at 9.8% · Expected improvement post-training: −4pp within 60 days
The feedback loop routing: which team owns each error type
| Error type | Root cause category | Feedback routes to | Fix type | Typical time to fix |
|---|
| Bank statement gap (date not specified) | Onboarding UX / instruction clarity | Product team + Multilingual AI (update document request screen) | UI change: auto-calculated date range displayed | 2–3 weeks |
| NACH bank details mismatch | System design (manual data entry allowed) | Technology team (disable manual NACH entry) | System: auto-populate from AA, manual disabled | 2–4 weeks |
| KFS dated on or after sanction date | System allows out-of-sequence actions | Technology team (add system block) | System: sanction blocked until KFS pre-dated acknowledgement | 2–3 weeks |
| EC expired at sanction | Process: no expiry trigger in LOS | Operations team + Technology (add LOS trigger) | Process trigger: 4-month application age → EC refresh request | 4–6 weeks |
| GSTIN filing gap not checked by RM | Training gap: RM checks registration, not returns | Training programme (update RM checklist module) | Training + checklist update: add GSTN filing status check | 4–6 weeks (next training cycle) |
| Photo mismatch (document vs selfie) | Fraud signal / detection gap | Fraud monitoring team (enhanced check, not a fix) | Enhanced due diligence trigger + face re-verification | Immediate (already triggered) |
| Bureau consent dated after bureau pull | Process sequence issue: bureau pulled before consent | Technology team (system block — bureau pull requires consent record) | System: bureau API call blocked until consent record timestamp confirmed | 3–4 weeks |
−2.3ppError rate improvement in 1 month — Oct 23.8% → Nov 21.5% · From 3 fixes implemented in October · 2 more fixes pending
−4.7ppNACH mismatch improvement — Loop 2 fix (auto-populate from AA) · First-EMI bounce rate down 34% on November disbursement cohort
3 of 5Fixes implemented this cycle — 2 pending (EC trigger and GSTIN training) · Expected −7–9pp additional improvement over next 2 months
Dec 15EC trigger implementation target — will eliminate the second most common error type · Expected −6–8pp in that error category post-implementation
The error register that drives product changes is the error register that eventually makes itself unnecessary
The Onboarding Quality Agent AI's goal is not to permanently employ itself as a QC gate for the same 15 errors, month after month. It is to catch errors, feed back the patterns, drive fixes, and progressively reduce the error rate until the onboarding process is genuinely robust — at which point the QC gate still runs 100% of files (because new error types appear with regulatory changes and product additions) but the error rate is low enough that the human QC team's time is spent on the genuinely novel cases rather than the preventable recurring ones. The October-to-November improvement of 2.3pp from 3 targeted fixes is not impressive as an absolute number. It is the first month of a continuous improvement cycle where each month's fixes reduce the next month's error rate, compounding over 12 months into an onboarding process that fails far less frequently than the one the institution started with. The QC AI is the feedback mechanism that makes the onboarding process smarter over time — and the improvement compounds, because the fixed errors do not come back.
