Apache Fineract for SOX ITGC testing

Apache Fineract for SOX IT general controls: what the platform supports and what it does not

Apache Fineract's documented controls support SOX ITGC testing on a lending or deposit core, but SOX scope, control design and the auditor's judgment stay with the company and its external auditors. The controls that matter most for Apache Fineract SOX ITGC work are maker-checker approval, which can be enabled for any state-changing API, an audit of state changes persisted by the platform, batch job run history for Spring Batch and Quartz jobs, and role-based access. These support evidence for access, change and computer operations. They do not, by themselves, decide which applications fall inside ICFR scope, which controls are key, or whether a deficiency is material. Management must make those calls under Section 404 of the Sarbanes-Oxley Act, and the auditor tests the design and operation of whatever management selects.

DeployOpen prepares the Fineract system, its configuration and the evidence packs that support management's assessment. It does not issue audit reports, attestations or certifications, and it does not tell a company whether its controls are effective. Before scoping work, confirm with your auditors which IT general control areas they expect to test, such as program development, program changes, computer operations and access to programs and data, since SEC Release 33-8810 says the relevant areas vary with each company's facts and circumstances. Also confirm whether your company is an accelerated or large accelerated filer, because that determines whether an auditor attestation under Section 404(b) applies at all. Ask for those answers in writing before any configuration of roles, approvals or batch monitoring begins.

Mapping SOX ITGC requirements to Fineract capabilities and configuration

This table compares each SOX-relevant risk or control area against what Fineract provides, the configuration it needs and what the hosting layer must add. No catalog of IT general controls exists, so the scope of your testing depends on your own facts and circumstances. Read each row as a starting point for your control design, not as a finished control.

Requirement area	Fineract capability	Configuration needed	Hosting layer must add
Unauthorized access to data (AS 2110 B4)	OAuth2 and HTTP basic authentication on REST APIs; tenant-scoped requests via Fineract-Platform-TenantId	Replace the default development login before any real use, enforce OAuth2 where your identity provider supports it, and confirm the tenant mapping	Network restriction, identity provider governance, secrets storage and access reviews for the database and tenants database
Excessive privileges and segregation of duties (AS 2110 B4)	Role-based permissions and maker-checker approval for state-changing APIs	Define roles per job function, enable maker-checker for each sensitive command, and confirm which actions remain outside approval	Privileged access management for administrators, periodic access recertification and joiner-mover-leaver records
Unauthorized changes to systems or programs (AS 2110 B4; Release 33-8810 program changes)	Audit of state changes persisted by the platform; Liquibase schema migrations applied on write instances	Keep audit records enabled, restrict who runs migrations, and document which release and configuration baseline is live	Change approval workflow for code, container images and product configuration, plus separate environments and deployment logs
Inaccurate processing and loss of data (AS 2110 B4; AS 2201 B29 computer operations)	Spring Batch job run history; Loan COB job can be enabled or disabled through FINERACT_JOB_LOAN_COB_ENABLED	Decide whether the Loan COB job runs in each environment, retain job run history, and define monitoring of job outcomes	Monitoring and alerting on failed or skipped batch runs, scheduled database backups and tested restore procedures
Computer operations (Release 33-8810; AS 2201 B29)	Scheduled batch processing with Quartz; remote partitioning options documented for large deployments	Document the scheduler configuration, job dependencies and any partitioning design, and keep it under change control	Job scheduling runbooks, capacity monitoring and incident records for failed operations
Transmission and access security (AS 2110 B4 access risks)	Documented SSL settings through environment variables such as FINERACT_SERVER_SSL_ENABLED; HTTPS-only encouraged	Enable SSL and confirm that plain HTTP is not exposed, then record the certificate and cipher settings	Certificate lifecycle, load balancer or gateway TLS policy and evidence of periodic configuration review
Access to programs and data at data conversion (AS 2110 B4; Release 33-8810)	Migration loads run through the platform's own import mechanisms, which leave audit records for persisted changes	Agree the conversion approach, reconciliation totals and sign-off roles before loading data into a production tenant	Retained conversion scripts, reconciliation evidence and restricted access to the migration accounts and staging data
Scope and evidence overall (no ITGC catalog; Release 33-8810)	The platform supplies controls that can be configured and evidenced, but it does not decide which controls matter for your financial reporting	Agree with your auditors which applications, interfaces and data flows are in scope before configuring controls	Your control inventory, owner assignments and periodic testing records for each area

Evidence Fineract produces for SOX ITGC testers and how to keep it

Most of the evidence a SOX ITGC tester asks for comes from three places: Fineract's own records, the logs and databases around it, and the change tickets your team keeps. Each card below names one artifact, what it proves, where it lives and who must keep it. Treat every item as a candidate for your own review, since nothing here is audit-ready until your team and your auditor have tested it.

User access listings and role assignments

A point-in-time export of Fineract users, their assigned roles and their permissions shows who could act in the system. It supports testing of user provisioning, periodic access review and privileged access. Fineract holds the user and role data, while your identity provider or directory holds the joiner, mover and leaver approvals that explain each change. Check that the export is taken with a timestamp, that it covers every tenant, and that any shared or default accounts are documented. Retention sits with your IAM team, which must keep both the export and the approval trail.

Maker-checker approval records

Where maker-checker is enabled for a state-changing API, Fineract records the request, the approver and the decision, so testers can see that a second person reviewed a sensitive action such as a product or rule change. Confirm which endpoints you have enabled it for, since the control only covers what you switch on. Pull samples for both approved and rejected requests. Retention sits with the application owner, who should export records on a schedule rather than rely on the live database.

State-change audit trail

Fineract persists state-changing commands as an audit of all state changes, which gives testers a record of who changed what and when for transactions and master data. This is the main evidence for showing that changes were authorized and not made outside the application. Verify that the audit tables are readable only by the administrators you intend, and that they are included in your database backup scope. Retention sits with the database team, and the schedule should match the retention period your SOX policy sets.

Loan COB job run history

Fineract batch jobs run on Spring Batch with Quartz scheduling and keep job run history. For the Loan COB job, this history shows that the close of business ran on each business day, when it started and finished, and whether it failed or was rerun. Testers use it to support reliance on automated loan accruals. Confirm whether the Loan COB job is enabled through FINERACT_JOB_LOAN_COB_ENABLED in every environment, and document any disabled period with its reason. Retention sits with the operations team, which should export run history and job logs for each reporting period.

Release and Liquibase migration logs

Each release and database change leaves a record: the deployed version, the Liquibase changelog executed against the database, and the pipeline log showing who approved promotion. Together these support testing of change management for program changes. Liquibase runs only on write instances and can run separately under the liquibase-only Spring profile, so capture logs from that step as well as the application rollout. Match each deployed version to a change ticket. Retention sits with the platform or release team and should cover every environment, not production alone.

Configuration change records

Product definitions, charges, accounting mappings and business rule settings drive how automated controls calculate results. Testers need a record of each change, the before and after values and the approver. Keep configuration in version-controlled files or exported snapshots wherever your deployment allows, and reconcile them to the live tenant. Changes made directly in the user interface without a ticket are a common finding, so compare the audit trail against the change log each period. Retention sits with the product or finance systems owner, who signs off the configuration baseline.

Data conversion reconciliation reports

When balances and client records move into Fineract, the reconciliation report compares source totals with loaded totals for loans, savings and the general ledger, and records every exception and its resolution. It supports testing of data conversion for completeness and accuracy, which matters where migrated balances feed financial statements. Sign off each reconciliation by someone independent of the load, and keep the source extracts. Retention sits with the migration lead for the life of the conversion evidence your auditor may request.

How privileged access and change approval are split between Fineract and your environment

Fineract authenticates API callers with OAuth2 or HTTP basic authentication, and it stores the users and roles it authorizes. It does not run your joiner, mover and leaver process. The README ships a development login named mifos with a default password, and that login must be replaced before any real deployment. Requests are also scoped by tenant through the Fineract-Platform-TenantId header, so access reviews must cover each tenant, not only the default one.

Default login removal: Confirm that the mifos account is disabled or its credentials rotated, and keep the change as dated evidence.
Authentication model: Confirm whether your deployment uses OAuth2 through an identity provider or basic authentication, and record which one is in force.
Tenant scoping: Confirm which tenants exist in the tenants database and who holds access to each one.
Identity lifecycle outside Fineract: Confirm that joiner, mover and leaver requests are approved and removed in your identity provider, with the Fineract user record following that process.
Privileged accounts: List accounts that can change users, roles or configuration, and confirm that each one has a named owner.

Before testing, confirm with your own environment which identity source Fineract trusts and who can change that trust setting.

Configuration sequence for SOX ITGC readiness on Fineract

This sequence sets the scope, access, change, batch and data conversion controls that a SOX IT general controls assessment will test on a self-hosted Fineract core, and it ends with an evidence calendar tied to fiscal year end.

Scope financial applications and assertions with the auditor
Agree with the external auditor and your SOX program owner which Fineract environments, interfaces and accounting outputs affect financial reporting, and which only affect operations. SEC Release 33-8810 says management evaluates only the IT general controls needed for other controls that address financial reporting risks. Write down the in-scope ICFR assertions, the control areas (program changes, computer operations, access to programs and data) and the owner for each. Done means a signed scope memo that names each Fineract tenant, database and accounting feed in scope.
Replace default credentials and enforce HTTPS
Before any user is created, remove the development login shipped in the README and replace it with named, unique administrative accounts. Confirm that OAuth2 or basic authentication is configured for each tenant and that HTTPS is enforced using the SSL settings the documentation exposes through environment variables such as FINERACT_SERVER_SSL_ENABLED. The IT team should keep the configuration as code and record who approved it. Done means a configuration review shows no default credentials remain and every external endpoint rejects plain HTTP.
Define roles and enable maker-checker
Map each job function to a Fineract role with the minimum permissions it needs, and document the business owner who approves each role. Fineract supports maker-checker approval that can be enabled for any state-changing API, so turn it on for product definitions, accounting mappings, user and role changes and any other API that affects financial records. Test that a maker cannot approve their own request, and that IT administrators do not hold both product-setup and approval rights. Done means a role matrix, a maker-checker configuration export and a test log showing a rejected self-approval.
Separate build, test and production instances
Run separate Fineract environments for build, test and production, each with its own database and tenants, and keep production changes flowing only through the approved release path. Restrict who can deploy to production and log each deployment against a change ticket. Because Fineract releases are quarterly under the ASF release policy, record which release and configuration version is running in each environment. Done means an environment inventory, a deployment access list and a sample change record that links a release to its approval.
Configure the Loan COB job and monitor run history
Confirm the Loan COB job setting through FINERACT_JOB_LOAN_COB_ENABLED and document whether it is enabled in each environment. Fineract batch jobs run on Spring Batch with Quartz scheduling and keep job run history, so define who reviews that history each business day, what counts as a failed or incomplete run, and how exceptions are escalated and resolved. Keep the review sign-off as evidence. Done means a documented monitoring procedure, a sample of reviewed run history and a record of any exception with its resolution.
Plan data conversion with reconciliation evidence
Before loading legacy data, agree the reconciliation method with finance: record counts, balances by product and office, and ledger totals compared between the source system and Fineract. Keep the import files, the load logs and the signed reconciliation as evidence, and resolve differences before go-live. Restrict who can run the conversion and require maker-checker approval for corrective entries. This addresses the AS 2110 risks of processing inaccurate data and potential loss of data. Done means a reconciliation workbook signed by finance and IT and a log of every correcting entry.
Set an evidence calendar tied to fiscal year end
Rule 13a-15(c) requires management to evaluate ICFR as of each fiscal year end using a suitable, recognized framework, so schedule evidence collection and control testing backward from that date. List each control, its owner, the evidence type (access reviews, change tickets, batch history, reconciliations, release records) and the frequency agreed with the auditor. Store evidence in a location the audit team can access without altering it. Confirm exact review timing with your auditor and internal audit rather than assuming it. Done means a calendar approved by the control owners and the auditor, with a first evidence pull completed.

What Fineract does not cover for SOX ITGC testing

Fineract's application controls are only part of an ITGC evidence set. The cards below mark what the project leaves to your team, your hosting layer and your auditors, so control design and evidence ownership are settled before testing starts.

No published ITGC catalog

Neither the SEC nor the PCAOB publishes a catalog of IT general controls. SEC Release 33-8810 says the relevant areas vary with each company's facts and circumstances, so your team must define which program, change, operations and access controls support reported financial figures. Document that scoping decision for Fineract before the auditor asks for it, and confirm the design with your external auditor.

No access review campaigns

Fineract is a headless application with REST APIs and no built-in user interface. It does not run periodic access recertification, so the review of who holds which roles in each tenant must come from exports and reviews your team runs. Plan that review cycle and its sign-off record as part of the ITGC design.

Identity lifecycle sits outside Fineract

Joiner, mover and leaver processing, privileged account vaulting and log retention are owned by the hosting layer. Fineract can authenticate users and record actions, but the upstream directory, approval workflow and vault decide who receives access and how privileged credentials are checked out. Confirm which system is the source of truth for each Fineract user before testing.

No comprehensive production guide

The Fineract README states that the project does not provide a comprehensive production deployment guide and that production deployments can be complex and time-consuming. Your change records, build baselines and hardening standards for the database, network and secrets must therefore be written by your team or a partner, then tested as part of the general controls over computer operations.

Event publishing is off by default

Fineract can publish business events such as ClientCreated to ActiveMQ, other JMS brokers or Apache Kafka, but the feature is disabled by default. If your reconciliation or monitoring evidence depends on those events, enabling them is a configured change that needs approval, a record of the broker's retention settings and a test of what reaches the consumer.

Auditors form the opinion

Under PCAOB AS 2201, the external auditor tests internal control over financial reporting, and under Section 404 the auditor attestation applies only to certain filers. DeployOpen prepares systems, controls and evidence for that testing but does not issue audit reports, attestations or certifications. Agree the evidence list with your auditor early.

Evidence for data conversion at migration and why it matters to ICFR

Opening balances are where a Fineract go-live first affects financial reporting, so the controls for conversion need to produce proof of completeness and accuracy before any balance is relied on. PCAOB AS 2110 (paragraph B4) lists processing inaccurate data and potential loss of data as IT risks to internal control over financial reporting. A conversion that drops loan schedules, mis-maps savings balances or loses a batch of client records would flow straight into the ledger and into every automated control that reads it. The auditor will want to see that someone compared the source and target, not just that the load finished.

Build the evidence around an opening balance reconciliation signed by the data owner, not by the team that ran the load. Reconcile record counts and totals per product, per office and per currency between the legacy system and Fineract, and tie the resulting general ledger opening balances to the legacy trial balance. Record each difference, its cause and its resolution. Ask the data owner, in writing, to confirm that the reconciled population is complete. Keep the reconciliation workbook, the query or script that produced each figure, and the approval with its date under change control, since it is the document an auditor will sample first.

Retain the load logs for every conversion run, including failed and re-run attempts, with the source extract identifier, the Fineract version and the operator. Confirm with your migration partner which import paths produce which logs, and make sure the post-load Close of Business Day run is observed and its job history is kept, because a clean reconciliation that is not followed by a successful COB does not yet show that the books are operating. The migration pages cover the supported import tooling; this section is about proving what that tooling did.

Questions finance and IT leaders ask about SOX ITGCs on Fineract

Does Apache Fineract make us SOX compliant?

No. Fineract is open-source software, and SOX compliance is a property of your internal control over financial reporting, which management designs, operates and evaluates each year. Fineract supports controls that management can design around: it records state-changing commands as an audit of changes, supports maker-checker approval for state-changing APIs, and keeps batch job run history. Under Section 404 (15 U.S.C. 7262), management assesses ICFR, and for accelerated and large accelerated filers that are not emerging growth companies, an external auditor attests to that assessment. Your auditor decides which IT general controls matter for your environment, and no SEC rule or PCAOB standard publishes a fixed catalog of them. Treat Fineract as one component in a control design that your team owns and your auditor tests.

What drives the cost of SOX ITGC work on Fineract?

Cost follows the scope your auditor and management set. The main drivers are the number of in-scope applications and hosting layers, the number of roles and access paths that need to be documented and tested, the count of integrations that touch financial data, the volume of data to be converted at migration, and whether the auditor expects walkthroughs of each control rather than sample-based testing of records. Costs split into one-time work (scoping, role catalog design, control design, migration evidence, initial walkthroughs) and recurring work (quarterly release control evidence, periodic access reviews, COB job monitoring and annual assessment support). When you request a quote, ask for each item to be listed separately with its in-scope system, the evidence it produces and who performs it. DeployOpen does not publish prices, and the quote follows from the written scope.

How long does a SOX ITGC engagement on Fineract take?

Duration depends on your fiscal calendar, the number of in-scope systems and how much of the control environment already exists in written form. A team that needs to design controls before an assessment period starts will need more time than one that is testing controls already in operation. Because most engagements are fixed-scope, the deliverables and timeline are agreed in writing before work starts, so ask for a dated plan that aligns with your fiscal year end, your auditor's interim and year-end testing windows, and the quarterly Fineract release cycle. Confirm with your external auditor which periods they will test and what evidence they need in each period before fixing the schedule.

What do we need to provide before the work starts?

The work depends on information only your organization holds. Prepare the following before scoping:

Named process owners for financial reporting, access management, change management and computer operations
A current role catalog for Fineract, listing each role, its permissions and who is assigned to it
Access data exported from Fineract and your identity provider, including user lists, role assignments and recent changes
Change records for releases, configuration changes to products and accounting setup, and any emergency changes
COB job history, batch failure records and the monitoring process currently in use
Migration plans and reconciliation records if data has been or will be converted
A named contact at your external auditor who can confirm the control expectations and testing approach

Can our own team run SOX ITGC testing on Fineract without a partner?

Yes, if your team already knows SOX testing and has working knowledge of Fineract's role model, maker-checker settings, batch jobs and deployment layers. The work is mostly disciplined documentation and sampling, and many internal audit and IT controls teams can run it. A partner adds value where the team lacks Fineract administration depth, needs to build evidence collection into the platform itself (for example, scripted access exports or job-history extracts), or must combine control design with implementation changes. Be clear about who signs off. Management owns the conclusion on ICFR, and your auditor performs the attestation where it applies, so the partner prepares systems, controls and evidence but does not issue an audit opinion.

Which Fineract controls recur every quarter and which are one-time?

One-time work includes scoping, the role catalog, the initial control design, the first walkthroughs and the migration evidence for data conversion. Recurring work includes access reviews against the role catalog, review of privileged account use, change approval evidence for each release and each product or accounting configuration change, and COB job monitoring with exception handling. Apache Fineract publishes releases quarterly at the end of each quarter according to its release policy, so plan quarterly evidence collection for upgrades, and confirm with your team which release line you run, because end-of-life releases are archived. Ask any partner to show which recurring tasks it will perform and which ones your staff will perform.

Where should we start with Fineract access and change controls?

Start with the role catalog and the list of people who can change products, accounting setup and users, because these are the areas where unauthorized access or changes would affect financial reporting. Map each privileged path, including direct database access, batch administration and deployment pipelines, not only the Fineract user interface. Then confirm that maker-checker is enabled for the state-changing APIs your control design relies on, and confirm the COB job setting in your environment (the Loan COB job can be enabled or disabled through FINERACT_JOB_LOAN_COB_ENABLED), so you know what runs and what evidence exists for each run. Verify these settings in your own environment with your vendor documentation before relying on them for testing.

How DeployOpen scopes and delivers SOX ITGC support for Fineract

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and this work applies the same method to a Fineract core that supports SOX ITGC testing. The written scope defines which control areas, environments and evidence are covered before any build begins.

How we scope

Confirm with management which financial reporting systems and Fineract tenants fall within the ICFR evaluation scope.
Agree in writing which access, change, computer operations and data conversion controls the engagement covers.
Map each control to the owner, the Fineract feature or hosting layer that operates it, and the evidence the auditor will request.
Record the scope in a fixed-scope agreement, with deliverables and timelines agreed before work starts.

How we build

Configure user roles, maker-checker approval and privileged access paths so segregation of duties is enforced in the platform.
Set up change records for releases and product configuration, with test environments separated from production.
Configure COB job monitoring, job run history and alerting so each business day close leaves reviewable evidence.
Test access reviews, change approvals and batch runs in a controlled environment before management relies on them.

How we hand over

Deliver a control narrative, control matrix and evidence collection procedure written for the client's own audit team.
Document the configuration baseline, including authentication settings, batch job flags and environment variables used in production.
Walk through the evidence pack with control owners so they can produce samples for the auditor without DeployOpen.
Confirm with your external auditor which evidence formats and sample sizes they accept before handover is accepted.

How we support

Offer ongoing support, upgrades and testing as a retainer after the initial engagement closes.
Review control changes whenever Fineract releases are applied, since release records feed the change management control.
Keep access reviews and COB monitoring running on a recurring schedule agreed with the client's control owners.
Reassess the scope with the client when systems, hosting or reporting obligations change.

Apache Fineract for SOX IT general controls