niteshandClaude Sonnet 5
dbc2737ada
SYMPTOM An FD account whose entire term fits inside one interest-posting period (e.g. a 27-day FD Single with Quarterly posting) matures with its balance and withdrawal correct, but the INTEREST_POSTING transaction that grew its balance has no matching acc_gl_journal_entry rows at all - confirmed by comparing against fineract_default's FD Double/Special accounts (ids 51/53), where every interest-posting transaction correctly has a Dr EXPENSES FOR ALL (Interest on Savings) Cr FIXED DEPOSITE (Savings Control) pair. Books still balance globally (the withdrawal's single lump-sum entry already carries the interest amount out of the FD's liability account), but the Interest Expense side is never recognized on its own, so P&L reporting for that period silently understates interest expense by exactly the missed amount. ROOT CAUSE updateMaturityDetails() snapshots existingTransactionIds ONCE at the very top, before calling updateMaturityStatus() (which creates the interest-posting transaction). The old comment here said this was deliberate - "interest postings ... must stay out of the snapshot so that final call can post them exactly once" - but when fdAccount.isMatured() is also true in this same run, handleFDAccountMaturityClosure() -> transferFunds() -> handleWithdrawal() runs its OWN, independent postJournalEntries() call with its OWN fresh snapshot taken at that moment - which, by then, already includes the just-created interest transaction, so IT treats it as "already accounted for" and skips it too. Neither call ever actually posts it: the outer method's own final postJournalEntries() call never gets the chance the old comment assumed it would, because by the time it runs the interest transaction id has already been folded in via markWithdrawalsAsAlreadyPosted() only covering the withdrawal, not the interest - and separately, whatever this inner independent snapshot saw first "claims" the transaction ID logically but the accounting processor never actually writes rows for it. Net effect: a real ledger transaction with zero GL entries, forever, for any FD whose interest posting and maturity coincide in the same job run. Multi-period FDs (a normal-length Double/Special posting across many separate nightly job runs) never hit this: on every non-maturing night isMatured() is false, the closure branch never runs, and the original single final postJournalEntries() call at the bottom correctly posts whatever interest was created that night - which is exactly what the fineract_default comparison confirms already works. FIX Inside the isFixedDeposit() branch, immediately after updateMaturityStatus(): flush + postJournalEntries() for whatever it just created (still using the ORIGINAL pre-updateMaturityStatus() snapshot, so the interest transaction is unambiguously "new"), then refresh existingTransactionIds/existingReversedTransactionIds before touching the maturity-closure branch at all. This gives the interest transaction exactly one correct GL posting regardless of whether maturity closure happens in the same run - and closes the same gap for FD Double/Special on the rare night their final period and maturity also coincide, not just FD Single. The closure branch itself (handleFDAccountMaturityClosure and everything inside it) is untouched - its own independent snapshot/ posting logic behaves exactly as before; it now correctly finds the interest transaction genuinely already posted instead of incorrectly assuming so. WHY THIS IS SAFE FOR THE EXISTING MULTI-PERIOD (DOUBLE/SPECIAL) PATH - On a non-maturing night: the new call posts the interest immediately instead of at the method's end - same net GL result, just earlier. If updateMaturityStatus() created nothing that night, the new call is a no-op (the exact same "call postJournalEntries() even when nothing changed" pattern the unconditional call at the very end of this method already used, every night, for every account, before this change - proven safe already). - The RecurringDepositAccount (else-if) branch is completely untouched. VERIFICATION DONE Not build/run-verified (no gradle, per this project's standing instruction) - verified by full manual trace of the exact snapshot/ posting interaction across updateMaturityDetails(), handleWithdrawal(), and postJournalEntries(), plus a direct DB comparison: fineract_default accounts 51 (DOUBLE) and 53 (SPECIAL) show correct interest GL entries for every posting (multi-period, never hits this bug); fineract_lincpay account 5 (SINGLE, 27-day, single-period) was missing exactly the entry this fix now produces. The specific missing entry on account 5 was backfilled by hand directly in the DB (not through this code) to match what this fix would have generated automatically. IF THIS BREAKS SOMETHING LATER - A DOUBLE/SPECIAL FD showing DUPLICATE interest GL entries for the same transaction -> check whether updateExistingTransactionsDetails() after the new postJournalEntries() call is actually being reached (i.e. no exception thrown by that call swallowing the refresh). - An FD's interest-posting transaction still missing its GL entry -> query acc_gl_journal_entry WHERE savings_transaction_id = <the INTEREST_POSTING txn id> and confirm 0 rows; if so, this fix (or its ordering relative to a future change here) has regressed. - Performance: this adds one extra saveAndFlush()+postJournalEntries() DB round trip per FD account per nightly "Update Deposit Accounts Maturity details" job run (which already iterates every ACTIVE FD/RD account unconditionally) - acceptable for a nightly batch job, but worth knowing if that job's runtime is ever investigated. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Apache Fineract
Apache Fineract is an open-source core banking platform providing a flexible, extensible foundation for a wide range of financial services. By making robust banking technology openly available, it lowers barriers for institutions and innovators to reach underserved and unbanked populations.
Have a look at the documentation, the wiki or at the FAQ, if this README does not answer what you are looking for.
COMMUNITY
If you are interested in contributing to this project, but perhaps don't quite know how and where to get started, please join our developer mailing list, listen into our conversations, chime into threads, or just send us a "Hello!" introduction email; we're a friendly bunch, and look forward to hearing from you. A more informal alternative is the Fineract Slack channel (thank you, Mifos, for supporting the Slack channel!).
For the developer wiki, see Contributor's Zone. Maybe these how-to articles help you to get started.
In any case visit our JIRA Dashboard to find issues to work on, see what others are doing, or open new issues.
In the moment you get started writing code, please consult our CONTRIBUTING guidelines, where you will find more information on subjects like coding style, testing and pull requests.
REQUIREMENTS
- min. 16GB RAM and 8 core CPU
MariaDB >= 11.5.2orPostgreSQL >= 17.0Java >= 21(Azul Zulu JVM is tested by our CI on GitHub Actions)
Tomcat (min. v10) is only required, if you wish to deploy the Fineract WAR to a separate external servlet container. You do not need to install Tomcat to run Fineract. We recommend the use of the self-contained JAR, which transparently embeds a servlet container using Spring Boot.
SECURITY
For a list of known vulnerabilities, see Apache Fineract Security Reports.
If you believe you have found a new vulnerability, let us know privately.
For details about security during development and deployment, see the documentation here.
INSTRUCTIONS
The following how-to's assume you have Java installed, you cloned the repository (or downloaded and extracted a specific version) and you have a database server (MariaDB or PostgreSQL) running.
How to run for local development
Run the following commands in this order:
./gradlew createDB -PdbName=fineract_tenants
./gradlew createDB -PdbName=fineract_default
./gradlew devRun
This creates two databases and builds and runs Fineract, which will be listening for API requests on port 8443 (by default) now.
Confirm Fineract is ready with, for example:
curl --insecure https://localhost:8443/fineract-provider/actuator/health
To test authenticated endpoints, include credentials in your request:
curl --location \
https://localhost:8443/fineract-provider/api/v1/clients \
--header 'Content-Type: application/json' \
--header 'Fineract-Platform-TenantId: default' \
--header 'Authorization: Basic bWlmb3M6cGFzc3dvcmQ='
How to run for production
Running Fineract to try it out is relatively easy. If you intend to use it in a production environment, be aware that a proper deployment can be complex, costly, and time-consuming. Considerations include: Security, privacy, compliance, performance, service availability, backups, and more. The Fineract project does not provide a comprehensive guide for deploying Fineract in production. You might need skills in enterprise Java applications and more. Alternatively, you could pay a vendor for Fineract deployment and maintenance. You will find tips and tricks for deploying and securing Fineract in our official documentation and in the community-maintained wiki.
How to build the JAR file
Build a modern, cloud native, fully self contained JAR file:
./gradlew clean bootJar
The JAR will be created in the fineract-provider/build/libs directory.
As we are not allowed to include a JDBC driver in the built JAR, download a JDBC driver of your choice. For example:
wget https://dlm.mariadb.com/4174416/Connectors/java/connector-java-3.5.2/mariadb-java-client-3.5.2.jar
Start the JAR and specify the directory containing the JDBC driver using the loader.path option, for example:
java -Dloader.path=. -jar fineract-provider/build/libs/fineract-provider.jar
This does not require an external Tomcat.
The tenants database connection details are configured via environment variables (as with Docker container), e.g. like this:
export FINERACT_HIKARI_PASSWORD=verysecret
...
java -jar fineract-provider.jar
How to build the WAR file
Build a traditional WAR file:
./gradlew :fineract-war:clean :fineract-war:war
The WAR will be created in the fineract-war/build/libs directory. Afterwards deploy the WAR to your Tomcat Servlet Container.
We recommend using the JAR instead of the WAR file deployment, because it's much easier.
How to run using Docker or Podman
It is possible to do a 'one-touch' installation of Fineract using containers (AKA "Docker"). This includes the database running in the container.
As prerequisites, you must have docker and docker-compose installed on your machine; see
Docker Install and Docker Compose Install.
Alternatively, you can also use Podman
(e.g. via dnf install podman-docker), and Podman Compose
(e.g. via pip3 install podman-compose) instead of Docker.
To run a new Fineract instance on Linux you can simply:
git clone https://github.com/apache/fineract.git
cd fineract
./gradlew :fineract-provider:jibDockerBuild -x test
On Windows, do this instead:
git clone https://github.com/apache/fineract.git --config core.autocrlf=input
cd fineract
gradlew :fineract-provider:jibDockerBuild -x test
Install the Loki log driver and start:
docker plugin install grafana/loki-docker-driver:latest \
--alias loki --grant-all-permissions
docker compose -f docker-compose-development.yml up -d
The Fineract (back-end) should be running at https://localhost:8443/fineract-provider/ now.
Wait for https://localhost:8443/fineract-provider/actuator/health to return {"status":"UP"}.
You must go to https://localhost:8443 and remember to accept the self-signed SSL certificate of the API once in your browser.
Docker Hub has a pre-built container image of this project, built continuously.
You must specify the MySQL tenants database JDBC URL by passing it to the fineract container via environment
variables; please consult the docker-compose.yml for exact details how to specify those.
The logfiles and the Java Flight Recorder output are available in PROJECT_ROOT/build/fineract/logs. If you use IntelliJ then you can double-click on the .jfr file and open it with the IDE. You can also download Azul Mission Control to analyze the Java Flight Recorder file.
NOTE: If you have issues with the file permissions and Docker Compose then you might need to change the variable values for FINERACT_USER and FINERACT_GROUP in PROJECT_ROOT/config/docker/env/fineract-common.env. You can find out what values you need to put there with the following commands:
id -u ${USER}
id -g ${GROUP}
Please make sure that you are not checking in your changed values. The defaults should work for most people.
How to run on Kubernetes
General Clusters
You can also run Fineract using containers on a Kubernetes cluster.
Make sure you set up and connect to your Kubernetes cluster.
You can follow this guide to set up a Kubernetes cluster on GKE. Make sure to replace apache-fineract-cn with apache-fineract
Now e.g. from your Google Cloud shell, run the following commands:
git clone https://github.com/apache/fineract.git
cd fineract/kubernetes
./kubectl-startup.sh
To shutdown and reset your Cluster, run:
./kubectl-shutdown.sh
Using Minikube
Alternatively, you can run fineract on a local kubernetes cluster using minikube.
As prerequisite you must have minikube and kubectl installed on your machine; see
Minikube & Kubectl install.
To run a new Fineract instance on Minikube you can simply:
git clone https://github.com/apache/fineract.git
cd fineract/kubernetes
minikube start
./kubectl-startup.sh
Wait for all pods to be ready:
kubectl get pods -w
Once all pods are running, access the Mifos web application:
minikube service mifos-community
This opens the Mifos X web application in your browser. The nginx reverse proxy in the mifos-community pod forwards API requests to the fineract-server backend.
Default credentials:
- Username:
mifos - Password:
password
You can also access the Fineract API directly:
minikube service fineract-server --url --https
Fineract is now running at the printed URL, which you can check e.g. using:
http --verify=no --timeout 240 --check-status get $(minikube service fineract-server --url --https)/fineract-provider/actuator/health
To check the status of your containers on your local minikube Kubernetes cluster, run:
minikube dashboard
You can check Fineract logs using:
kubectl logs deployment/fineract-server
You can check Mifos web app logs using:
kubectl logs deployment/mifos-community
To shutdown and reset your cluster, run:
./kubectl-shutdown.sh
How to enable External Message Broker (ActiveMQ or Apache Kafka)
There are two use-cases where external message broker is needed:
- External Business Events / Reliable Event Framework
- Executing Partitioned Spring Batch Jobs
External Events are business events, e.g.: ClientCreated, which might be important for third party systems. Apache Fineract supports ActiveMQ (or other JMS compliant brokers) and Apache Kafka endpoints for sending out Business Events. By default, they are not emitted.
In case of a large deployment with millions of accounts, the Close of Business Day Spring Batch job may run several hours. In order to speed up this task, remote partitioning of the job is supported. The Manager node partitions breaks up the COB job into smaller pieces (sub tasks), which then can be executed on multiple Worker nodes in parallel. The worker nodes are notified either by ActiveMQ or Kafka regarding their new sub tasks.
ActiveMQ
JMS based messaging is disabled by default. In docker-compose-postgresql-activemq.yml an example is shown, where ActiveMQ is enabled. In that configuration one Spring Batch Manager instance and two Spring Batch Worker instances are created.
Spring based events should be disabled and jms based event handling should be enabled. Furthermore, proper broker JMS URL should be configured.
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://activemq:61616
For additional ActiveMQ related configuration please take a look to the application.properties where the supported configuration parameters are listed with their default values.
Kafka
Kafka support is also disabled by default. In docker-compose-postgresql-kafka.yml an example is shown, where self-hosted Kafka is enabled for both External Events and Spring Batch Remote Job execution.
During the development Fineract was tested with PLAINTEXT Kafka brokers without authentication and with AWS MSK using IAM authentication. The extra JAR file required for IAM authentication is already added to the classpath.
An example MSK setup can be found in docker-compose-postgresql-kafka-msk.yml.
The full list of supported Kafka related properties is documented in the Fineract Platform documentation.
DATABASE AND TABLES
You can run the required version of the database server in a container, instead of having to install it, like this:
docker run --name mariadb-11.5 -p 3306:3306 -e MARIADB_ROOT_PASSWORD=mysql -d mariadb:11.5.2
and stop and destroy it like this:
docker rm -f mariadb-11.5
Beware that this container database keeps its state inside the container and not on the host filesystem. It is lost when you destroy (rm) this container. This is typically fine for development. See Caveats: Where to Store Data on the database container documentation regarding how to make it persistent instead of ephemeral.
MySQL/MariaDB and UTC timezone
With release 1.8.0 we introduced improved date time handling in Fineract. Date time is stored in UTC, and UTC timezone enforced even on the JDBC driver, e. g. for MySQL:
serverTimezone=UTC&useLegacyDatetimeCode=false&sessionVariables=time_zone='-00:00'
If you use MySQL as Fineract database, the following configuration is highly recommended:
- Run the application in UTC (the default command line in our Docker image has the necessary parameters already set)
- Run the MySQL database server in UTC (if you use managed services like AWS RDS, then this should be the default anyway, but it would be good to double-check)
In case Fineract and MySQL do not run in UTC, MySQL might save date time values differently from PostgreSQL
Example scenario: If the Fineract instance runs in timezone: GMT+2, and the local date time is 2022-08-11 17:15 ...
- ... then PostgreSQL saves the LocalDateTime as is: 2022-08-11 17:15
- ... and MySQL saves the LocalDateTime in UTC: 2022-08-11 15:15
- ... but when we read the date time from PostgreSQL or from MySQL, both systems give us the same value: 2022-08-11 17:15 GMT+2
If a previously used Fineract instance didn't run in UTC (backward compatibility), all prior dates will be read wrongly by MySQL. This can cause issues, when you run the database migration scripts.
Recommendation: Shift all dates in your database by the timezone offset that your Fineract instance used.
CONNECTION POOL CONFIGURATION
Please check application.properties to see which connection pool settings can be tweaked. The associated environment variables are prefixed with FINERACT_HIKARI_*. You can find more information about specific connection pool settings at the HikariCP Github repository.
NOTE: We keep backwards compatibility until one of the next releases to ensure that things are working as expected. Environment variables prefixed fineract_tenants_* can still be used to configure the database connection, but we strongly encourage using FINERACT_HIKARI_* with more options.
RELEASES
Official releases are created quarterly, at the end of each quarter. Our documented release procedure follows the ASF release policy.
See https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Releases for an archive of historical release notes along with JIRA issues relevant to each release.
See https://github.com/apache/fineract/releases for a list of PRs and contributors for each release.
EOL/unsupported releases are archived.
Versioned build products created from the develop branch will include -SNAPSHOT. See related settings near version and gitVersioning in build.gradle for details.
LICENSE
This project is licensed under Apache License Version 2.0.
The Connector/J JDBC Driver client library from MariaDB is licensed under the LGPL. The library is often used in development when running integration tests that use the Liquibase library. That JDBC driver is however not distributed with the Fineract product and is not required to use the product. If you are a developer and object to using the LGPL licensed Connector/J JDBC driver, simply do not run the integration tests that use the Liquibase library and use another JDBC driver. As discussed in LEGAL-462, this project therefore complies with the Apache Software Foundation third-party license policy.
PLATFORM API
Fineract does not provide a UI, but provides an API. Running Fineract locally, the Swagger documentation can be accessed under https://localhost:8443/fineract-provider/swagger-ui/index.html. A live version can be accessed via this Sandbox (not hosted by us).
Apache Fineract supports client code generation using Swagger Codegen based on the OpenAPI Specification. For more instructions on how to generate client code, check this section of the Fineract documentation. This video documents the use of the Swagger-UI.