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.

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

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

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

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

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

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

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

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

7. Calculation example

For planning only: principal P = ₹1,00,000, nominal annual rate 18%, monthly rate r = 0.18/12, n = 12.

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.

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.

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

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.

Lendly — Technical design and implementation handoff

Version 1.0 · 01 November 2026 · Proposed architecture; not deployed

1. Architecture decision

Use a modular backend for the MVP instead of independently deployed microservices. Separate application/consent, verification, offers/documents, operations and servicing modules by interfaces and database ownership. Split services only when load, isolation or team ownership justifies the overhead.

Two deployment domains are essential. The LSP domain handles minimal profile/contact data, user experience, references and scoped workflow coordination. A lender-owned or lender-controlled domain owns sensitive assessment/KYC evidence, issued offers, financial instructions and the authoritative ledger. Contractual permission and legal review determine exact boundaries; hosting a database in India alone does not authorize unrestricted LSP storage.

Borrower mobile app                     Operations browser
        │                                       │
        ├──── LSP edge / API gateway ────────────┤
        │     Auth, minimal profile, ticket routing,
        │     consent UI references, status projection
        │                    │ mTLS / scoped API
        └──────────── LENDER CONTROLLED DOMAIN ────────────┐
                      Application workflow                │
                      Verification adapters               │
                      Credit review + policy versions     │
                      Offer / KFS / document signing      │
                      Payout & repayment orchestration    │
                      Ledger / LOS / LMS integration      │
                                │                        │
                    PostgreSQL + outbox + job worker     │
                    Encrypted document vault             │
                                │                        │
                   Authorized external providers ◄───────┘
                   OTP · KYC · bureau · income · signing
                   mandate · bank / payment rails

Funds: lender account ⇄ verified borrower account
No funds pass through the LSP application or its accounts.

The diagram is a proposed ownership model, not an assertion that every lender offers these APIs. Agree an integration boundary with the selected lender first. Browser/mobile clients never carry provider secrets or directly trust redirect parameters.

2. Proposed stack

These are proposed engineering choices, not user-mandated technologies. Pin supported stable versions after checking lender SDKs, security maintenance and native build compatibility. This package deliberately does not guess a dependency lockfile.

Official implementation references: React Native, NestJS, PostgreSQL transaction isolation. PostgreSQL documents concurrency behavior; choose explicit locking/version checks for decision and financial transitions rather than assuming a read followed by write is atomic.

3. Modules and contracts

Keep lender-specific integration DTOs inside adapters. Normalize states into the documented application model while preserving raw provider status in the lender-controlled event record.

4. Data model and ownership

All identifiers are UUIDs or opaque lender references. Every applicable record includes lender_id, timestamps, version and provenance. Store money as integer paise in bigint; rates as fixed decimal. Record timestamps in UTC and display borrower schedules in the lender's business timezone, proposed Asia/Kolkata. Encrypt sensitive columns with managed keys and rotation policy.

Relationships: Customer 1:N Application; Application 1:N Verification/Proposal/Offer; Offer 1:N Documents and 0:1 settled Loan; Loan 1:N Installments/Payments; Payment 1:N Allocations. Support ticket references a customer and optional application/loan, without duplicating sensitive evidence.

Constraints: one active application/loan per borrower according to policy; one accepted current offer; unique payout instruction per offer; unique provider event; unique lender-ledger posting reference. Enforce financial and version constraints in the database, not only form validation. Maintain current status projections separately from immutable events.

5. API conventions and draft contract

api-contract.json is an OpenAPI 3.1 draft describing the principal borrower/admin resources. It is a starting contract, not a deployed endpoint set or a complete vendor specification. Its example server uses the reserved .invalid domain. Application authentication uses bearer tokens; workforce tokens require a separate audience and role/tenant verification.

Amounts are integer INR paise, never formatted strings. IDs are opaque. List responses use bounded cursor pagination. All state-changing business requests carry Idempotency-Key; sensitive commands require an expected resource version. Provider callbacks use provider-specific signatures over the raw body with replay checks and are specified separately from bearer authentication.

Representative operations include OTP challenge/verification, draft creation/update/submission, consent events, verification sessions, current offers, offer acceptance, contracting sessions, application status, loan/schedule retrieval, payment intents, exit quotes, tickets, privacy requests, admin proposals/confirmations and reconciliation enquiries. The contract labels actor scopes and includes conflict, auth, validation and throttling errors.

{
  "error": {
    "code": "OFFER_EXPIRED",
    "message": "This offer has expired. Request a refreshed offer.",
    "requestId": "opaque-correlation-id"
  }
}

Error classes: 400 malformed request; 401 invalid authentication; 403 resource/role denied; 404 absent or deliberately concealed resource; 409 version/idempotency/state conflict; 422 business validation; 429 throttled; 503 temporary dependency unavailability. Never expose stack traces, bureau details or provider secrets in errors.

6. Critical transactional sequences

Decision confirmation

Verify workforce identity, checker scope, lender scope and checker_user_id != maker_user_id. In one transaction lock the application, compare expected version and proposal status, verify current evidence/policy and commit decision, new version, audit event and outbox event. A repeated idempotency key with the same body returns the prior result; a changed body returns conflict. A stale proposal cannot be confirmed after borrower data changes.

Offer acceptance and contracting

The server checks borrower ownership, current offer, expiry, required acknowledgement/document hash and application validity atomically. Persist acceptance and contracting request before contacting providers through a worker. Signature and mandate are separate records. Revalidate the final disbursement gates against the accepted offer and verified provider results. A button tap or provider redirect is never a trusted completion event.

Financial instruction and webhook processing

Create a unique instruction and outbox message in a transaction. Worker sends the instruction with a stable provider reference; persist attempts. A timeout becomes UNKNOWN and triggers enquiry against that reference. Verified events enter a durable inbox with unique provider/event ID before asynchronous processing. Acknowledge successful receipt only after durable persistence; repeated valid deliveries return success without duplicate effects. Check monotonic state rules, amount, currency and reference; send conflicting events for investigation.

After provider confirmation, reconcile with lender settlement/ledger evidence. Post one allocation or store the authoritative lender posting reference, then update the servicing projection and emit the receipt notification. Reversal is explicit and compensating. A failed callback arriving after settlement cannot erase a paid status. Network retries must never invent a new payout reference.

Privacy and document handling

Validate requester, purpose and lender scope. Route privacy changes to the lender and provide a request reference. A deletion request creates a case; retention decisions are recorded per data category. Do not promise immediate erasure of loan records. Documents use hash/version binding and short-lived, scope-limited retrieval; no public URLs or KYC attachments in support email.

7. Security and deployment

Use TLS for clients, mTLS or equivalent service authentication where supported, secret storage with rotation and separate development/test/production credentials. Workforce MFA and least privilege are mandatory proposed controls. Validate ownership for every resource, prevent object-level authorization bypass, sanitize uploads inside lender-approved flows and redact PII/tokens from analytics and logs. Mobile tokens belong in platform-protected storage; clear sessions on logout and support session revocation.

Host approved data stores, backups, logs, observability and document processing in contracted India locations. Review telemetry vendors and support access as part of the same boundary. Infrastructure should use separate accounts/projects, private databases, restricted egress, encrypted backups and audited privileged access. Keep production customer data out of development environments.

The prototype stores no real records and has no security boundary. Do not deploy it as a borrower-facing loan application. Its role picker and rail are review controls.

8. Operational targets and observability

Proposed pilot targets, subject to capacity and lender agreements: 99.5% monthly availability for owned non-provider services; p95 under 700ms for simple owned API reads at 50 requests/second; no synchronous provider latency promise. Load-test the agreed traffic model before accepting these targets. Initial recovery objectives: RPO 15 minutes and RTO 4 hours, proven by restore exercises and reconciled against lender financial records.

Track application conversion by step without raw PII, provider success/latency, stale reviews, expiring offers, unknown payout age, unreconciled receipts, duplicate callbacks, queue lag, complaint age and notification failures. Alert on financial mismatches and persistent unknowns; identify an on-call owner and runbook for each. Dashboard reporting must distinguish counts of attempts, unique borrowers, approved applications and settled loans.

Runbooks: provider outage pauses new affected steps while preserving drafts; unknown payout opens enquiry and blocks duplicate issue; settlement mismatch goes to authorized operations; compromised credential triggers revocation, investigation and applicable reporting; restore test replays only deduplicated durable events and checks lender ledger consistency.

9. Implementation phases and verification

Use unit tests for pricing/state guards, contract tests for each adapter, integration tests for transaction/idempotency behavior and end-to-end tests for borrower and operator journeys. Include concurrent checker approval, cross-customer access, revoked consent, expired KFS, provider callback replay and orphaned payment recovery. A passing UI test cannot demonstrate regulatory compliance or real bank settlement.

For the delivered wireframe package, verify JavaScript syntax, screen render/navigation, calculator sensitivity, consent and acknowledgement guards, role-based proposal confirmation, linked application status, settlement deduplication, local document links and narrow viewport layout. Production criteria above remain implementation work.

10. Dependencies and decision register

Before engineering estimates: choose the lender/LOS/LMS and clarify APIs, identity/KYC route, bureau permissions, income provider, signing, mandate, bank rails, notification provider and service-level agreements. Obtain approved fee/tax fixtures, actual KFS/agreement templates, credit-policy versions, complaint ownership and a record-retention schedule. Confirm which domain may store each field.

The API contract intentionally uses generic verification/contracting adapters until vendor selection. Vendor signature algorithms, callback schemas, request credentials, bank settlement formats and detailed decision engine rules cannot be finalized without those agreements. No hidden real providers or credentials are included.

Regulatory basis and remaining legal reviews are in the functional specification. This document is an engineering proposal and does not certify licensing or compliance.