3. Complete product module map

This section enumerates every module a full lending platform needs. It is organised into sixteen module families A through P, each on its own page. Together, they constitute the product surface of the platform — what users see, what compliance officers depend on, what engineers must build or buy.

The module list is exhaustive, not aspirational. Skipping a module is a conscious choice, not an oversight. The MVP roadmap makes those choices explicit by phase.

Module families

ID	Family	Pages
A	Borrower acquisition	3.A
B	Application journey	3.B
C	KYC / KYB	3.C
D	Data ingestion	3.D
E	Underwriting engine	3.E
F	Manual underwriting workflow	3.F
G	Co-lending module	3.G
H	Loan documentation	3.H
I	Disbursement	3.I
J	Loan management system (LMS)	3.J
K	Collections	3.K
L	Portfolio monitoring	3.L
M	Accounting and finance	3.M
N	Reporting and compliance	3.N
O	Admin and configuration	3.O
P	Analytics and intelligence	3.P

How modules combine into journeys

A loan moves through modules in roughly this order:

   Acquisition (A)
        │
        ▼
   Application (B)
        │
        ▼
   KYC / KYB (C) ────► Data ingestion (D)
        │                    │
        └──────► Underwriting engine (E)
                       │
                       ▼
               Manual workflow (F)  ────► Co-lending allocation (G, if co-lent)
                       │
                       ▼
               Loan documentation (H)
                       │
                       ▼
               Disbursement (I)
                       │
                       ▼
               LMS (J) ◄──── Collections (K)
                       │
                       ▼
               Portfolio monitoring (L)
                       │
                       ▼
               Accounting (M) + Reporting (N)

   Cross-cutting always-on: Admin & config (O), Analytics (P)

Page template

Each module page below uses the same template:

1. Purpose — what the module exists for.
2. In-scope features — bullet list, exhaustive.
3. Out-of-scope — features explicitly not in this module.
4. Key entities — what data this module owns.
5. Key workflows — the few main flows the module orchestrates.
6. Integrations — what external systems and vendors it talks to.
7. APIs — what it exposes to other modules.
8. Events — what it emits.
9. Edge cases — operational situations that break naive implementations.
10. Compliance touchpoints — which regulations bite into this module.
11. MVP vs production — what to ship first vs what to defer.

How this section relates to other sections

• The data model (entities and fields) is in Section 5.
• The underwriting rules library is in Section 6.
• The co-lending allocation engine and APIs are in Section 7.
• The vendor list per integration is in Section 4.
• The engineering backlog (user stories per module) is in Section 13.

Each module page links forward and backward to keep the reading coherent.