Credit Path Advisor
A borrower-facing eligibility and guidance layer inside MoneyView’s active-loan experience. It tells active borrowers whether they are eligible for a responsible top-up, what amount range is possible, what is blocking them, and what next action improves eligibility.
1. Goals, Non-Goals, Decision Principles
This PRD is for a discovery-to-application guidance layer, not a new lending product. The feature should improve clarity and responsible conversion while preserving MoneyView's existing underwriting and lender-policy controls.
| Category | Definition | How we validate it |
|---|---|---|
| Goal | Help active borrowers understand their current top-up path without starting a blind application. | Advisor open rate, calculator usage, reduced support contacts, reduced failed top-up attempts. |
| Goal | Expose safe reason codes and next-best actions for eligible, near-eligible, and blocked states. | Comprehension survey, CX deflection, fewer repeat inquiries for the same borrower state. |
| Goal | Increase responsible repeat-credit conversion without degrading portfolio quality. | Top-up completion lift with default, DTI, and early stress metrics inside guardrails. |
| Non-goal | Change underwriting policy, promise guaranteed approval, or override risk/lender constraints. | All UI copy uses "may be eligible" and final-check disclaimers; final decision remains with underwriting. |
| Non-goal | Build a full restructuring/foreclosure product in V1. | V1 only routes users into the existing top-up/application journey after advisor review. |
| Principle | Every state must answer three questions: Am I eligible? Why? What should I do next? | No product state ships without status, reason, and next action copy. |
2. Problem Statement
Active MoneyView borrowers who may be good candidates for additional credit cannot clearly see if, when, or why they are eligible for a top-up while their current loan is active. The result is blind re-application, avoidable support dependency, borrower frustration, and switching to other lenders before MoneyView can present a safe next-credit path.
PM question
How might MoneyView show active borrowers their next eligible credit path before they apply and fail?
| Problem area | Current user experience | Product consequence |
|---|---|---|
| Eligibility opacity | User does not know whether an active loan blocks another credit request. | Repeat borrower applies blindly or contacts support. |
| No reason codes | User sees rejection or no offer without a clear path forward. | Trust drops because the system feels arbitrary. |
| No EMI impact preview | User cannot understand affordability before starting an application. | Riskier applications enter the funnel and support burden increases. |
| Late offer timing | Eligible users discover options after already searching elsewhere. | MoneyView loses high-quality repeat borrowers to competing lenders. |
3. Target Users
The first launch should focus on borrowers where the product problem is clarity rather than basic credit quality. Riskier cohorts can be supported later through stricter milestone messaging and smaller offer ranges.
| User cohort | Eligibility posture | Need | Advisor value |
|---|---|---|---|
| Strong active borrower | On-time EMIs, stable income, healthy bureau score, low DTI | Needs additional funds without a confusing second-loan attempt. | Show amount range, reason codes, EMI impact, and review CTA. |
| Near-eligible borrower | Good repayment but one missing proof, DTI issue, or policy hold | Needs to know what action unlocks eligibility. | Show blocker, milestone, and next eligible date or action. |
| Not-yet-eligible borrower | Insufficient repayment history, risk flags, or unstable income signal | Needs transparent guidance without feeling rejected permanently. | Show safe explanation and future improvement path, not offer CTA. |
| Support-contact borrower | User has already asked about second loan or top-up eligibility | Needs consistent answer across app and CX. | Expose same reason codes to support console. |
4. User Journey
The highest-friction moment happens before application submission: the borrower needs credit but does not know whether MoneyView can support them responsibly. The advisor should intervene before the user searches externally or hits a generic rejection.
| Stage | User action | Emotion | Current pain | Advisor intervention | Success signal |
|---|---|---|---|---|---|
| Awareness | Rajesh needs extra funds for urgent medical expenses while his first loan is active. | Anxious | Does not know if another loan is possible before repayment completion. | Active-loan dashboard shows "Check your next credit path" card. | User opens advisor instead of starting a blind application. |
| Consideration | Checks app, website, and support options for second-loan rules. | Uncertain | Information is policy-heavy and not personalized to his repayment behavior. | Advisor explains status using repayment, bureau, income, and DTI signals. | User understands whether he is eligible, near eligible, or blocked. |
| Decision | Compares top-up amount and EMI affordability. | Cautious | Without EMI impact, user may over-apply or abandon due to fear of hidden cost. | Calculator shows current EMI, estimated new EMI, monthly delta, and DTI movement. | User adjusts amount/tenure before application start. |
| Application | Starts top-up application only after understanding conditions. | Confident | Current journey can feel like a rejection funnel. | CTA routes only eligible users into application; blocked users get next-best action. | Higher application quality and fewer avoidable rejects. |
| Support | Contacts support if the reason is unclear or urgent. | Impatient | CX may answer generically without seeing the same decision context. | CX console shows latest advisor state, reason codes, and session history. | First-contact resolution improves; conflicting answers reduce. |
| Post-decision | Tracks future eligibility if not yet eligible. | Hopeful | Blocked users do not know when to return. | Advisor shows next milestone and refresh date. | User returns after milestone instead of switching lender. |
5. Solution Ideas Considered
The teardown evaluated multiple directions. Credit Path Advisor is selected because it solves the clarity gap first, fits existing loan infrastructure, and can be piloted without changing core risk policy.
| Idea | Type | Why considered | Tradeoff | Decision |
|---|---|---|---|---|
| Static second-loan policy page | Low effort | Easy to ship and reduces generic confusion. | Not personalized; still makes user interpret policy themselves. | Reject for V1 core, keep as support content. |
| Support-led eligibility guidance | Operational | Useful for urgent users and escalations. | Scales poorly and creates manual dependency. | Support as secondary surface only. |
| Pre-approved top-up card | Conversion | Directly drives application starts for eligible users. | Does not help near-eligible or blocked users understand why. | Include as eligible state inside Advisor. |
| Second-loan eligibility calculator | Utility | Helps users understand EMI and DTI impact. | Needs eligibility context before calculations are meaningful. | Include after advisor state. |
| Credit Path Advisor | Decision layer | Combines eligibility, reason codes, calculator, and next-best action. | Requires cross-functional alignment with risk, CX, and analytics. | Selected for V1. |
| Dynamic credit marketplace | Moonshot | Could route users to partner lenders dynamically. | High compliance, partner, and operational complexity. | Future bet after advisor proves demand. |
6. Product Scope
In Scope
- Advisor card on active-loan dashboard.
- Real-time eligibility state: eligible, near-eligible, not eligible, retry.
- Reason-code explanation for borrower and CX teams.
- Top-up amount range and offer validity where user is eligible.
- EMI and DTI impact simulator before application.
- Next-best-action guidance for blocked users.
- Event tracking for every step in the advisor journey.
Out of Scope for V1
- Changing core underwriting policy or lender risk appetite.
- Guaranteeing final approval before required final checks.
- Dynamic marketplace across all NBFC partners.
- Full loan restructuring or foreclosure/rebooking logic as the primary product.
- Pricing optimization or interest-rate negotiation.
- Support-agent manual override of risk decisions.
7. User Experience
The advisor should feel like a native part of the active-loan dashboard, not a marketing banner. The product promise is clarity: every user should know the current state, the reason, and the next responsible action.
| Step | Surface | User sees | Primary action |
|---|---|---|---|
| 1 | Active-loan home | “Top-up path available” or “Improve eligibility” card below current loan summary. | Review eligibility |
| 2 | Advisor details | Status, amount range, reason codes, valid-through date, and guardrail summary. | Calculate EMI impact |
| 3 | Calculator | Top-up amount slider, tenure selector, EMI delta, DTI movement, affordability label. | Review offer or reduce amount |
| 4 | Offer review | Final amount, fees, tenure impact, expiry, consent copy, and final-check disclaimer. | Proceed to application |
| 5 | Blocked state | Reason code, blocker explanation, next milestone, and support-safe language. | Track milestone or update proof |
8. Functional Requirements
| ID | Requirement | Acceptance criteria | Priority |
|---|---|---|---|
| FR-01 | Show advisor entry point only to users with an active personal loan. | Card appears on active-loan dashboard; hidden for no-loan users and closed-loan-only users. | P0 |
| FR-02 | Classify borrower into eligible, near-eligible, not-eligible, or retry state. | State is returned with reason code, confidence, timestamp, and expiry. | P0 |
| FR-03 | Display explainable reason codes. | User and CX see aligned reason labels such as REP_12_ON_TIME, DTI_HIGH, INCOME_PROOF_PENDING. | P0 |
| FR-04 | Show top-up amount range and validity for eligible users. | Amount range never exceeds risk engine output; validity date is visible. | P0 |
| FR-05 | Calculate EMI and DTI impact before application. | User sees current EMI, estimated new EMI, monthly delta, DTI movement, and risk label. | P0 |
| FR-06 | Give next-best action for blocked users. | Every blocked state has one clear action: repay next EMI, update income proof, wait until date, or contact support. | P1 |
| FR-07 | Log advisor journey events with session continuity. | Card view, open, calculator edit, offer review, support tap, and application start have session_id. | P0 |
| FR-08 | Provide CX-readable decision context. | Support console can retrieve latest advisor state and reason codes without manual risk override. | P1 |
| FR-09 | Suppress advisor offer when decision data is stale. | If key signal freshness exceeds configured SLA, show retry state instead of amount range. | P0 |
| FR-10 | Persist the last viewed advisor state for continuity. | User returning within validity window sees same state with refreshed timestamp and clear expiry. | P1 |
| FR-11 | Allow near-eligible users to set milestone reminders. | Reminder is available for next EMI, income proof update, or eligibility refresh date. | P2 |
| FR-12 | Provide lender-policy safe copy. | Messages explain constraints without exposing sensitive underwriting thresholds or blaming partners. | P0 |
9. System Design
Credit Path Advisor is a decision and explanation layer. It should not own final underwriting. It consumes risk, bureau, repayment, income, and policy signals, then surfaces a user-safe interpretation.
Repayment History
Signal Aggregator
Eligibility Service
Reason-Code Mapper
Advisor UI + CX Context
| Layer | Responsibility | Inputs | Outputs |
|---|---|---|---|
| Signal aggregator | Collects borrower and active-loan signals. | EMI history, outstanding principal, bureau score, income stability, DTI, lender policy flags. | Normalized signal object with freshness timestamp. |
| Eligibility service | Classifies current advisor state. | Signal object, risk thresholds, product policy, partner constraints. | State, amount range, reason codes, expiry, final-check flag. |
| Reason-code mapper | Converts risk/policy logic into borrower-safe language. | Raw rule hits, policy outcomes, model flags. | Customer copy, CX copy, next-best-action mapping. |
| Advisor frontend | Shows status, calculator, offer preview, or blocked-state guidance. | Eligibility API response and event session ID. | Advisor interaction events and application-start CTA. |
10. Data, API, and Analytics Requirements
The advisor needs trustworthy, fresh, auditable decision data. The system should separate raw underwriting signals from borrower-safe explanations so product clarity does not leak sensitive policy logic.
| Object / Event | Required fields | Owner | Notes |
|---|---|---|---|
| advisor_eligibility_response | user_id, active_loan_id, state, reason_codes, amount_min, amount_max, expiry_at, signal_freshness_at | Eligibility service | Amount fields are nullable for blocked and retry states. |
| advisor_reason_code | code, customer_copy, cx_copy, next_best_action, severity, expose_to_user | Risk + Product | Raw rule IDs should not be shown directly to users. |
| advisor_session | session_id, user_id, source_surface, created_at, last_state, application_started | Analytics platform | Session ties together card view, calculator, support, and application start. |
| advisor_card_viewed | session_id, user_id, state, source_surface, card_rank, app_version | Frontend analytics | Needed to calculate true activation funnel. |
| advisor_calculator_changed | session_id, amount_selected, tenure_selected, estimated_emi, dti_after, risk_label | Frontend analytics | Used to understand responsible amount selection behavior. |
| advisor_application_started | session_id, offer_range, selected_amount, selected_tenure, reason_codes, final_check_required | Loan funnel analytics | Must join with final approval, disbursal, and portfolio performance. |
11. Product States + Edge Cases
| State | User-facing message | System condition | Fallback |
|---|---|---|---|
| Eligible now | You may be eligible for a top-up of up to X. | Repayment, DTI, income, bureau, and lender policy all pass. | Show calculator and offer review CTA. |
| Near eligible | You are close. Complete this action to improve eligibility. | One fixable blocker such as income proof or next EMI pending. | Show milestone and reminder option. |
| Not yet eligible | Top-up is not available right now. | Risk, repayment, policy, or bureau constraint blocks offer. | Explain reason safely and suppress application CTA. |
| Retry | We could not check eligibility right now. | Signal freshness issue, API timeout, bureau downtime, or service error. | Retry, log failure, and avoid showing stale amount. |
| Support review | We need to verify your details before showing an offer. | Mismatch or risk flag requires manual review. | Create CX context with session_id and latest reason codes. |
12. QA and Acceptance Test Matrix
| Scenario | Setup | Expected behavior | Severity if broken |
|---|---|---|---|
| Eligible borrower opens advisor | 12 on-time EMIs, healthy bureau, DTI below threshold, valid lender flag. | Eligible state appears with amount range, expiry, reason codes, calculator CTA. | P0 |
| Near-eligible borrower has one blocker | Good repayment but missing income proof. | No offer CTA; show proof update action and refresh expectation. | P0 |
| Risk-blocked borrower | High DTI or risk flag. | Show safe explanation and suppress top-up amount. | P0 |
| Signal API timeout | Repayment or bureau signal unavailable. | Retry state appears; no stale amount or misleading eligibility copy. | P0 |
| Calculator amount exceeds guardrail | User drags amount beyond safe DTI range. | Risk label changes and CTA asks user to reduce amount/extend tenure. | P1 |
| CX opens same user context | User contacts support after advisor visit. | CX sees latest state, reason codes, session ID, and next-best action. | P1 |
13. Success Metrics
North Star Metric
Responsible top-up path completion rate
Percentage of eligible active borrowers who view the advisor, understand their path, complete a responsible top-up application, and remain inside portfolio risk guardrails.
| Metric group | Metric | Target / guardrail | Why it matters |
|---|---|---|---|
| Activation | Advisor card open rate | 30%+ among eligible / near-eligible users | Measures whether users notice and trust the entry point. |
| Clarity | Reason-code comprehension | Support contacts per advisor viewer down 20% | Validates that the advisor reduces confusion, not just clicks. |
| Conversion | Calculator to application start | 15-25% for eligible cohort | Shows whether users can evaluate EMI impact and proceed. |
| Risk | Top-up cohort default guardrail | Default rate not above approved risk band | Prevents growth from becoming unsafe credit expansion. |
| Operational | Eligibility API error rate | <0.5% critical failures | Ensures the advisor does not create more support burden. |
| Business | Repeat borrower retention | Lift vs control cohort | Measures whether the feature keeps good borrowers in ecosystem. |
14. Rollout Plan
| Phase | Duration | Scope | Exit criteria |
|---|---|---|---|
| Design + Risk Alignment | 2 weeks | Reason-code taxonomy, copy, user states, risk thresholds, CX language. | Approved state model and guardrails. |
| Service Build | 4 weeks | Signal aggregator, eligibility API, reason mapper, event schema. | API contract stable and validated with test cohorts. |
| Frontend Build | 3 weeks | Advisor card, detail screen, calculator, blocked states, support link. | All states render correctly on supported app versions. |
| Internal UAT | 1 week | Positive, blocked, retry, stale-signal, CX context, analytics tests. | No P0 journey, event, or risk-state defects. |
| Pilot | 2 weeks | 5-10% of low-risk active borrowers. | Support tickets stable, error rate below threshold, no risk guardrail breach. |
| Scale | Phased | Expand by lender, cohort, app version, and risk band. | Retention lift and portfolio quality remain positive. |
15. GTM and Operational Readiness
This launch should be positioned as a helpful eligibility guidance feature, not as a guaranteed credit offer. GTM should avoid over- promising and should prepare CX to answer the same way the product explains the state.
| Workstream | Deliverable | Owner | Readiness check |
|---|---|---|---|
| In-app launch | Dashboard entry point, tooltip copy, blocked-state copy, calculator copy. | Product + Design | Copy approved by Risk, Legal, CX. |
| Notifications | Only for eligible and near-eligible users with safe wording. | Growth | No notification uses guaranteed approval language. |
| CX enablement | Reason-code playbook, escalation SOP, support console training. | CX Ops | Agents can explain top 10 states without engineering help. |
| Risk monitoring | Daily cohort report on approval quality, DTI movement, early stress. | Risk Analytics | Pilot cannot expand without guardrail sign-off. |
| Experimentation | Holdout cohort for active borrowers not exposed to advisor. | Product Analytics | Retention, support, conversion, and risk metrics compare against control. |
16. Risks + Open Questions
Risks
- Users may interpret advisor amount as guaranteed approval.
- Stale bureau or income data can create incorrect eligibility states.
- Reason codes may expose too much underwriting logic if not mapped carefully.
- CX may still give generic answers if support tooling is not aligned.
- Growth pressure can push top-up offers beyond risk guardrails.
Open Questions
- What minimum EMI count should unlock the first advisor state?
- Which reason codes can be safely exposed to borrowers?
- Should near-eligible users receive push reminders or only in-app guidance?
- What is the correct cooldown after a not-eligible state?
- How should lender-specific constraints appear without blaming partners?