Appearance
Client Datatables (m_client)
Client datatables attach custom data directly to individual client records. They are the most commonly used datatable target, because client profiles are where most regulatory, social, and operational data requirements land.
All examples below use apptableName: "m_client". Fields marked one-to-many use multiRow: true.
Extended KYC and Compliance
Regulators frequently require information beyond what the standard client profile captures. A KYC extension datatable is typically one-to-one - one compliance record per client.
Use case: Capturing AML and KYC attributes at onboarding, required for regulatory reporting.
Example fields:
| Field name | Type | Notes |
|---|---|---|
PEP_Status | Boolean | Politically Exposed Person flag |
Source_of_Funds | Dropdown | Linked to a "Source of Funds" code value list |
ID_Document_Type | Dropdown | Linked to a document type code list |
ID_Document_Number | String (50) | Client's primary ID number |
ID_Expiry_Date | Date | |
Risk_Classification | Dropdown | Low / Medium / High |
KYC_Verified_Date | Date | Date the KYC review was completed |
KYC_Officer | String (100) | Name or employee code of the reviewing officer |
This structure keeps compliance data separate from the client profile but queryable alongside it in reports. When a regulatory audit requires a list of all high-risk clients with expiring documents, a single report query covers both tables.
Household Survey (Poverty Assessment)
Microfinance institutions running social performance programs or participating in Progress out of Poverty Index (PPI) measurement need to capture household-level data at intake and at follow-up intervals. This is one-to-one per client per survey round, or one-to-many if multiple rounds are tracked over time.
Use case: Tracking poverty indicators and household conditions for impact reporting and donor requirements.
Example fields for a household baseline survey:
| Field name | Type | Notes |
|---|---|---|
Survey_Date | Date | Date the survey was conducted |
Household_Size | Number | Number of people in the household |
Primary_Income_Source | Dropdown | Agriculture / Trade / Employment / Remittance / Other |
Monthly_Household_Income | Decimal | Estimated monthly household income |
Housing_Type | Dropdown | Owned / Rented / Shared / Informal |
Access_to_Clean_Water | Boolean | |
Access_to_Electricity | Boolean | |
Children_in_School | Number | Number of school-age children currently enrolled |
PPI_Score | Number | Calculated poverty probability score |
Using multiRow: true allows a second survey to be recorded at follow-up without overwriting the baseline, preserving the full history for longitudinal impact analysis.
Business Profile (SME and MSME Clients)
For institutions serving small businesses rather than individuals, client records need business attributes that the standard personal profile does not include.
Use case: Capturing business registration, sector, and operational details for SME lending eligibility and portfolio segmentation.
Example fields:
| Field name | Type | Notes |
|---|---|---|
Business_Name | String (150) | |
Registration_Number | String (50) | Business registration or tax ID |
Business_Sector | Dropdown | Linked to a sector classification code list |
Years_in_Operation | Number | |
Number_of_Employees | Number | Full-time equivalent headcount |
Annual_Revenue | Decimal | Self-reported annual turnover |
Business_Premises | Dropdown | Owned / Leased / Home-based / Market stall |
Has_Bank_Account | Boolean | Existing formal banking relationship |
Primary_Market | Dropdown | Local / Regional / Export |
This datatable supports credit scoring workflows and feeds into loan eligibility rules, without requiring changes to the core loan product configuration.
Family Members (One-to-Many)
Group lending and household-level risk assessments often require capturing dependants or family members linked to a client. Since a client can have multiple family members, this is always multiRow: true.
Use case: Recording household composition for group lending eligibility and social data collection.
Example fields:
| Field name | Type | Notes |
|---|---|---|
Full_Name | String (150) | |
Relationship | Dropdown | Linked to a relationship type code list (Spouse, Child, Parent, Sibling, Other) |
Date_of_Birth | Date | |
Gender | Dropdown | Linked to the Gender code list |
Education_Level | Dropdown | None / Primary / Secondary / Tertiary |
Employment_Status | Dropdown | Employed / Self-employed / Student / Unemployed |
Monthly_Income | Decimal | Individual income contribution to household |
With this structure, a report can calculate total household income, dependant ratios, and education levels across the portfolio without any custom development.
Income Verification
For lending institutions that require documentary evidence of income, a structured datatable is preferable to free-text notes or attached files alone. This is one-to-one per client.
Use case: Recording the outcome of the income verification process and the supporting evidence reviewed.
Example fields:
| Field name | Type | Notes |
|---|---|---|
Verification_Method | Dropdown | Payslip / Bank statement / Tax return / Business records / Site visit |
Verified_Monthly_Income | Decimal | Income figure accepted after verification |
Currency | Dropdown | Linked to currency code list if multi-currency |
Verification_Date | Date | |
Verified_By | String (100) | Officer name or employee code |
Notes | Text | Free-text for exceptions or caveats |
Debt_to_Income_Ratio | Decimal | Calculated at time of verification |
Officer Visit Log (One-to-Many)
Field-based institutions track visits to clients - for relationship management, repayment follow-up, or condition assessment. Since there are many visits per client over time, this is multiRow: true.
Use case: Maintaining a timestamped log of officer interactions for portfolio management and collections.
Example fields:
| Field name | Type | Notes |
|---|---|---|
Visit_Date | Date | |
Visit_Purpose | Dropdown | Routine / Collections / Verification / Complaint / Other |
Officer_Name | String (100) | |
Client_Present | Boolean | Whether the client was available during the visit |
Outcome | Dropdown | Positive / Neutral / Concern raised / Escalated |
Next_Visit_Date | Date | Scheduled follow-up |
Notes | Text | Free-text observation |
Portfolio managers can query this table to identify clients who have not been visited recently, or clients with a pattern of escalated outcomes.
Social Performance Indicators
Institutions reporting to social investors or participating in frameworks like SPTF (Social Performance Task Force) need structured social data per client. This is typically one-to-one, refreshed annually.
Use case: Capturing structured social outcome data for investor reporting and impact measurement.
Example fields:
| Field name | Type | Notes |
|---|---|---|
Reporting_Period | String (10) | e.g. "2024-Q1" |
Is_Woman | Boolean | |
Is_Youth | Boolean | Under 35 |
Is_Rural | Boolean | |
Is_First_Time_Borrower | Boolean | First formal credit product |
Disability_Status | Boolean | |
Displaced_Status | Boolean | Internally displaced or refugee |
Financial_Literacy_Trained | Boolean | Participated in financial literacy program |
These fields allow institutions to produce disaggregated portfolio data - percentage of women clients, rural reach, youth penetration - directly from Fineract without maintaining a parallel tracking spreadsheet.