# Lendly — Functional specification Version 1.0 · 01 November 2026 · India personal-loan MVP ## 1. Purpose and status Design an original mobile borrowing experience and a lender operations console for a single-partner personal-loan product. Moneyview is a category reference, not an affiliation, licensed asset or copied interface. Its public personal-loan page illustrates an online application and cost-disclosure journey; our proposed limits and rates are independent assumptions. [Reference: Moneyview](https://moneyview.in/personal-loan). This package is a medium-fidelity design handoff with offline simulations. It contains no backend, native application, real OTP, KYC, credit decision, signature, bank connection or payment capability. Do not enter actual personal information. State exists in browser memory and disappears on reload. The design-review rail can jump to any scenario; this is not a production permission model. ## 2. Proposed scope | Item | Proposed MVP decision | Owner before production | | --- | --- | --- | | Business model | Lendly is an LSP/DLA interface for one regulated lender | Business + lender | | Customer | Salaried adult residents meeting lender policy | Lender credit/compliance | | Channels | Android and iOS mobile app; desktop operations console | Product | | Language | English first; localization-ready | Product | | Loan | Unsecured, fixed installment, INR only | Lender | | Illustrative range | ₹25,000–₹3,00,000; 6, 12, 18 or 24 months | Lender; not an eligibility promise | | Example pricing | 18% annual reducing interest; 2% processing fee; illustrative 18% tax on fee | Lender + tax adviser | | Limit | One active application and one active loan per borrower for MVP | Lender | | Decision | Provider checks plus lender assessment; manual review available | Lender | | Money | Borrower and lender authorized accounts; no LSP wallet | Lender operations | Outside the first release: multiple-lender marketplace, self-employed underwriting, credit cards, BNPL, investments, insurance cross-sell, referral incentives, top-ups, co-lending, DLG arrangements and a new in-house core banking ledger. No approval-speed guarantee or preselected marketing consent. ## 3. Roles and responsibilities | Role | Responsibilities | Restrictions | | --- | --- | --- | | Borrower | Apply, consent, verify, review, sign, repay, raise complaints | Own records only | | Credit maker | Review lender-owned evidence and propose outcome | Cannot confirm own proposal | | Credit checker | Independently approve or return maker proposal | Distinct authenticated user; fresh evidence required | | Operations | Enquire transfers, reconcile receipts, manage authorized collections workflows | Cannot change credit decision or bank details casually | | Support | Investigate assigned tickets and route corrections | No unrestricted KYC document access | | Auditor | Inspect permitted evidence and audit history | Read-only | | Access administrator | Manage role requests through approved workflow | Cannot grant self elevated financial permissions | Prototype role switching simulates different roles in one page. Production must use separate identities, MFA and backend authorization. The sample dashboard is illustrative; only APP-1042, its amount/decision, repayment state and created ticket have linked interactions. ## 4. Screen inventory and production behavior | ID | Screen | Main action | Success / exception | | --- | --- | --- | --- | | M01 | Welcome | Start application | M02; disclose actual lender before application | | M02 | Mobile & OTP | Verify registered mobile | M03; wrong/expired code, cooldown and locked challenge | | M03 | Consent centre | Authorize purpose-specific assessment | M04; decline exits without application submission | | M04 | Your profile | Save identity, occupation, income, location | M05; validate age, name and serviceability server-side | | M05 | Choose your loan | Select amount and tenor | M06; outside policy range blocked | | M06 | Verify identity | Launch lender KYC provider | M07 or M19/manual review | | M07 | Verify income | Authorize supported provider or alternative | M08 or M19/manual review | | M08 | Bank account | Verify ownership and submit | M09; mismatched account needs correction | | M09 | Application tracker | View actual lender state | M10, M19 or M20; resume requested step | | M10 | Loan offer | Inspect lender, principal, APR, net proceeds and costs | M11; decline or M21 on expiry | | M11 | Key facts statement | Read and acknowledge versioned lender KFS | M12; missing acknowledgement blocks progression | | M12 | Agreement & mandate | Sign and authorize separately | M13 only after both server confirmations | | M13 | Transfer status | Track lender disbursement | M14 on settlement; unknown to operations, failure to recovery | | M14 | Loan home | Inspect balance, next EMI and documents | M15, M17, M18 or M22 | | M15 | Repayment schedule | Inspect lender-issued amortization | M16; documents available throughout loan life | | M16 | Pay installment | Initiate payment through lender route | Pending, confirmed, failed; receipt after confirmation | | M17 | Help & complaints | Create and track ticket | Reference, SLA and escalation route | | M18 | Privacy controls | Revoke optional use or request review/deletion | Purpose-specific response with retained-data explanation | | M19 | Action needed | Retry affected step or request manual review | Existing verified progress retained | | M20 | No offer available | Correct information or contact support | No promise of approval; policy-based future application | | M21 | Offer expired | Request new assessment/offer | Recheck consent; issue and acknowledge new KFS | | M22 | Cooling-off exit | Request valid exit quote | Pay exact lender quote; await confirmed closure | The M11 disclosure is deliberately simplified for wireframe review. It is not a substitute for the prescribed KFS, full amortization schedule or an executed loan agreement. M14 and M22 can be opened as separate settled-loan and immediate-post-disbursement scenarios; the prototype does not enforce real elapsed time. ### Admin workspaces | ID | Workspace | Production purpose | Prototype coverage | | --- | --- | --- | --- | | A01 | Dashboard | Intake, aging, collections and reconciliation visibility | Sample metrics and queue links | | A02 | Applications | Case evidence, requests, proposal and independent decision | Linked APP-1042; maker/checker guards | | A03 | Customers | Masked profile, consents, references and privacy requests | One sample profile | | A04 | Disbursements | Status enquiry, trace and reconciliation | Unknown-status enquiry; no payout control | | A05 | Repayments | Match receipts and detect duplicates | Sample confirmation updates mobile installment | | A06 | Collections | Assigned cases, borrower notice and contact history | Separate overdue sample and audit event | | A07 | Support | Complaints, investigation, escalation, resolution | Sample ticket creation and resolution event | | A08 | Policy & access | Versioned policy and role administration | Read-only proposed policy and role boundaries | | A09 | Audit log | Trace actor, event and evidence | In-memory simulated events | Production additions to each queue: server pagination, permitted search, assigned-user scope, date/status filters, meaningful empty/error states, permission-checked exports and case drill-down. These are specified, not fully implemented in the wireframe. ## 5. Functional flows ### Borrower happy path ```text M01 Start → M02 OTP → M03 Consent → M04 Profile → M05 Amount/tenor → M06 Identity → M07 Income → M08 Bank ownership → Submit → M09 Lender review → M10 Offer → M11 KFS acknowledgement → M12 Agreement + mandate → M13 Disbursement pending → confirmed settlement → M14 Active loan → M15 Schedule → M16 Payment pending → verified settlement → Receipt / balance update → final confirmed allocation → lender closure → closure document ``` Production prerequisite: an application may reach an offer only after the lender's required assessment gates pass. A confirmed admin decision does not itself disburse funds. The customer may abandon before signing; application withdrawal and post-signing cancellation use lender-specific rules. ### Credit review and exception flow ```text Submitted → Checks pending → Review queue ├─ Need information → borrower correction → recheck ├─ Provider issue → retry / manual review └─ Maker proposal → independent checker ├─ Return → maker ├─ Decline → M20 └─ Approve → versioned offer ``` Every decision retains policy version, evidence references, reasons and actor identity. Material borrower changes invalidate stale evidence and any unaccepted offer when required. New proposal versions invalidate earlier checker requests. The server rejects a self-approval even when the UI is bypassed. ### Funds and repayments ```text Accepted offer + verified KYC + bank + signature + mandate → lender payout request → submitted → pending / unknown ├─ confirmed failure → controlled retry └─ confirmed settlement → active loan Installment due → lender-authorized payment intent → pending → verified provider event + reconciliation → ledger allocation → borrower receipt → paid / partial / overdue according to ledger ``` An unknown transfer or payment is never automatically retried as a new financial instruction. A duplicate callback cannot create a second allocation. A reversal uses a compensating lender-ledger entry, not deletion. Manual matching requires authorized evidence and independent approval when value changes. ### Servicing, complaints and privacy Borrower request → ticket/reference → assigned owner → investigation → documented response → borrower acknowledgement or escalation. Complaints track receipt time separately from first response and resolution. Privacy requests have a separate purpose, legal-retention evaluation and completion record. Cooling-off exit uses an expiring lender quote, payment reconciliation and explicit closed confirmation. Foreclosure after that window follows the applicable lender product rules and is a separate implementation path. ## 6. State model | Aggregate | Allowed high-level states | Critical rule | | --- | --- | --- | | Application | DRAFT, SUBMITTED, CHECKS_PENDING, ACTION_REQUIRED, IN_REVIEW, APPROVED, DECLINED, WITHDRAWN | Terminal decisions require lender evidence; no client override | | Verification | NOT_STARTED, PENDING, VERIFIED, FAILED, MANUAL_REVIEW | Verification is per type and per evidence version | | Offer | ISSUED, ACCEPTED, EXPIRED, DECLINED, SUPERSEDED | Accept atomically only if valid and still current | | Signature | NOT_STARTED, PENDING, SIGNED, FAILED, EXPIRED | Browser redirect alone does not mean signed | | Mandate | NOT_STARTED, PENDING, ACTIVE, FAILED, REVOKED | Failed mandate blocks payout under proposed MVP policy | | Disbursement | CREATED, SUBMITTED, PENDING, UNKNOWN, SETTLED, FAILED, REVERSED | Only confirmed settlement activates servicing | | Loan | ACTIVE, OVERDUE, EXIT_REQUESTED, CLOSURE_PENDING, CLOSED | Closure requires lender confirmation and zero due under quote | | Payment | CREATED, PENDING, UNKNOWN, SETTLED, FAILED, REVERSED | Allocation only once per unique settlement | | Complaint | OPEN, ASSIGNED, WAITING, RESOLVED, ESCALATED, CLOSED | Escalation does not reset original receipt time | ## 7. Calculation example For planning only: principal P = ₹1,00,000, nominal annual rate 18%, monthly rate r = 0.18/12, n = 12. ```text EMI = P × r / (1 − (1+r)^(-n)) Fee = P × 2%; illustrative fee tax = fee × 18% Net proceeds = P − fee − tax Total installments = unrounded EMI × n Monthly cash-flow rate i solves: Net proceeds = Σ[EMI / (1+i)^k], k = 1..n Illustrative nominal annualized APR = 12 × i × 100 ``` Prototype uses equal monthly periods with the first installment one month after disbursement; APR is illustrative. Production must use the lender-approved KFS calculation, actual dates, complete included charges, rounding and tax treatment. Store paise and fixed decimal rates; do not use JavaScript floating point for ledger posting. The final installment absorbs agreed rounding adjustments. Displayed whole-rupee figures may differ slightly from exact totals. ## 8. Experience and accessibility requirements Use plain language and disclose the lender, costs and pending status at the decision point. Each control needs an accessible name; production targets WCAG 2.2 AA, keyboard support for admin, screen reader semantics, dynamic type, visible focus and 44px touch targets. Status uses text as well as color. Support back/resume without repeating completed checks, and announce errors near the relevant field. Do not clear borrower entries on provider failure. The design rail and simulation controls disappear from the native app. ## 9. Regulatory design checkpoints The following is a scoped reference summary, not a complete compliance assessment. Confirm current applicability with the lender before launch. RBI’s 2025 Digital Lending Directions address lender/LSP oversight, borrower disclosures, direct lender–borrower fund flows, grievance handling and purpose-specific consent. The design should provide a cooling-off exit, minimize LSP data storage, avoid access to contacts/call logs and use India-hosted data. The lender remains responsible for outsourced activity. Multi-lender matching has additional display requirements and is outside this MVP. [RBI Digital Lending Directions, 2025](https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12848&Mode=0). The KFS circular addresses standardized borrower disclosures, APR computation, acknowledgement and an amortization schedule. For loans of seven days or longer, the KFS validity period is at least three working days; shorter loans have a one-working-day minimum. Implement lender-approved validity and document generation rather than copying the prototype’s seven-day example. [RBI KFS circular, 15 April 2024](https://rbi.org.in/Scripts/NotificationUser.aspx?Id=12663&Mode=0). Other launch reviews: applicable KYC/AML rules, privacy and data-protection obligations and their commencement status, communications consent, credit-information reporting, outsourcing/cybersecurity, recovery conduct, tax, e-sign validity and applicable prepayment rules. These reviews are unresolved dependencies, not certified features of this package. ## 10. Acceptance scenarios for production | Scenario | Expected result | | --- | --- | | Wrong or expired OTP; resend flood | Clear error, rate limit, expiring challenge; no session issued | | Required assessment consent declined | No bureau/income request made; marketing stays independent | | Reload or app killed after saved step | Resume from authenticated server draft | | Out-of-range amount, future DOB, invalid PAN or unsupported location | Backend rejects with safe field-level error | | KYC failure or unsupported bank | Specific retry/alternative route; progress preserved | | Another customer’s application ID requested | Access denied without data leakage | | Maker tries to approve own proposal | Backend denies; audit records attempt | | Two checkers confirm different versions | Only current version can succeed atomically | | Offer expires while borrower reads KFS | Acceptance rejected; refresh and new acknowledgement required | | e-sign return arrives before provider callback | Signature remains pending | | Payout request times out | UNKNOWN; enquiry with original reference; no new payout | | Duplicate or late settlement callback | One allocation; monotonic status or explicit reversal | | Partial payment or reversal | Lender schedule/ledger determines revised due; no false paid state | | Consent revoked or deletion requested with active loan | Explain permitted retention; route to lender; preserve obligations | | Complaint remains unresolved | Original receipt time and applicable escalation route retained | | Last installment / cooling-off amount reconciles | Close only on lender confirmation; issue closure record | ## 11. Delivery phases and open decisions 1. Product and lender alignment: validate customer segment, lending contract, credit rules, fees, KFS, collections, privacy and support responsibilities. 2. UX refinement: usability-test these flows, finalize design system, error copy, native navigation, localization and accessible high-fidelity screens. 3. Sandbox implementation: OTP, consent, applications, provider adapters, review, document/signature, mandate and status flows. 4. Financial operations: lender disbursement adapter, schedule mirror, repayments, reconciliation, complaints and reporting. 5. Controlled pilot: security assessment, restore exercise, lender UAT, operational training, support readiness and limited rollout. A team capacity plan and vendor sandbox access are required before estimating calendar dates or cost. No delivery timeline is promised in this package. Decisions still needed: legal entity and lender; age/income/serviceability thresholds; provider list; exact interest/fees; KFS and exit terms; retention schedule; underwriting authority; bank and collection arrangements; complaint contacts; languages; expected volumes; native release targets and hosting contracts. The defaults above are proposals that make the wireframes reviewable.