Apache Fineract savings and deposit products

Once savings, fixed deposit and recurring deposit accounts exist in Apache Fineract, each product type behaves differently in daily use, and those differences are what your operations team, your customers and your ledger will experience. A savings account is the most open of the three. Deposits and withdrawals are accepted on demand, subject to whatever withdrawal rules and minimum balance settings the product carries. A fixed deposit works the other way: the funds are committed for a term, and the product configuration governs what happens if the customer wants the money earlier. A recurring deposit sits between the two. It expects contributions on a schedule and needs a defined outcome for contributions that are missed.

Interest and charges do not usually move the moment a transaction is entered. In Fineract they are posted by the end-of-day (Close of Business) process, so the balance a customer sees during the day and the balance that appears after the nightly run can differ. The exact effect depends on how each product is configured: the interest calculation and posting frequency, which charges are attached, when they fall due, and how they are recognised in the accounts. Treat those settings as the place where product behaviour is decided, not as defaults to accept. Ask your implementer to show you, for each product, which settings produce an interest or charge posting and at what point in the day it happens.

Before go-live, confirm each of these behaviours against the Fineract documentation for the exact version you plan to run. The current stable release listed on the project website is 1.15.0, but your deployment may be on a different 1.x release, and product options can change between releases. The researched material available for this page does not set out product-level interest formulas, early withdrawal penalty mechanics or the rules for missed recurring deposit instalments, so do not assume how Fineract will handle them. Write down the outcome you need for each case, such as an early exit from a term deposit or a skipped monthly contribution, and check that the configured product produces it.

The only reliable way to confirm these behaviours is to test them with your own rule set. Build a small set of test accounts for each product, using the interest rates, terms, charges and grace periods you intend to offer. Run the transactions you expect customers to make: deposits, withdrawals, early closure of a fixed deposit, a missed recurring instalment and a late one. Then run the end-of-day process and compare the resulting balances, postings and journal entries with a hand calculation signed off by finance. Repeat the test whenever a product setting changes, and keep the results as evidence for your change record and for the reviewers who will ask how the products were verified.

Every Fineract savings, fixed deposit and recurring deposit product needs its balances, interest expense, fee income and withdrawal liabilities pointed at specific general ledger accounts. This mapping is what turns product activity into journal entries, so finance will see the result of these choices in every period close. Settle the mapping with the finance team before the product is built, not after the first month of postings reveals an unexpected balance. For each product type, the first question is which account holds customer deposits. A savings product, a fixed deposit and a recurring deposit may each carry a liability balance that finance wants reported separately, for example by product family or by regulatory category. Confirm whether the deposit liability account is shared across products or split per product, and confirm how that split will appear in the trial balance. Changing it later usually means reposting history, so treat it as a design decision with a named owner. The second question is where accrued interest sits. Fineract's interest posting creates an expense on the institution's side and a payable or accrued liability on the customer side, and finance will want to know whether interest is recognised as it accrues or when it is credited to the account. Ask finance to confirm the accrual convention for each product, then confirm with your Fineract version which accounting mapping options exist for interest and how the journal behaves when interest is posted, including on fixed deposit maturity and on recurring deposit schedules. Fee income needs the same treatment: decide whether account charges, withdrawal fees and penalties are recognised as income on posting, and which income account each charge type uses. The third question is how closed or dormant accounts are handled. Closing a savings account can move a residual balance, clear accrued interest, or trigger a reversal of charges, and each of these creates journal entries that finance must be able to trace. Decide which account receives balances from closed or dormant accounts, who approves the transfer, and how long those balances stay on the books before escheatment or write-off procedures apply. These rules depend on your jurisdiction and your own policies, so confirm them with your legal and finance teams rather than relying on defaults. Before go-live, run one complete product lifecycle in a test environment: open, deposit, interest posting, fee charge, partial withdrawal, maturity or closure. Export the journal entries and have finance reconcile each one against the expected postings and the deposit balance. This is the cheapest point to find a mapping error. The overall chart of accounts design is covered in its own section, so this test should focus on the deposit mapping alone. Confirm the accounting mapping options and journal behaviour for your specific Fineract release, because the available mapping choices and posting logic can change between versions.

Before a savings, fixed deposit or recurring deposit product takes real customer money, the team needs proof that each rule behaves as the product document says it should. The test set should cover the full lifecycle of each product in Apache Fineract, from account opening through to closure, and the expected results should be written down before the test run. Start with account opening at the configured minimum and maximum balances, then test deposits and withdrawals on both sides of each limit, including the exact boundary values. Record which product template and version each test ran against, so a later regression can be traced to a specific configuration change.

Interest and fee tests need hand-calculated expected values. For each product, have a finance or product owner calculate the expected interest for a known balance over a known period using the agreed day-count and posting rules, then compare that figure with what the platform posts when the interest posting job runs on its schedule. Do the same for fee and charge postings, including charges triggered by withdrawals, and for early withdrawal penalties and maturity behaviour on fixed deposits. Include reversals and corrections in the set: reverse a posted transaction, correct a balance, and confirm that interest and ledger entries adjust as the product rules require. Where the expected value and the platform value differ, treat the difference as a defect until the rule owner explains it.

Failing safely is tested separately from correct posting. Confirm that rejected operations, such as a withdrawal below the minimum balance or an operation on a closed account, return a clear error that an operator can act on and that nothing is partially written. Rerun a failed batch step in a non-production copy and check that no interest, fee or ledger entry is posted twice. Then verify access control: log in as a user without product configuration rights and confirm that changes to product definitions are refused. Ask the security owner to confirm which roles and approval steps apply in your deployment, since the permission model depends on how identity and maker-checker controls are set up.

Operations begin the day the first real account is opened. Monitor the duration and failure count of the end-of-day batch jobs against a baseline taken during testing, and set alerts for runs that exceed that baseline or leave failed steps. Each day, reconcile total deposit balances in the sub-ledger against the general ledger balances mapped to each product, and investigate any difference before the next day-end. Back up the PostgreSQL database and the tenant configuration on a schedule that your recovery objectives support, and test restores rather than assuming the backups are usable. Keep a dated change log of every product version and configuration change, so the team can show which rules applied on any given date.

Finally, document each deposit product in a form that operations and audit staff can use without reading the configuration screens. For each product, record the eligibility rules, minimum and maximum balances, withdrawal limits, interest method and posting schedule, fees, early withdrawal and maturity behaviour, and the ledger accounts it posts to. Link each rule to the test case that proves it and to the change log entry that introduced it. Ask your auditors which evidence they expect for product controls, and confirm with them how the documentation and test records should be retained. This document becomes the reference used when a customer dispute, an upgrade or a regulator's question requires the team to explain what the product was supposed to do on a given date.