Why Apache Fineract global configuration settings for production need a formal review
A bank or lender preparing go-live on Apache Fineract needs a formal review of its global configuration before the first customer transaction is posted. Fineract is headless, so it ships no user interface and no operating guardrails of its own: the behavior you get depends on REST API calls, environment variables and the global configuration switches exposed through the API. Several of those switches, including maker-checker, holiday handling, transactions on holidays and job enablement, control how the platform behaves for every tenant and every product. Development defaults are not a production policy, and the review should start from the question of which behavior your institution has approved, not which behavior the platform happens to ship with.
Global settings are also among the hardest changes to reverse once real data exists. A switch that alters how repayments fall on holidays or how approvals are routed can leave loans, schedules and audit trails that were produced under one setting and must be explained under another. Before go-live, record each switch, its current value, the owner who approved it and the evidence that the value was tested in a non-production tenant. The project's README is direct that a production deployment can be complex and time-consuming and that it does not provide a comprehensive production deployment guide, so this record is work your team must produce, not something you will find in the documentation.
The same review belongs after every upgrade. Official Fineract releases are created quarterly, at the end of each quarter, under the ASF release policy, so a platform that stays current will change at that cadence. Release notes and the platform documentation should be checked for new or changed global settings, and the switch register should be compared against the new release in a staging tenant before production is upgraded. Confirm with your implementation team which settings were changed from defaults in your environment, who can change them in production, and how each change is logged and approved.
Which global configuration switches to decide before go-live
This table lists the global configuration switches a go-live review should decide explicitly for Apache Fineract, with the business effect, the risk of accepting the default and the owner of each decision. Defaults are not stated here, so confirm each one in the 1.15.0 documentation and record the chosen value. Treat every row as a sign-off item rather than a setting the implementation team chooses alone.
| Switch | What it changes in business terms | Risk of leaving the default | Decision owner |
|---|---|---|---|
| Maker-checker for sensitive operations | Requires a second authorized user to approve covered changes before they take effect. Confirm which operations the 1.15.0 documentation covers. | A single operator may create and approve the same change, so segregation of duties rests on role design alone. | Chief risk officer or operations head, with security confirming role assignments |
| Holiday repayment rescheduling | Determines whether a repayment due on a holiday moves to another date, and how the loan schedule shown to the customer reflects it. | Schedules, customer notices and collections timing may diverge from what the lending policy expects. | Head of lending products, with finance confirming the accrual impact |
| Transactions on holidays | Controls whether transactions can be posted on dates defined as holidays in the calendar. | Postings on closed days can distort branch-day reports, interest figures and reconciliation with external payment rails. | Operations lead, aligned with the owner of the holiday calendar |
| Job enablement for scheduler jobs | Turns individual background jobs on or off, including jobs that run as part of Close of Business. | A disabled job can stop interest posting or notifications without an alert. An untested job can run against live balances. | Platform owner for operations, with business sign-off for jobs that affect balances |
| Other global settings in the 1.15.0 list | Any remaining switch that changes posting, reporting, access or data handling must also be reviewed. | Unreviewed defaults can change behavior after go-live or after an upgrade without a clear owner. | Implementation lead, with the project sponsor approving the final list |
How to run a global configuration review before go-live
This sequence turns Fineract's global switches from an unexamined default set into a documented, tested and approved configuration. The result is a signed record of every switch value, the business reason behind it, and evidence that loan, savings, holiday and batch behavior match the operating calendar.
Inventory every global switch in the target release
Start by listing every global configuration key exposed by the exact Fineract release you plan to run, including job enablement flags, maker-checker options, holiday and transaction-date behavior, and authentication-related settings. Read the release's own documentation rather than relying on settings you remember from an earlier version, because switches can be added, renamed or retired between releases. Assign each key an owner in your organization. The step is done when the inventory is a single document that lists the key, its current default, its owner and the release it was checked against.
Map each switch to a business decision
For each key in the inventory, write the operational decision it controls, such as whether a second person must approve a change, how a repayment due on a holiday moves, whether transactions can post on a holiday, and which background jobs run overnight. Involve operations, credit, finance and compliance owners, since they own these decisions and not the engineering team. Record the decision, the approver and the reason next to each key. The step is done when every switch has a named business owner and a written rationale, and any switch nobody can explain is flagged for follow-up before it is set.
Confirm the default login has been replaced
Before any tenant is configured, confirm that the built-in development login documented in the project README has been removed or changed on every environment that will hold client data, and that OAuth2 or basic authentication is configured with individual accounts. Check that no shared operator account is used for configuration changes. Verify this on the running instance by attempting the default credentials and confirming they fail. The step is done when the check is recorded with the date, the environment and the person who performed it.
Set values in a non-production tenant
Apply the mapped values to a non-production tenant that mirrors the production configuration as closely as possible, including the same release, database platform and job settings. Record each change in your change log with the previous value, the new value and the approver reference. Avoid changing values by editing the database directly, since that bypasses the audit trail you will need later. The step is done when the non-production tenant reflects the proposed settings and every change is traceable to a line in the inventory.
Test loan and savings flows across a holiday and a COB run
Design test scripts that cover a loan repayment falling on a configured holiday, a savings transaction dated on a holiday, a maker-checker action that must be approved, and at least one full Close of Business run. Execute them on the non-production tenant and compare the results with the expected outcomes written in the decision map. Where a result differs from the expectation, determine whether the setting, the test or the documentation is wrong before changing anything. The step is done when every scripted case has a recorded result, and any deviation has a documented resolution.
Check job enablement against the operating calendar
Compare the list of enabled scheduled jobs with the operating calendar your organization actually runs, including branch hours, batch windows, reporting deadlines and any maintenance freeze. Confirm that jobs needed for interest, charges and COB are enabled, and that jobs which would post unintended entries on non-business days are disabled or scheduled correctly. Review run history from the test tenant to confirm the jobs ran when expected. The step is done when a signed table matches each enabled job to a calendar requirement.
Record approvals and promote the settings
Collect written approval from each business owner named in the decision map, and from the security and compliance owner for authentication and audit-related switches. Store the approved inventory, test results and change log together as the configuration baseline for the release. Apply the same values to production through your normal change process, then verify them against the baseline and repeat the check after every upgrade, since a new release can change defaults. The step is done when production matches the approved baseline and the baseline is stored where it can be audited.
Security controls that depend on global configuration
Several of the controls an auditor will ask about in a Fineract deployment are set outside the code, in configuration and in who can change it. The cards below cover the controls that the documentation and README make visible, so that the team can check each one before go-live and after every upgrade. Whether these controls are adequate for your obligations is a judgment for your auditors and regulators, not for DeployOpen.
Maker-checker as segregation of duties
Maker-checker is the setting that requires a second user to approve certain changes before they take effect, so no single operator can create and release the same change. Decide which actions need approval, such as product and global configuration changes, and confirm the setting is enabled in the target environment. Test it with two named users and record the approval trail as evidence. Ask your auditors which actions they expect to see covered.
Replacing default development credentials
The README shows a default development login of mifos with a matching password, and it states that this must be changed for any real deployment. Remove or rotate that account before any environment holds real client data, including staging copies. Check that no default credential remains in Helm values, compose files, scripts or the tenant configuration. Record the rotation as a dated change so the control can be shown later.
HTTPS-only access with documented SSL settings
The documentation strongly encourages HTTPS only and describes SSL settings through environment variables such as FINERACT_SERVER_SSL_ENABLED. Set these explicitly in each environment rather than relying on defaults, and confirm that plain HTTP is not reachable from outside the network. If TLS terminates at a reverse proxy or load balancer, verify the chain end to end and check how forwarded headers are handled. Review the setting after every upgrade, because configuration can change between releases.
Change control over global settings
Global configuration switches change platform behavior for every tenant, so changes to them need the same review as code. Limit which administrator roles can edit them, keep the list of current values in version-controlled configuration, and require a recorded reason for each change. Compare the live values with the approved baseline on a schedule, and after each upgrade, since a new release can add or change switches. Ask your auditors which change records they will sample.
Scope of responsibility for these controls
Some controls depend on settings that the platform exposes but your organization must choose and operate. Assign an owner for each control, a reviewer who is not the owner, and a review interval set by your own policy. Document which controls come from Fineract, which come from the surrounding platform such as the identity provider or proxy, and which come from your processes. Confirm each assignment with your compliance function before the review is scheduled.
What to confirm for your release and environment
Fineract's global configuration switches are read from your running release, not from this page. The cards below list what to verify for your own version, how each setting is exposed, and how it behaves across tenants and instance types, so the settings you review match the platform you actually run.
Exact switch names and defaults
Confirm the global configuration key names, their default values and their data types against the release you deploy, not against older examples or forum posts. Fineract's current stable line is 1.15.0, but names and defaults can change between quarterly releases. Record the values in your environment after startup, and keep that record with your change tickets so a later upgrade can be compared line by line. Pay particular attention to maker-checker, holiday handling and job enablement, since a default that changed silently can alter how approvals and batch runs behave.
API exposure versus configuration only
Determine, for each switch, whether it can be read and changed through the REST API or only set through environment variables and deployment configuration. Settings that exist only in configuration need a controlled change path, such as a redeployed image or a pipeline change with approval. Settings exposed through the API may be changeable by any user holding the right permission, so confirm which roles can modify them. Document the answer per setting so your change control matches what the platform allows.
Behavior across tenants
Confirm whether each switch applies to a single tenant, to all tenants on the instance, or is stored per tenant in the tenants database. Fineract is multi-tenant, so a setting changed for one institution may or may not affect another. Test this with at least two tenants in a non-production environment before go-live. Check especially any setting that changes holiday or business date behavior, because a mismatch between tenants can produce inconsistent repayment schedules.
Interaction with instance types
Verify how each setting behaves on read, write and batch instances. Scheduler jobs and business date changes run on the batch and write side, while read instances serve queries from replicas that may lag. Confirm which instance types must carry a given setting, whether a setting is honored on instances that do not run jobs, and whether a change needs a restart of every instance. Map the answers to your Kubernetes deployments or equivalent so no instance runs with a different configuration by accident.
Effect of job enablement on batch runs
Confirm which scheduled jobs are switched on by configuration, which the Close of Business process depends on, and what happens when a job is disabled for a period. Batch runs on large deployments can take several hours, so an enablement change made near a cut-off can leave some accounts processed and others not. Ask the vendor or your partner to confirm the job dependency order for your release, and agree a rule for when job changes may be made.
Upgrade regression of settings
After each upgrade, compare the effective value of every global switch with the value recorded before the upgrade. New releases can add switches, rename them or change defaults, and an existing environment may keep an old value that no longer matches the documented intent. Run a regression pass on approval flows, holiday handling and job runs in a staging copy of production data. Treat any unexplained difference as a blocking finding until someone has confirmed its cause in writing.
Keeping global configuration correct after each Fineract upgrade
The global configuration review is not a one-time go-live task. The Fineract README states that official releases are created quarterly, at the end of each quarter, under the ASF release policy, and that end-of-life releases are archived. Each time the image tag changes to a new release, the switches that govern maker-checker, holiday handling and job enablement must be checked again, because a default that was safe on one release may be different on the next. Treat the image tag and the configuration record as one change: no upgrade is complete until the settings have been confirmed on the new version.
Before promoting an upgrade, run the new release against a staging tenant that has been loaded with a copy of your intended production configuration. Export the global configuration for the current production version and for the candidate version, then compare them field by field. Any setting that differs without a deliberate decision is a finding. Pay particular attention to the settings that control approvals, transactions on holidays, and which scheduled jobs are enabled, since those change how money moves and when batch work runs. Confirm the exact export method and API calls with the release documentation for each version rather than assuming they are stable.
Keep a written record of the intended value of every global setting, for each tenant, under version control alongside the deployment manifests. The record should state the value, the reason it was chosen, who approved it, and the Fineract release it was last verified against. Multi-tenant deployments often differ between tenants, so a single shared record hides exceptions. When an upgrade review ends, update the record and file the comparison output with it. Auditors and your own operations team will rely on this trail when they ask why a setting had a particular value on a given date.
Questions buyers ask about Fineract global configuration
How much effort does a Fineract global configuration review take?
The effort depends mainly on how many switches your team needs to decide, how many tenants share the deployment, how many products rely on the behavior those switches control, and how many scheduler jobs you plan to keep enabled. A single tenant with a small product catalog and a short list of decisions is a far smaller exercise than several tenants with different branch rules and holiday calendars. Each switch needs a recorded decision, a test that shows the behavior, and an owner who accepts the result. Ask any partner to break the estimate down by tenant, by switch group and by job, so you can see which items drive the total and which you can trim.
Can our own team complete the global configuration review alone?
Yes, if you have engineers who know the Fineract REST API and the platform's global configuration endpoints, and business owners who can decide how maker-checker, holiday handling and transactions on holidays should behave for each product. The harder part is usually not the setting change itself but proving the combined effect on loans, savings and the Close of Business run. Teams without prior Fineract go-live experience often find the review takes longer than planned because each decision touches several downstream processes. An outside partner is most useful for an independent second review, for test design and for documenting the decisions so auditors can follow them.
What do we need to provide for a configuration review?
The review needs named business owners for lending, savings, operations and finance who can approve each behavior change. It also needs a staging tenant that mirrors production settings, products and holiday calendars, along with representative test data such as loans in several repayment states and savings accounts with posted interest. Access to the current global configuration export, the change history and the list of enabled scheduler jobs is essential. Plan for your own change approval process to run in parallel, because each switch you alter will need sign-off before it reaches production.
Does a Fineract upgrade change the configuration review effort?
Yes. A new release can add switches, change defaults, alter how existing switches behave or change which jobs run. Because Fineract publishes official releases quarterly under the ASF release policy, teams on an active release line will face this review more than once a year. The effort after an upgrade is usually smaller than the first review, but it still requires comparing the old and new settings, rerunning the tests that cover holiday and COB behavior, and confirming that the documented defaults match what your organization intends. Ask whether the upgrade plan includes a configuration diff as a standard step.
Which global configuration switches matter most before go-live?
The switches that most often change customer-facing or financial results are maker-checker approval, holiday repayment rescheduling, transactions on holidays and the enablement of scheduled jobs. Maker-checker determines who can finalize changes to clients, loans and savings. Holiday settings decide when repayments move and whether transactions post on non-business days. Job enablement decides which background processes run during Close of Business. Each of these should be documented with the business reason, the tested outcome and the owner who accepted it, and reviewed again whenever a product or calendar changes.
What should a quote for a Fineract configuration review include?
A quote should follow from a written scope and list the tenants, products, switch groups and jobs in the review, along with the deliverables and the acceptance criteria. Ask for the assumptions about your staging environment, test data and business owner availability, since these often drive the schedule more than the settings themselves. Separate one-time work, such as the first review and documentation, from recurring work, such as retesting after each upgrade or quarterly release. DeployOpen works from a written scope agreed before work starts, and does not publish a price list, so the quote is the place to confirm exactly which items are included and which are your responsibility.
Does a configuration review certify that our Fineract setup is compliant?
No. A configuration review prepares the settings, decisions and evidence that an auditor or certification body will examine, but it does not produce an audit report, attestation or certification. DeployOpen prepares systems, controls and evidence for compliance assessments, and independent auditors and certification bodies make the determination. Ask your compliance lead which records they need, such as the decision log, the test results and the change history, so the review produces evidence in the form your assessor expects.
How DeployOpen scopes and delivers a Fineract configuration review
DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. The cards below follow a configuration review from written scope through handover and ongoing support, so you can see what you receive and what you need to provide.
Written scope before any work
Every review starts from a written scope that lists the Fineract version, the tenants and environments in question, and the global configuration switches to be examined. Scope and deliverables are agreed in writing before work begins, so the boundaries of the review are known to both sides. Ask for the scope document to name which switches are covered and which are explicitly excluded, such as product-level settings or accounting configuration.
Quote follows the scope
DeployOpen does not publish a price list. A quote is produced from the written scope, so the number of tenants, environments, and switches under review, along with any upgrade or retest work, drives its size. Ask the quote to separate one-time review effort from any recurring support or upgrade review, and to state which parts depend on access you provide.
Your environment, your control
The review runs against the Fineract instances in your own infrastructure, including your cloud accounts, data centers or air-gapped networks. You keep control of access, change windows and where evidence is stored. Confirm before work starts which accounts, read access and tenant data handling apply, and whether any review step needs a non-production copy.
Documented findings and change record
Deliverables typically include a record of each switch, its current value, the recommended value, and the reason for any change. Each finding is linked to the environment and version it was observed in, so an upgrade or audit later can be traced. Confirm the exact format and sign-off steps in the scope so that approvals for each change remain with your team.
Hardening that follows the review
Where a switch affects security or control, such as maker-checker or the default development login, the review can be extended to hardening work. That work covers credentials, HTTPS settings and job enablement. Any change to production is agreed as a separate written item, so you can decide whether your own team or DeployOpen applies it.
Retainers for upgrades and reviews
Ongoing support, upgrades and periodic configuration reviews are available as retainers. A retainer suits teams that move between Fineract releases, since global switches can change behavior after an upgrade. Ask what the retainer covers, how it is scoped each period, and how quickly review requests are handled, and check that the retainer does not imply audit or certification outcomes.
