đź“„ Initiative Spec: INT-20 MCA Portfolio Engine (LMS)

Status: 🟡 Draft (BRD Stage) Owner: azmi Strategic Intent: Transform the rigid one-loan-per-merchant model into a dynamic “Micro-Portfolio” engine.


1. The “Why” (Strategic Context)

  • Problem: The current MCA (Merchant Cash Advance) system is rigid. Recollection (repayment) configurations are manual and project-based. We cannot easily handle different periods (daily vs. weekly) without changing global configs, and we cannot run multiple parallel financing projects for a single merchant.
  • The Opportunity: A merchant’s needs aren’t static. They might need a large Inventory loan (Project A) and a smaller Marketing loan (Project B) at the same time.
  • The Goal: Enable Parallel Project Financing where a single merchant can have multiple active projects, each with unique repayment rules.
  • Impact: Maximize Merchant LTV and increase capital deployment velocity by allowing multiple “taps” for the same brand.

2. The “What” (Solution Components)

2.1 The “Project-Level” Config (Config-less Launch)

  • Mechanism: Move from a “one-size-fits-all” merchant config to a Project-Object model.
  • Repayment Logic: All repayment rules (cut %, frequency, terms) are stored as metadata within the specific project object at the time of launch.
  • Elimination of Engineering Bottleneck: Ops can launch new projects via a dropdown UI. No manual database configuration by Engineers is required for individual deals.

2.2 Parallel Financing Support

  • Concurrent Execution: Ability to run Project A (e.g., 100M Inventory @ 10% daily split) and Project B (e.g., 50M Marketing @ 5% daily split) for the same merchant simultaneously.
  • Automated Split Aggregator: The “Splitter” system automatically aggregates the total daily cut (e.g., 15%) from the settlement to service all active projects.

2.3 Key Features (MVP)

  1. Dynamic Recollection Periods: Set Daily, Weekly, or Bi-weekly repayment triggers at the project level.
  2. Project Life-cycle Tracking: Independent status tracking (Disbursed, Repaying, Completed) for each concurrent project.
  3. Bulk Disbursement: Ops capability to disburse multiple projects via CSV upload.

2.4 Reporting & Financial Visibility (The 3-Tier Model)

Focus: Providing real-time insights for Finance and Management.

  • Tier 1: The Project Ledger (Database Store):
    • Requirement: All repayments must be written to a permanent fact_loan_repayments table.
    • Columns: Project_ID, Merchant_ID, Transaction_Date, Amount_Collected, Principal_Portion, Fee_Portion, Remaining_Balance.
  • Tier 2: The Live Dashboard (Metabase):
    • Visibility: A live view for Finance to see today’s expected total collection vs. actual collection across all projects.
    • Merchant View: A consolidated view showing how a merchant’s daily GMV is split between concurrent projects.
  • Tier 3: The Exporter (Downloadable):
    • Feature: One-click download of the Ledger as Excel (.xlsx) or CSV.
    • Excel Parity: Export must match the column structure of the existing FLIK_Daily_Repayments_Tracker.xlsx for seamless reconciliation.

3. The “How” (User Flow)

  1. Selection: Ops selects an enriched merchant from the database.
  2. Configuration: Ops defines the “Bulk Purchase” amount and selects repayment style from a dropdown (Daily Revenue Split or Fixed Weekly).
  3. Parallel Launch: Ops can add a second project for the same merchant without affecting the first one.
  4. Automated Split: The system reads project metadata and automatically calculates the split percentages from daily GMV.

4. Technical & Ops Requirements

  • Data Impact: Refactor merchant_finance_config to a one-to-many finance_projects table.
  • Logic Change: Update the “Splitter” cron job to iterate through all active projects for a merchant rather than checking a single flag.

5. Timeline (Q1)

  • BRD Review: Jan 2026
  • Engineering Draft (PRD): TBD (Tech Lead)
  • Go-Live: Target Q1 end.