Apache Fineract Documentation

repository·develop·Indexed 25 days ago

https://github.com/apache/fineract

An open-source core banking platform providing a flexible foundation for financial services. Documentation covers local development setup using PostgreSQL, the Fineract Java Client library, integration testing, and the Progressive Loan Embeddable Schedule Generator. It includes details on demo database configurations (Bare Bones, default-demo, and latam-demo) and a proposed type-safe, DTO-driven command processing API architecture.

Tokens
113.9K
Snippets
141
Records
540
Agent score
82%

What's inside Apache Fineract

  1. Overview of the Fineract Java Client library

    develop
    The Fineract Java Client is the official library for interacting with Apache Fineract via Java. It is primarily autogenerated using Swagger Codegen to ensure alignment with the Fineract API, but it also contains hand-written utility classes to simplify common usage patterns. This library is maintained as a submodule of the main Apache Fineract repository.
  2. Default Demo Database Contents

    develop

    The default-demo database provides a pre-configured environment containing the latest schema DDL and the minimum reference data required to deploy and interact with the Fineract platform. This is useful for testing legacy documentation interactions or performing a quick setup.

    Included Reference Data:

    • Currencies: Several Latin American currencies are pre-configured (at least one selected currency is mandatory).
    • Offices: A default root/head office named Latam HO is created.
    • Permissions: All permissions required by the latest software release are configured.
    • Roles: A default role named Super user is created, which includes the Full Authorisation permission.
    • Application User: A default user is provided to allow immediate access via the UI.

    Default Application User Credentials:

    • Username: quipo
    • Password: quipo
    • Role: Super user (allows all operations in any office/branch)
    • Office Association: Latam HO
  3. Reference data included in Bare Bones Demo

    develop

    The Bare Bones Demo database contains the latest schema DDL and the minimum required reference data for a functional platform deployment. It includes:

    Core Reference Data

    • Currency: US Dollar (default).
    • Office: A single root office named Head Office.
    • Roles: A single role named Super user with Full Authorisation permissions.
    • Permissions: All permissions required by the latest software release are pre-configured.

    Configuration

    • Client Identity Document: One code is set up called Client Identifier with default values of {'Passport number'}.
    • Feature Flags: An entry named maker-checker is available to enable or disable the maker-checker feature globally. It is disabled by default.
    • Datatables: No additional data via the datatables approach is configured.

    What is NOT included

    To keep the demo lightweight, the following are not pre-configured:

    • Products: No loans, deposits, or savings products.
    • Charges: No fees or penalties.
    • Staff: No employees/loan officers.
    • Portfolio Data: No clients, groups, or accounts.
    • Accounting: No chart of accounts is set up; accounting for portfolio items is off by default.
  4. Access Apache Fineract project resources

    develop

    Use the following links to access the official Apache Fineract project resources:

    • Project Source Code: The central repository for development and code inspection.
    • Issue Tracker: The Jira instance used for reporting bugs, requesting features, and tracking project tasks.
    • Official Downloads: The primary site for downloading stable releases of Apache Fineract.
  5. What is Static Weaving in Fineract

    develop
    Static weaving is a build-time process used to enhance JPA entities to improve runtime performance. It uses org.eclipse.persistence.tools.weaving.jpa.StaticWeave to perform bytecode transformations on compiled classes. This process ensures that JPA-managed classes are optimized before the application runs.
  6. What is Loan Re-Aging (Settlement Plan)?

    develop

    Loan Re-Aging, also known as a Settlement Plan, is a feature used to assist customers in financial duress by restructuring their loan repayment schedule.

    It creates a new set of installments for an existing loan account based on the current outstanding principal. For example, a customer with a 750 euro balance could have that balance spread over 12 months with 10 equal payments instead of the original schedule.

    Key Concepts

    • Re-Age: The process of recalculating the remaining loan schedule (principal, interest, fees, and penalties) starting from a specified date.
    • Transaction Date: The accounting/event date when the re-aging is applied.
    • Start Date: The due date of the first re-aged installment.
    • Special Collected Installment: A single installment created to capture portions of installments that were already partially paid before the re-aging transaction date. This ensures historical repayment accuracy without changing original GL postings.
    • N+1 Installment: An additional installment used to balance rounding differences in principal, interest, or fees.
  7. What is Re-amortization in Advanced Payment Allocation?

    develop

    Re-amortization is a specific allocation strategy for future installments. Instead of paying off a single installment in full, the transaction amount is divided into equal portions based on the number of remaining future installments. Each of those installments is then paid by its respective portion.

    In a typical workflow, the system attempts to allocate the principal portion first. If there are remaining unprocessed amounts after the principal portions are covered, the rest of the outstanding balances are allocated according to the remaining configured rules.

  8. Understand Savings and Fixed Deposit interest posting period types

    develop

    Apache Fineract uses interest posting period types to determine the calendar interval at which accrued interest is credited (posted) to savings and fixed-deposit accounts. These types are divided into two categories: Standard (aligned to fixed calendar boundaries) and Anniversary-Based (anchored to the account activation date).

    Standard Posting Period Types

    These types align with fixed calendar boundaries or the configured financial year.

    CodeNameDescription
    1DailyInterest is posted every day.
    4MonthlyInterest is posted on the first day of each calendar month.
    5QuarterlyInterest is posted on the first day of each calendar quarter, aligned to the configured financial-year beginning month.
    6Bi-AnnualInterest is posted twice a year, aligned to the configured financial-year beginning month.
    7AnnualInterest is posted once a year on the first day of the month that begins the configured financial year.

    Anniversary-Based Posting Period Types

    These types use the account's activation date as an anchor. The posting schedule is determined by the day-of-month of activation rather than fixed calendar boundaries.

    CodeNameDescription
    8Anniversary MonthlyInterest is posted every month on the same day-of-month as the account activation date.
    9Anniversary QuarterlyInterest is posted every three months on the same day-of-month as the account activation date.
    10Anniversary Bi-AnnualInterest is posted every six months on the same day-of-month as the account activation date.
    11Anniversary AnnualInterest is posted every twelve months on the same day-of-month as the account activation date.
  9. Data Model for Working Capital Disable/Enable Features

    develop

    The Disable/Enable functionality in Working Capital does not use new tables. Instead, it appends rows to existing action tables, using the action column to distinguish between different types of operations.

    Core Logic

    • Disable Action: A DISABLE row is inserted with a start_date representing the business date of the action. While the feature is disabled, the end_date remains null.
    • Enable Action: When re-enabling, an ENABLE row is inserted. The existing DISABLE row's end_date is updated to enableDate - 1.
    • Auditing: Both action tables extend an auditable base type, meaning they automatically include created_by, last_modified_by, created_on_utc, and last_modified_on_utc.

    Action Tables

    m_wc_loan_delinquency_action

    Maps to the WorkingCapitalLoanDelinquencyAction entity. Used for managing delinquency status.

    ColumnTypeNullableMeaning for Disable/Enable
    idBIGINT (PK)NoSurrogate key
    wc_loan_idBIGINT (FK)NoOwning loan ID (m_wc_loan.id)
    actionVARCHAR(128)NoDISABLE or ENABLE
    start_dateDATENoBusiness date of the action
    end_dateDATEYesnull while active; enableDate - 1 once enabled

    m_wc_loan_breach_action

    Maps to the WorkingCapitalLoanBreachAction entity. Used for managing breach status.

    ColumnTypeNullableMeaning for Disable/Enable
    idBIGINT (PK)NoSurrogate key
    wc_loan_idBIGINT (FK)NoOwning loan ID (m_wc_loan.id)
    actionVARCHAR(128)NoDISABLE or ENABLE
    start_dateDATENoBusiness date of the action
    end_dateDATEYesnull while active; enableDate - 1 once enabled
  10. Configure External Message Brokers (ActiveMQ or Kafka)

    develop

    Fineract supports external message brokers for two main use cases: sending External Business Events (e.g., ClientCreated) and executing Partitioned Spring Batch Jobs (remote partitioning).

    ActiveMQ

    To enable JMS-based messaging, configure the following environment variables:

    • FINERACT_REMOTE_JOB_MESSAGE_HANDLER_JMS_ENABLED=true
    • FINERACT_REMOTE_JOB_MESSAGE_HANDLER_SPRING_EVENTS_ENABLED=false
    • FINERACT_REMOTE_JOB_MESSAGE_HANDLER_JMS_BROKER_URL=tcp://<broker-host>:<port>

    Kafka

    Kafka support is disabled by default. Configuration properties are documented in the official Fineract Platform documentation. Fineract supports both PLAINTEXT brokers and AWS MSK (using IAM authentication via an included JAR).

  11. Understand the Two-Track Balance Model for Working Capital Loans

    develop

    Working Capital Loans with amortizationType = EIR use a two-track model to distinguish between contracted schedules and actual payment behavior.

    1. Planned Track (Reference Schedule)

    • expectedBalance: The running outstanding principal balance assuming all expected payments are made on time. It decreases monotonically from netDisbursementAmount to zero.
    • expectedDiscountFeeBalance: The remaining unrecognized discount fee income based on expected amortizations: discountFee − Σ(expectedAmortizationAmount[1..i]).
    • Characteristics: Always fully populated and does not change retroactively once built.

    2. Projected Track (Actual Activity)

    • actualBalance: The running outstanding principal balance based on actual cash payments received. It deviates from the planned balance when actual payments differ from expected.
    • actualDiscountFeeBalance: The remaining unrecognized discount fee income based on actual amortizations: discountFee − Σ(actualAmortizationAmount[1..i]).
    • Characteristics: Populated only where a positive payment exists or where calculatedTillDate has been reached. Future unpaid periods are null.

    Relationship and Divergence

    • Exact payment: The tracks converge (actualBalance[i] == expectedBalance[i]).
    • Overpayment: The projected balance decreases faster than the planned balance (actualBalance[i] < expectedBalance[i]).
    • Underpayment/No payment: The projected balance is higher than the planned balance, or remains null if no payment was received for a future period.