Domain: BFSI · Retail Lending · Digital Process Transformation | Role: Business Analyst / APM | Year: 2026
G Yasaswini | yashaswini2519@gmail.com | linkedin.com/in/g-yasaswini
A regional bank's retail loan processing workflow runs entirely on manual interventions — manual KYC verification, batch credit bureau checks, and multi-level approval chains. The result: an average processing time of 8.4 days, with 47% of applications breaching the 8-day SLA. Customers wait nearly two weeks for decisions that should take hours. Operations teams are buried in repetitive verification tasks that add no credit judgment value.
| Objective | Current State | Target |
|---|---|---|
| Average processing time | 8.4 days | ≤ 5 days |
| SLA breach rate | 47% | < 10% |
| Applications auto-approved (low-risk) | 0% | 60% |
| Redundant approval layers | 2-level for all loans | 1-level for low-risk |
The BRD defines the business targets. This section defines how those targets will be tracked after go-live — the instrumentation, data sources, and review cadence.
| Metric | Baseline | BRD Target | Stretch (TO-BE) | Source |
|---|---|---|---|---|
| Average processing time | 8.4 days | ≤ 5 days | ~4 hours | Loan origination system timestamps |
| SLA breach rate | 47% | < 10% | — | FR-12: per-application time tracking |
| Auto-approval rate | 0% | ≥ 60% | — | Risk segmentation engine output |
| KYC completion rate | Manual (days) | ≥ 95% within 5 min | — | DigiLocker API response logs |
| Data entry error rate | 15% | < 2% | — | Application rework loop count |
| Customer drop-off rate | Unknown | Establish baseline | — | Funnel analytics from application portal |
Leading indicators (visible within the first 2 weeks of go-live):
- DigiLocker API success rate — if below 90%, KYC automation is not delivering
- CIBIL real-time fetch success rate — if below 90%, TAT reduction is blocked at Step 3
- Application funnel completion rate — are customers finishing the online form?
Lagging indicators (visible at 30/60/90 days):
- Average processing time — the headline metric; takes time to accumulate sample
- SLA breach rate — needs 2–3 weeks of data to calculate reliably
- Customer satisfaction (CSAT) — post-disbursement survey
| Review | Frequency | Audience | Action Trigger |
|---|---|---|---|
| API health check | Daily (automated alert) | Operations team | Alert if API success rate < 90% |
| SLA breach rate | Weekly | Branch management | Review if breach rate > 15% |
| Full metric dashboard | Monthly | Business leadership | Formal review vs BRD targets |
| Post-launch retrospective | 90 days post go-live | All stakeholders | Confirm targets met or revise |
Note on the 94% TAT claim: The BRD commits to ≤ 5 days (conservative target). The TO-BE process design projects ~4 hours for eligible auto-approval cases. Both are valid — the BRD target is the committed SLA; the TO-BE figure is the optimised-path estimate for 60% of applications. Track both separately in the post-launch dashboard.
| Stage | As-Is (Manual) | To-Be (Digital) | Time Saved |
|---|---|---|---|
| Application submission | Branch visit required (30–60 min) | Online 24/7 via DigiLocker (10 min) | ~50 min |
| Document verification | Back-office manual check (24–48 hrs) | API + AI validation (2 min) | ~47 hrs |
| Credit check | Manual CIBIL request batch (12–24 hrs) | Real-time bureau API (5 min) | ~23 hrs |
| Risk assessment | Officer manual review — all apps (24–48 hrs) | Rules engine: 60% auto-routed, 40% manual | ~36 hrs avg |
| Approval | Multi-level email/phone (24–48 hrs) | Single-level for low-risk; dual for high-risk | ~47 hrs |
| Customer notification | Manual call/email (12–24 hrs) | Automated SMS + email (< 1 min) | ~23 hrs |
Time reduction breakdown: Document verification alone accounted for 24–48 hours of the 8.4-day average — the single largest bottleneck. Removing it via API drops the base TAT by 28–57%. Adding real-time credit checks (saves ~23 hrs) and routing 60% of applications to auto-approval eliminates the remaining backlog drivers. For the 60% of applications classified as low-risk: TAT drops from 5–7 days to ~4 hours (96% reduction). For the remaining 40% that require manual review: TAT drops from 5–7 days to ~1 day (80% reduction). Weighted average improvement: ~90% reduction in processing time across all applications.
| Artifact | Description |
|---|---|
| BRD v1.0 | Business requirements — problem statement, objectives, stakeholders, scope, risks, success criteria |
| FRD v1.0 | 15 functional requirements (FR-1 to FR-15) across KYC, credit integration, risk segmentation, approval workflow, SLA monitoring, and reporting |
| Non-functional requirements | 4 NFRs — response time ≤ 3s, 99% uptime, data privacy compliance, RBAC |
| AS-IS process flow | 7-step manual workflow with per-step timing and identified bottlenecks |
| TO-BE process flow | 6-step digital workflow with automation touchpoints and routing logic |
| JIRA backlog | User stories and tasks organized across 2 sprints |
| Confluence documentation | Project documentation hub — BRD, FRD, process flows |
| User stories | 12 stories across 5 epics with acceptance criteria and story points |
Why risk segmentation instead of blanket automation? Automating all approvals creates unacceptable credit risk exposure. Segmenting by risk preserves human oversight for high-risk cases while eliminating the backlog for low-risk ones — directly targeting the 47% SLA breach rate without changing credit policy.
Why API-based KYC (DigiLocker + Aadhaar)? Manual document verification is the single largest time sink (24–48 hrs). API validation reduces this to 2 minutes, eliminates the 15% data-entry error rate, and is RBI-compliant under digital lending guidelines.
Why restructure the approval chain? The dual-approval layer (Branch Manager + Regional Manager) adds 24–48 hours to every application regardless of risk. Segmenting by risk ensures the Regional Manager's time goes only to decisions that genuinely require senior judgment.
KYC Automation (FR-1 to FR-3) The system shall validate customer identity via API within 5 minutes of submission, flag incomplete documents for applicant correction, and maintain a full audit log of all verification attempts.
Risk Segmentation Engine (FR-6 to FR-8) Applications classified as Low / Medium / High risk using predefined scoring thresholds. Low-risk → automated approval. High-risk → manual review queue with full context for the analyst.
SLA Monitoring (FR-12 to FR-13) The system shall track per-application processing time and trigger escalation alerts when SLA thresholds are at risk of breach — not after the breach has already occurred.
| NFR | Requirement |
|---|---|
| NFR-1 | System response time ≤ 3 seconds for all API validations |
| NFR-2 | 99% system uptime during business hours |
| NFR-3 | All customer data compliant with data privacy regulations |
| NFR-4 | Role-based access control enforced for all approval actions |
Operations Team · Risk Management · Branch Manager · Regional Manager · IT Development · Compliance & Audit · Business Leadership
| Tool / Method | Usage |
|---|---|
| JIRA | Sprint planning, backlog, user story tracking (2 sprints) |
| Confluence | Project documentation hub |
| Process flow diagramming | AS-IS bottleneck analysis, TO-BE automation mapping |
| Requirements documentation | BRD v1.0 + FRD v1.0 following standard BA/PM formats |
digital-loan-transformation/
│
├── README.md
├── Documents/
│ ├── BRD_Digital_Loan_Transformation.pdf
│ ├── FRD_Digital_Loan_Transformation.pdf
│ ├── AS-IS_Process_Flow.pdf
│ └── TO-BE_Process_Flow.pdf
├── process_flow/
│ └── flowchart.png
├── Screenshots/
│ ├── JIRA_Backlog.png
│ ├── JIRA_Sprint1.png
│ ├── JIRA_Sprint2.png
│ └── Confluence_Documentation.png
└── user_stories.md
This project demonstrates BA and PM competencies: process analysis, BRD/FRD documentation, sprint planning, stakeholder communication, data-backed transformation rationale, and requirements elicitation — applicable to BA, APM, and product analyst roles in BFSI and fintech.