đź“„ 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)
- Dynamic Recollection Periods: Set Daily, Weekly, or Bi-weekly repayment triggers at the project level.
- Project Life-cycle Tracking: Independent status tracking (Disbursed, Repaying, Completed) for each concurrent project.
- 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_repaymentstable. - Columns: Project_ID, Merchant_ID, Transaction_Date, Amount_Collected, Principal_Portion, Fee_Portion, Remaining_Balance.
- Requirement: All repayments must be written to a permanent
- 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.xlsxfor seamless reconciliation.
3. The “How” (User Flow)
- Selection: Ops selects an enriched merchant from the database.
- Configuration: Ops defines the “Bulk Purchase” amount and selects repayment style from a dropdown (Daily Revenue Split or Fixed Weekly).
- Parallel Launch: Ops can add a second project for the same merchant without affecting the first one.
- 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_configto a one-to-manyfinance_projectstable. - 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.