P2P Lending App Development

Companies building P2P lending platforms are engineering regulated financial infrastructure, not simple transactional apps. The core system manages the full loan lifecycle: origination, underwriting, matching, funding, servicing, and collections. Each stage carries compliance obligations (AML/KYC, adverse action notices, regulatory reporting), financial data integrity requirements (append-only payment ledgers, complete audit trails), and operational reliability demands (ACH settlement windows, collections SLAs). Whether building a consumer lending marketplace, a business lending platform, or an SME invoice financing product, the engineering decisions made in the origination engine and matching layer determine whether the platform can scale to institutional volumes and survive regulatory scrutiny. Scrums.com builds dedicated engineering teams that ship production-ready lending infrastructure (from credit decisioning to collections) in weeks, not quarters.

Loan Origination and Credit Decisioning Architecture

The loan_applications table is an append-only state machine: status transitions (submitted, bureau_pull, underwriting, decisioned, offered, accepted, funded, active, closed) are recorded as events, never as field updates. This gives compliance teams a complete audit trail for adverse action notice obligations under ECOA and Regulation B.

Bureau integrations (Experian, Equifax, TransUnion, or international equivalents) use a soft pull at application intake for pre-qualification and a hard pull at offer acceptance. Store the raw bureau response as an immutable JSON blob alongside the application; regulators can request the exact data that drove the decision years later. Decouple the credit policy from the application service: a credit_rules table versioned with effective_date ranges means LTV limits, DTI thresholds, and minimum score cutoffs can be adjusted without a code deploy.

Underwriting model outputs (probability of default, expected loss, suggested rate band) are stored in underwriting_decisions as a separate immutable record, never overwritten. When the model is retrained, old decisions retain the model_version that produced them. Challenger models run in shadow mode: scoring applications without affecting live decisions, storing results in shadow_decisions for offline evaluation before promotion.

Adverse action notice generation must be deterministic: the top four reason codes from the bureau response plus the specific credit policy rule that triggered rejection. Store reason codes as a typed enum, not free text, to ensure notices are consistent and machine-readable for regulatory submissions.

Borrower-Lender Matching and Marketplace Infrastructure

The offer_book records every investor allocation against a loan listing: investor_id, amount_committed, interest_rate, committed_at. Fractional funding (where multiple investors fund slices of a single loan) requires a funding_round table with a target_amount and a current_funded_amount maintained by serialisable-isolation increments (not optimistic concurrency), plus an expiry_at timestamp after which unfunded listings cancel and committed funds release.

Auto-invest (rules-based allocation for institutional or retail investors) runs as a background service reading from a policy_config table: loan grades, maximum exposure per borrower, maximum concentration per industry, minimum yield. The service processes new listings via an event-driven queue, never polling the database, and respects per-investor daily allocation caps enforced with a Redis sorted set counter reset at midnight in the investor's local timezone (IANA tz lookup, not UTC offset).

Secondary market note transfers use a note_transfer table. A transfer atomically updates the note's investor_id and appends a transfer_event to the loan event log via a single serialisable-isolation transaction. Transfer pricing (par, discount, or premium) is stored as a decimal; platform fees on secondary trades are computed from a fee_schedule config table at transfer time, not cached on the note.

Portfolio analytics for investors use nightly pre-computed snapshots for summary metrics (weighted average life, average yield, default rate by grade) and projection queries for real-time balance, avoiding live aggregation of the full loan book on every page load.

P2P lending platforms like these are built and delivered by dedicated engineering teams through our mobile app development service.

Payment Processing and Collections Infrastructure

Repayment schedules are generated at loan funding using the agreed amortisation formula (flat rate, declining balance, or interest-only with bullet). Each row in repayment_schedule stores due_date, principal_due, interest_due, fees_due, and status (pending, collected, missed, waived). The schedule is immutable after generation; adjustments such as payment holidays or restructures create a new schedule version linked to a restructure_event record.

ACH and SEPA direct debit origination runs via a payment processor adapter (Dwolla, Stripe, GoCardless). The adapter wraps each origination call with a deduplication_key (loan_id + due_date + attempt_number) to prevent double debits on retries. Payment events flow into payment_events as an append-only ledger: every initiation, settlement, return, and reversal is a separate row, never an update to an existing row.

Collections workflow triggers on a missed payment event. A collections_workflow table tracks each delinquent loan: days_past_due, current_stage (soft_collections, formal_collections, legal, write_off), and assigned_agent. Stage transitions are governed by a collection_policy config table: DPD thresholds, permitted contact actions (SMS, email, outbound call, legal referral), and jurisdiction-specific restrictions (FDCPA contact hour limits stored as schedule config). Late fees are computed from a fee_config table, not hardcoded, so policy changes take effect without a code deploy.

Charge-off events create a journal entry pair in the accounting layer: debit Bad Debt Expense, credit Loan Receivable. Recovery payments post to a separate recovery_payments ledger and reverse the charge-off proportionally. Dedicated engineering teams from Scrums.com build these payment and collections systems to financial-grade reliability standards.

KYC/AML, Regulatory Reporting, and Portfolio Risk

KYC identity verification runs as a separate microservice. The identity_check table stores the verification outcome (pass, fail, manual_review), the provider response blob (Onfido, Jumio, Persona), and the document type submitted. Status transitions follow a state machine: initiated, documents_submitted, provider_processing, completed, failed, escalated. Failed or manual-review cases block loan origination; the block is enforced by the origination service reading identity_check.status before advancing the application state.

AML transaction monitoring uses a rules engine configured via a monitoring_rules table: amount thresholds, velocity checks (total transfers in a rolling 30-day window), counterparty risk flags, and jurisdiction blocklists. Rules fire alert_events; each alert carries a severity level and a case_id linked to a compliance_cases table for investigator workflow. Suspicious activity reports (SARs) and currency transaction reports (CTRs) are generated as projection queries over alert_events and compliance_cases, not as separate stored documents that can diverge from the underlying data.

Regulatory reporting (1099-INT/OID for the US, ISA manager reporting for the UK) uses a reporting_config table mapping jurisdiction to template, required fields, and submission endpoint. Reports are generated as projection queries over the payment_events and interest_accrual_events ledgers, ensuring figures match the live accounting system exactly.

Portfolio risk metrics (weighted average LTV, concentration by grade, industry, and geography, provision coverage ratio) are computed nightly via a dbt job and stored in portfolio_snapshots. The provision calculation uses an expected-loss model: EAD multiplied by PD (from the underwriting model) multiplied by LGD (from historical recovery data). These figures feed directly into financial reporting without manual adjustment. Start a conversation with Scrums.com to get a dedicated team building compliant lending infrastructure from day one.