Open source core banking for SOX IT general controls

Open source core banking for SOX IT general controls: what the auditor will test

Section 404 of the Sarbanes-Oxley Act requires management to assess internal control over financial reporting (ICFR) every year, and for accelerated and large accelerated filers that are not emerging growth companies, an auditor attests to that assessment. Auditors test the IT general controls (ITGCs) over any system that produces financial figures, and a core banking system holding loan balances, interest accruals and general ledger postings is one of those systems. A self-hosted Apache Fineract core does not remove that testing. It moves the operating burden of the controls, including access, change, batch processing and data integrity, onto the institution's own teams and records.

No SEC rule or PCAOB standard publishes a catalog of ITGCs. SEC Release 33-8810, *Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting*, says the IT controls that matter vary with each company's facts and circumstances, and management only needs to evaluate the ITGCs necessary for the proper operation of controls that address financial reporting risks. PCAOB Auditing Standard 2110, *Identifying and Assessing Risks of Material Misstatement*, asks the auditor to understand the IT general controls important to automated controls, and PCAOB Auditing Standard 2201, *An Audit of Internal Control Over Financial Reporting That Is Integrated With An Audit of Financial Statements*, makes effective general controls over computer operations a condition for benchmarking automated application controls. The first task for a CFO or CISO is therefore to map which Fineract modules, databases and batch jobs feed the financial statements, and to document which ITGCs those mappings require before anyone designs a control.

Which SOX ITGC requirements a self-hosted Fineract core must satisfy

This table maps each SOX IT general control area to what a self-hosted Fineract core has to do and how to configure it. Read each row as a control question an assessor will ask, with the Fineract setting that supports the answer. The main takeaway is that instance separation, tenant scoping and migration evidence carry most of the weight, and the SEC and PCAOB sources do not prescribe a fixed control catalog, so scope should be agreed with your auditors.

ITGC area	What the core must do	How to configure it and what to evidence
Privileged and direct database access	Limit who can connect to the PostgreSQL database holding ledger and loan records, so IT staff do not gain access beyond their duties (AS 2110, B4).	Restrict direct database roles, route changes through the API, log privileged sessions, and review access lists on a set cadence with sign-off.
Change approval and program changes	Control how Fineract versions, configuration and product definitions move into production (Release 33-8810 program change area).	Promote tested builds through separate environments, require approval records for product and accounting changes, and keep quarterly release adoption documented.
End-of-day batch scheduling and computer operations	Run interest, accrual and end-of-day jobs on the batch instance, on schedule, with failures visible and reruns controlled (AS 2201, B29).	Run one batch instance separate from write and read instances, monitor job completion, record job logs and reconcile outputs to the general ledger each day.
Access controls as the basis for relying on automated control benchmarks	Keep access controls strong enough that an auditor can rely on a benchmark of automated controls for a period (AS 2201, B33).	Use tenant-scoped access through the Fineract-Platform-TenantId header, separate user roles per tenant, and test access controls before each benchmark period.
Schema migrations and write instance control	Ensure database schema changes run once, under change control, and only where the team intends (Fineract documentation on Liquibase).	Run Liquibase only on write instances, or separately with the liquibase-only Spring profile on Kubernetes, and retain migration logs with approvals.
Data migration controls	Prevent inaccurate processing, data loss and inappropriate manual intervention when loading accounts and balances (AS 2110, B4).	Reconcile migrated balances to opening general ledger entries, run trial migrations, keep reconciliation reports, and document any manual correction with a reviewer.
Read instance and reporting integrity	Keep reporting queries from affecting ledger writes and ensure reported figures match system-of-record data.	Point reporting at read replicas, reconcile report totals to ledger balances, and confirm with your auditor which reports are in scope as key reports.

How the ITGC areas differ across the core's operating environments

The production write instance is where transactions are posted, balances change and product rules take effect, so it carries the most direct financial reporting risk. Fineract's documentation says Liquibase database migrations run only on write instances, which makes schema change a write-tier event that needs its own change record. Access to the write tier and its PostgreSQL database is the area where privileged and direct database access controls matter most, because a privileged user can change posted data without passing through the application's audit trail. The institution must own the controls below.

Privileged access to the database: Named accounts, approval for each elevated session, and logging of direct SQL access to the loan and savings tables.
Schema and migration changes: Liquibase changesets tied to approved change tickets, with the same review applied to every release.
Program change approval: Quarterly Fineract releases and configuration changes reviewed, tested and approved before promotion.
Segregation of duties: Developers and DBAs who build changes are not the people who approve or deploy them to production.
Monitoring of unauthorized data changes: Alerts on updates made outside the application, which the PCAOB's risk standard lists as a central IT risk.

Confirm with your auditor which production access events and change records they expect to sample, and how long those logs must be retained.

Why a self-hosted Fineract core shifts ITGC ownership to the institution

A self-hosted Fineract core moves every IT general control from a vendor's data center into the institution's own control scope. Apache Fineract is a headless application with REST APIs and no user interface of its own, so the access paths that auditors will test are the APIs, the front end the institution chooses (the Mifos X web application is the one the README uses in its Kubernetes example), the tenants database that maps each Fineract-Platform-TenantId header to a tenant connection, and the PostgreSQL layer underneath. Each of these is a route to change customer balances, loan schedules or accounting entries, so each belongs inside the scope of access, change and privileged-access testing. Before fieldwork, the reader should produce a written inventory of every path, including service accounts used by integrations and any batch or read instances that connect to the same database.

The database choice also shapes control design. The Fineract README names PostgreSQL as the recommended database and states that MariaDB and MySQL are deprecated under proposal FSIP-9, and the official Docker image ships only the PostgreSQL JDBC driver. Institutions that already run MySQL or MariaDB for other systems should confirm early whether that is a platform standard they must carry into the core, and whether their database administration tooling, audit logging and backup procedures are documented for PostgreSQL. Direct database access is the control area where an administrator can change data without passing through the application's audit trail, so the choice of engine determines which logging, role and privilege settings must be designed and evidenced.

The Fineract project itself does not carry the burden of production design. The README warns that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. That means decisions on change approval gates, privileged role separation, batch scheduling for end-of-day processing, and migration reconciliation are the implementer's responsibility, and the auditor will test whatever the institution documents. Before signing a scope, the reader should ask the implementation partner which of these controls they will design, which they will document as operating procedures, and which will remain the institution's own tasks, and should have that split written into the statement of work.

Which open-source components carry the core's ITGC evidence

No single component produces SOX IT general control evidence. The core, database, deployment layer, front end and logging and identity layer each generate part of the record, and the institution must confirm how those parts fit together. The cards below cover what each component contributes and what to verify before relying on it.

Apache Fineract as the core

Apache Fineract 1.15.0 is the core banking application, licensed under Apache-2.0 and released quarterly at the end of each quarter. Its REST APIs and configurable products define the transactions that auditors will trace into the general ledger. Confirm which Fineract version and release cadence your institution will adopt, how each upgrade is tested and approved under change management, and who maintains the custom code layered on top. The project itself does not provide a production deployment guide, so the control design is the institution's responsibility.

PostgreSQL as the recommended database

The Fineract README names PostgreSQL as the recommended database, and MariaDB and MySQL are deprecated under FSIP-9. Database access is where privileged and direct access risks concentrate, because anyone who can write to tables can bypass application controls. Confirm how production database accounts are separated, how DBA access is logged and approved, how schema changes are reviewed, and whether database audit logs are retained outside the database host. Ask your implementation partner how Liquibase migrations are controlled and recorded.

Mifos X as a front-end example

Fineract is headless and ships without its own user interface. The Fineract README points to the Mifos X web application as the front end used in its Kubernetes example. Each user interface is an additional access path that needs its own role mapping, authentication and logging. Confirm which front end you will use, whether it is the Mifos X application or a custom build, and how staff roles in the front end map to Fineract permissions, so that segregation of duties can be demonstrated for both channels.

Kubernetes for instance separation

The Fineract documentation describes read, write and batch instance types set by environment variables, and recommends one write instance, one batch instance and multiple read instances on read replicas for high load. Container orchestration lets you enforce that separation, restrict which workloads can write, and control who can change deployment configuration. Confirm how deployment manifests are version controlled and approved, how the batch instance's schedule is configured and monitored for end-of-day runs, and how Liquibase migrations are run only from the designated write or migration workload.

Centralized logging and identity layer

Access controls and activity logs over the core depend on components the institution chooses, not on Fineract alone. A central identity provider can enforce multi-factor authentication and remove access when roles change, while a central log store can collect application, database, container and administrator activity in one place with retention the institution sets. Confirm which identity provider and logging platform will be used, that privileged activity is captured by both, that logs cannot be altered by the teams they monitor, and that access reviews can be produced from them on a set schedule.

How end-of-day batch and migration controls are sequenced

This sequence keeps scheduled end-of-day processing and schema or data changes under change approval, so each run can be traced to an authorized owner and a reconciled result that an auditor can test.

Confirm the batch instance owns scheduled end-of-day work
Before each end-of-day cycle, the platform team checks that the Fineract batch instance is the only process configured to run scheduled jobs, and that read and write instances are not picking up those schedules. Fineract instance types are set by environment variables, so the check is a review of the deployed configuration against the approved baseline, not an assumption. The output is a dated configuration record, reviewed by someone other than the person who maintains it, showing the instance roles in production.
Approve every schema change before it reaches production
Database changes in Fineract are applied through Liquibase migrations, and the platform team submits each migration as a change request with the scripts, the target environment and the rollback approach. An approver who is independent of the author signs off before deployment. Evidence is the approved ticket linked to the migration version and the deployment record, which together show that no schema change was made outside the change process.
Run migrations only on the write instance
Fineract runs Liquibase database migrations only on write instances. On a Kubernetes deployment, the team can run them as a separate job using the liquibase-only Spring profile, so that application pods do not apply schema changes during normal startup. The operator records which job ran, against which database, and the exit status. Logs from that job are retained with the change ticket so the auditor can see that migrations ran once, under approval, and from the designated path.
Rehearse data migrations in non-production first
Bulk loads of clients, loan and savings accounts, schedules and balances are rehearsed in a non-production tenant that mirrors the production configuration. Each rehearsal produces reconciliation reports comparing source record counts and balances with what Fineract holds, including opening balances against the general ledger. Any difference is logged, investigated and resolved before the production load is approved. The rehearsal reports and their sign-off form the baseline evidence for the production run.
Reconcile the production load and approve cutover
During the production data load, the same reconciliation reports are produced against the production tenant and compared with the approved rehearsal results. Finance and the business owner sign the reconciliation, and the change approver authorizes the cutover only when balances tie to the general ledger. Discrepancies stop the cutover until resolved under the change process. The signed reconciliation and cutover approval are the control evidence for the migration.
Monitor the first end-of-day run against the baseline
After the first scheduled batch run on the new configuration or data, operations reviews the job outcome, processing exceptions and key totals against the reconciliation baseline. Manual intervention, such as re-running a job or editing records to clear an exception, is raised as a logged incident and approved by someone outside the operations step. The output is a signed run report that records job status, exceptions and any manual actions with their approvals.
Retain signed evidence for each step
The team stores the configuration record, change tickets, migration logs, rehearsal and production reconciliation reports, cutover approval and run reports in a controlled repository with restricted write access and a defined retention period set with the compliance owner. Each item is signed or approved by the named role, so the chain from request to result can be traced. Ask the auditor early which evidence format and sampling approach they expect, since the sequence only supports ICFR if the records are complete and retrievable.

What auditors ask for and which component produces it

What evidence do auditors ask for when reviewing user access to Fineract?

Auditors ask for periodic access reviews that show who holds each Fineract role, who approved it, and when it was last recertified. The identity layer and the Fineract role and permission configuration produce this evidence, while the institution's identity governance process signs it off. Retain the review exports, approval records, and the list of users who left or changed roles between review cycles. Access controls are one of the elements that determine how long an auditor can rely on a benchmark of an automated control under PCAOB AS 2201, so weak access review evidence can shorten that reliance window. Confirm with your auditor which review frequency and sample sizes they expect for your scope.

How do privileged database sessions get logged for a self-hosted core?

Privileged and direct database access is the area where auditors look hardest, because IT staff holding access beyond what their duties require can break segregation of duties. The database audit logging, the bastion or session recording tool, and the ticket that authorized each session produce the evidence. Retain session logs, the approval that opened each privileged session, and a periodic review showing that someone other than the operator checked them. Confirm which logging features your PostgreSQL build and hosting platform support before you commit to a design.

Which change tickets and approvals does an auditor expect for Fineract releases?

Auditors expect each change to Fineract configuration, code, or infrastructure to have a ticket, a documented approval by someone independent of the builder, and evidence that the approved change is the one deployed. The ticketing system, the version control history, and the pipeline approval gate produce this evidence. Retain tickets, pull request approvals, and the approval record for each production change, including quarterly Fineract upgrades that the project publishes at the end of each quarter. The SEC's guidance names program changes as a general control area management may consider, so document how you decide which changes are in scope.

What deployment records show that only approved builds reached production?

A deployment record links a production release to a specific build, its approved change ticket, the time it was deployed, and the person or pipeline that deployed it. The CI/CD pipeline logs, the container image registry with digests, and the deployment tool history produce this evidence. Retain build artifacts, image digests, and deployment logs for the audit period. Reconcile these records against the change tickets each quarter so that any deployment without a ticket is visible. Ask your implementation partner how they separate build, approve, and deploy duties in your pipeline.

What batch run logs prove end-of-day processing completed correctly?

Batch run logs show that each end-of-day job started, ran in the expected order, completed, and produced the expected output count and totals. The Fineract batch instance logs, the job scheduler history, and the exception queue produce this evidence. Fineract runs read, write, and batch instances, and Liquibase migrations run only on write instances, so retain logs from each instance type. Keep the scheduler configuration under change control, and retain the completion report and the reconciliation to the general ledger for each business day. Ask your partner how failed jobs are re-run and how that re-run is recorded.

What migration reconciliation sign-offs does an auditor need for data loads?

Auditors need a signed reconciliation showing that loaded clients, loan and savings accounts, schedules, and opening balances match the source system and the general ledger. The migration reconciliation reports, the trial migration results, and the named sign-offs from finance and the business owner produce this evidence. Retain the source extracts, the reconciliation reports for each trial and the final load, the exception log, and the cutover approval. Migration controls protect against processing inaccurate data and loss of data, which the PCAOB lists as IT risks to internal control over financial reporting. Confirm with your auditor how they want opening balances tied to the general ledger.

How do backup and restore tests become audit evidence?

A restore test is evidence only when it records what was restored, when, by whom, and whether the restored data reconciled to the source. Backup job logs, restore test records, and reconciliation results from a restored environment produce this evidence. Retain the backup schedule, the restore test plan, the results, and any defects raised. Test restores on a schedule that matches your recovery commitments, and document the outcome even when a test fails. Computer operations is one of the general control areas management may consider, so the record should show it covers the production core and its batch processing.

What tooling alone does not satisfy in an ITGC audit

A self-hosted Fineract deployment gives the bank full control of the software, but auditors test whether people, approvals and records around it work as designed. The cards below cover the gaps that no open-source component closes on its own, and the evidence the bank must own. DeployOpen prepares controls and evidence; independent auditors test them.

Privilege assignment stays with the bank

Fineract ships REST APIs and a tenant model, but it does not decide who may act as an administrator, who may post manual journal entries, or who may connect directly to the PostgreSQL database. Those rights come from the bank's identity provider, database roles and application roles. Under PCAOB AS 2110, IT staff with access beyond their duties can break segregation of duties. Check that each privileged role has a named owner, a documented purpose and a periodic access review with evidence.

Change policy needs more than a pipeline

A CI/CD pipeline enforces steps, but it does not define who approves a change to a loan product rule, a fee calculation or a database migration. Auditors look for a written change policy, a request tied to a ticket, separation between developer and approver, and proof that emergency fixes were reviewed afterward. Confirm with your partner which approvals the pipeline records and which ones still rely on people signing off in a ticket.

Batch schedules need owners and monitoring

End-of-day processing in Fineract runs on batch instances, and the platform does not decide who may change the job schedule, who watches for failed or partial runs, or how a rerun is approved. Each batch job needs a named business owner, a documented schedule, alerting on failure and a log of reruns. Without that, an auditor cannot rely on the completeness of the daily accounting cut-off.

Migration reconciliation needs judgment

When clients, loan schedules and balances move into Fineract, the platform can load data but cannot decide whether the opening balances agree with the legacy general ledger. Finance and operations must sign off on reconciliation differences, approve any manual adjustment and confirm the cutover results. Auditors will ask for the reconciliation workpapers, the approvals and a record of rejected or corrected records, because an unexplained difference can mean inaccurate processing or loss of data.

Direct database access needs compensating records

PCAOB AS 2110 lists unauthorized changes to master data and the risks of many users sharing a common database among IT risks to internal control. A self-hosted core gives the bank the database, so the bank must decide who can run direct SQL, how those sessions are logged and how each change is traced to an approved request. Confirm whether database audit logging and session recording are enabled and where those logs are retained.

No platform issues a SOX opinion

Section 404 requires management to assess internal control over financial reporting each year, and external auditors test that assessment under PCAOB AS 2201. No open-source platform, vendor or implementation partner issues an audit report or attestation. DeployOpen prepares controls, configurations and evidence for the bank's assessment, but the bank's management and its independent auditors decide what is effective. Ask any partner to state this boundary in writing.

What does a SOX ITGC implementation for self-hosted core banking cost and require?

What drives the cost of SOX ITGC work for a self-hosted core banking system?

The cost is driven by how many ITGC areas are in scope, how many environments must be controlled, how many integrations feed or read the core, and how much testing and evidence collection is automated. Costs fall into two groups. Implementation is one-time work: documenting control design, configuring access, change approval and job scheduling controls, and building evidence collection. Operation recurs: periodic access reviews, change sampling, backup restore tests and support for auditors. Ask for a quote that lists each ITGC area, each environment (production, batch, read replicas, non-production), each integration with its control owner, and whether evidence collection is scripted or manual. Costs rise sharply when controls are added after the core is live, because configuration and history must then be reconstructed.

How long does a SOX ITGC implementation take for a core banking system?

Duration depends on the written scope, not on a fixed figure. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the timeline follows from the ITGC areas, environments and integrations listed in that scope. A narrow scope covering access and change control on one environment will take far less time than a scope that adds batch scheduling, data migration controls and multiple environments. Ask any partner for a milestone plan tied to deliverables, and check whether it includes a period in which controls operate before the auditor relies on them, since an auditor needs to see controls working over time.

What does the institution need to provide for a SOX ITGC engagement?

The institution must provide people and records that only it can supply. Plan for named process owners for access, change management, batch operations and data migration, each with authority to approve or reject. Appoint an auditor liaison who can answer requests quickly and keep the audit calendar. Provide a complete access inventory: every account with direct database or operating system access, every privileged role, every service account, and every person with vendor support access. Without a current inventory, access reviews cannot be completed and the control cannot be evidenced. Confirm these responsibilities in the scope document before implementation starts.

Can an in-house team implement SOX ITGCs for self-hosted Apache Fineract?

Yes, if the team has the skills and time, and many institutions choose that route. The Apache Fineract README warns that a production deployment can be complex, costly and time-consuming, that the project does not provide a comprehensive production deployment guide, and that organizations may pay a vendor for deployment and maintenance. Before deciding, check whether the team has experience with PostgreSQL administration, Kubernetes or the chosen runtime, Liquibase migrations, IT audit evidence and change control tooling. A partner can fill specific gaps, such as control documentation or testing, while the institution keeps operational ownership.

Does the SEC cost estimate for exemption from auditor attestation apply to my ITGC budget?

No. The SEC's estimate in Release 34-88365 is a different question. It estimated in 2020 that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average, roughly $110,000 in audit fees and $100,000 in other costs. That figure concerns whether an issuer must have its ICFR assessment attested by an auditor. It does not estimate what it costs to build, document or operate IT general controls for a self-hosted core. Management still has to evaluate ICFR under Section 404(a) and Rule 13a-15, and the ITGCs that support financial reporting controls remain necessary whether or not an auditor attests. Confirm your filer status and attestation obligation with your counsel and auditor before using that figure in any budget.

How do quarterly Apache Fineract releases affect change control?

Each quarterly release is a change that must pass through the same approval, testing and evidence steps as any other production change. The Fineract README states that official releases are created at the end of each quarter, following the ASF release policy, and that end-of-life releases are archived. Current stable release is 1.15.0, published July 14, 2026. Your change process should define how a new release is assessed, tested in non-production environments, approved by the process owner, and rolled out, including how Liquibase migrations run only on write instances and how batch instances are handled. Decide whether you will adopt every quarterly release or only security and defect fixes, and record that policy, because auditors will test whether changes were authorized and tested.

What should I ask an implementation partner about SOX ITGC scope and evidence?

Ask the partner to state which ITGC areas are in scope and how each maps to the financial reporting risks you identified, since no SEC rule or PCAOB standard publishes a fixed catalog. Ask how they will document controls, what evidence they will collect and how often, and how they will support the auditor's walkthroughs and testing. Ask who holds the privileged access, how break-glass access is logged and reviewed, and how batch job and data migration controls are evidenced. Finally, ask what the partner does not do. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors do that work.

How DeployOpen scopes SOX ITGC work for a core banking system

DeployOpen agrees the scope of SOX ITGC work in writing before any build begins. For a self-hosted Apache Fineract deployment, that written scope should name each system in the control boundary: the Fineract write, batch and read instances, the tenants database, the PostgreSQL databases, the reverse proxy and identity layer, the CI/CD pipeline and the backup and restore tooling. It should also name which ITGC areas the client's auditors expect to rely on, because the SEC guidance in Release 33-8810 says the relevant aspects of IT general controls vary with each company's facts and circumstances. Ask the client's external auditor early which controls they plan to benchmark, since that choice determines how much evidence the scope must produce.

Within that scope, DeployOpen plans, implements, hardens, documents and supports the self-hosted Fineract platform inside the client's own cloud accounts, data centers or air-gapped networks. The work covers the controls the client owns, such as privileged access to the database, change approval for Liquibase migrations and the scheduling of end-of-day batch jobs on the batch instance. DeployOpen also prepares systems and evidence for the assessment, including access reviews, change tickets and job logs. It does not issue audit reports, attestations or opinions on ICFR. Those come from the client's management assessment and the independent auditor under PCAOB AS 2201.

Ongoing work after go-live is usually handled under a retainer, which can cover support, upgrades to new quarterly Fineract releases, re-testing of access and change controls and evidence collection for each assessment cycle. Confirm in the proposal how the retainer treats upgrades that alter database schema, how emergency patches are approved and who signs off the revised control evidence. Those terms determine whether the controls keep working after the first assessment cycle, which is where many programs lose their footing.

How DeployOpen delivers and supports SOX ITGC controls for self-hosted core banking

DeployOpen plans, implements, hardens, documents and supports self-hosted Apache Fineract inside the client's own cloud accounts, data centers or air-gapped networks. For SOX IT general controls, the work produces the access, change, batch and migration controls and the evidence an auditor needs, while the auditor and management keep ownership of the ICFR assessment.

How we scope

Scope is agreed in writing before work starts, listing which Fineract instances, environments and control areas are covered.
We map which Fineract functions and data feed financial reporting, so ITGC effort targets relevant systems only.
The written scope names who approves privileged access, change tickets and batch schedules, and who owns each control.

How we build

We configure privileged access paths to the PostgreSQL database and Fineract environments, limiting direct access to named roles.
We set up change pipelines with approval records, separate environments and logged deployments for Fineract configuration and code.
We schedule read, write and batch instances and document end-of-day job controls, reruns and failure alerting.

How we hand over

Deliverables include control narratives, access matrices, change procedures, batch runbooks and data migration reconciliation records.
We test controls before handover and document the results, including exceptions and how they were resolved.
Runbooks and evidence locations are handed to your control owners, so the institution can operate the controls independently.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, including review of quarterly Fineract releases.
We help prepare access reviews, change samples and batch logs for internal audit and the external auditor's requests.
Ask any implementation partner to confirm its support hours, response terms and evidence retention in writing before signing.

Open source core banking for SOX IT general controls