Core banking requirements checklist for Fineract

Core banking requirements checklist: how to use it before choosing Fineract

This checklist is for a bank, lender or fintech that has to define its core banking requirements before it selects or builds on *Apache Fineract*. It covers products, accounting rules, tenants, channels, payment and card integrations, KYC data, regulatory reporting, batch jobs, performance targets and the ICT third-party risk register. The checklist should be signed off by the executive accountable for the core (usually the CIO or COO), with the CISO, head of compliance, finance controller and risk owner each signing their own sections. Use it to decide what the platform must do before any product demo or build estimate is accepted.

Fineract is a headless application: it exposes REST APIs and provides no user interface of its own. That means every channel is a separate requirement. Define the customer and staff front ends, the mobile app, the branch and collections tools, and the Mifos X web application if you consider it, along with who builds and hosts each one. The same applies to payments, card processing, KYC document capture and regulatory reporting. None of these come with Fineract, so each needs an owner, an interface definition and a test plan in the written scope.

Treat every line of this checklist as a requirement to verify, not a claim to accept. Ask the implementation partner to show how each item will be configured, tested and evidenced in your own environment, and record the answer in the written scope, which is where deliverables, acceptance criteria and timelines are agreed before work starts. A vendor statement that a feature exists is not evidence. Where a requirement depends on a Fineract version, confirm it against the release you will deploy, since the project publishes quarterly releases and the current stable release is 1.15.0 according to the Apache Fineract project site.

Which product, accounting and tenant requirements to define first

This table lists the functional requirements to settle before configuring Apache Fineract, from loan, savings and deposit products to accounting, tenancy, KYC data and reporting. Each row says why the requirement matters and how to verify it before build starts. Treat the verification column as the acceptance test your implementation partner should be able to demonstrate.

Requirement	Why it matters	How to verify
Loan, savings and deposit products	Each product type carries its own rules for interest, fees, repayment schedules and penalties, and these drive every downstream balance and report.	Configure one test product per type with agreed rules, then run sample accounts through a full lifecycle and compare outputs with the signed-off product sheet.
Product business rules and fee logic	Rules such as grace periods, penalty accrual, rounding and day-count conventions are hard to change once live accounts exist.	Document each rule with a worked example, then confirm the system result matches the example to the smallest currency unit.
Chart of accounts and accounting mappings	Fineract posts accounting in real time, so every product event needs a defined general ledger account before go-live.	Map each product event to a ledger account in a reviewed matrix, then post sample transactions and check the trial balance against the expected entries.
Accrual and interest recognition	Accrued interest and fees affect income, provisioning and period-end close, and errors compound across periods.	Reconcile accruals for a sample of loans and savings accounts against an independent calculation and a sample ledger extract for the same dates.
Multi-tenant structure	Each tenant needs its own data, products and configuration, and requests must reach the correct tenant every time.	Confirm the tenant identifier header is set by every client channel, check the tenants database entries, and test that a request for one tenant cannot read another tenant's records.
Client data and KYC documents	Client identity records and uploaded KYC documents are personal data and must be retrievable for audits and customer requests.	Define the mandatory fields and document types, then test capture, retrieval, update and retention for a sample client across each channel.
Reporting and regulatory outputs	Regulators and internal committees need consistent figures, and report logic must match the general ledger.	List each required report with its source fields and owner, then reconcile report totals to the general ledger for the same period.
Configurable business rules and approvals	Maker-checker steps, limits and overrides need to match the institution's delegated authority matrix.	Test each rule with an authorized and an unauthorized user, and record the outcome in the test evidence pack.

How channels, front ends, payments and card integrations change the requirements

The Fineract README uses the Mifos X web application as the front end in its Kubernetes example. Mifos X is a separate application that calls Fineract's REST APIs, so the requirements for staff sessions, roles and screens sit with the front end while balances, products and accounting stay in Fineract. Teams should confirm with the vendor and the implementation partner which Mifos X version fits the Fineract release they run, how it is hosted and how it is patched.

Staff authentication: Define how staff sign in, whether through an identity provider with multi-factor authentication, and how sessions expire and are revoked.
Role mapping: Map Mifos X roles to the maker-checker and segregation rules the institution needs, and test them against Fineract permissions.
Customer-facing workflows: Mifos X is built mainly for staff operations, so self-service for customers usually needs separate work and a separate security review.
Payment and card rails: Mifos X does not supply card or payment connectivity, so disbursement and repayment channels must be specified and integrated separately.
Audit ownership: The institution owns the logs of user actions in the front end, the retention of those logs and the review of privileged access.

Confirm the Mifos X version, its support status and the security testing it has received before committing to it as the front end.

Security requirements the FTC Safeguards Rule and ICT controls expect

The FTC Safeguards Rule sets baseline controls for customer information that a self-hosted Fineract deployment must meet on its own infrastructure. The cards below cover the controls most often reviewed in a core banking assessment, with the evidence to keep and the check to run for each.

Encryption in transit and at rest

Customer information must be encrypted over external networks and on storage. For Fineract, this covers TLS on the REST APIs, connections from the Mifos X front end and integrations, and database connections to PostgreSQL, plus encrypted volumes, backups and replicas. Keep certificate inventories, key management records and storage encryption settings. Verify by scanning external endpoints for protocol versions and by confirming that read replicas and backup copies are encrypted too.

Multi-factor authentication for system access

Any individual accessing an information system needs multi-factor authentication, which covers staff using the Fineract admin interface, operators with database or server access, and vendor support accounts. Fineract is headless, so MFA must be enforced in the identity layer that fronts the Mifos X front end, the admin tools and the bastion hosts. Keep the MFA policy, enrollment records and exception approvals. Verify by attempting logins with only a password against each access path.

Change management procedures

Changes to product configuration, accounting rules, code, database migrations and infrastructure need documented approval and testing before they reach production. In Fineract this includes Liquibase migrations, tenant configuration and upgrades to each quarterly release. Keep change tickets, test evidence, approval records and rollback plans. Verify by sampling recent production changes and tracing each one back to an approved request.

Logging of authorized user activity

The rule requires logs of what authorized users do with customer information. For a core banking system, this means logs of loan and savings postings, reversals, product changes, user role changes and direct database sessions, with user identity attached. Keep log retention settings, the list of logged event types and access rights to the log store. Verify by performing a test transaction under a named user and confirming the entry appears, with the correct identity and timestamp, in the central log store.

Annual penetration testing and vulnerability assessments

Absent effective continuous monitoring, the rule requires penetration testing once a year and vulnerability assessments at least every six months. Testing should cover the Fineract REST APIs, tenant isolation, the front end, the database tier and the hosting platform. Keep the scope statements, reports, remediation tracking and retest evidence. Verify that testing dates on record match the cadence and that open findings have owners and due dates. DeployOpen runs security testing as a separate engagement, and an independent assessor's report is what an examiner reviews.

Privileged database access controls

Direct access to the PostgreSQL database that holds ledgers, client records and KYC data bypasses application controls, so it needs its own controls. Limit privileged roles, require named accounts and approval for each elevated session, and record every query or change made outside the application. Keep role matrices, access reviews and session recordings or audit logs. Verify by listing database roles and checking each superuser or schema owner against an approved owner, then confirming that the logs capture a test privileged session.

What regulatory reporting and record retention need from the core

Regulatory reporting is a requirement to define before any Fineract configuration starts, because the core has to produce the data a regulator asks for, not just store transactions. A headless core such as Apache Fineract exposes portfolio, accounting and client data through REST APIs, but the report definitions, field mappings, cut-off rules and submission formats are not something the platform decides for you. Each report needs an owner on the compliance side, a named source of truth in the core (for example, which loan status, account classification or general ledger code feeds each line), and a test case with known expected values. Ask the compliance lead for the full list of reports, their frequencies and their formats in writing, and treat any report without a named data source as an open risk.

Record retention is the second decision, and it depends on the licence and activity of the institution. Some firms face specific rules: for example, SEC Rule 17a-4(b) requires broker-dealers to preserve certain records, including bills receivable or payable, bank statements and originals of business communications, for not less than three years, with the first two years in an easily accessible place. Lending and deposit businesses are subject to different retention periods set by their own regulators, and some of those rules may not apply to a bank at all. Confirm with counsel which retention rules apply to your licence type, then map each record class to a store, a retention period and a deletion or legal hold procedure before the first production load.

Plan for these requirements in the core design rather than adding them after go-live. Decide where historical balances, transaction journals and document attachments are kept, how point-in-time reports can be reproduced for an examiner, and who approves a change to a report definition. Ask any implementation partner to show how a regulatory report is built from Fineract data, how its output is reconciled to the general ledger, and how retention rules are enforced in the database and backup layers, including what happens to records when a client relationship closes. Your compliance team should sign off each of these items before the reporting build is accepted.

What buyers ask before hiring a Fineract implementation partner

How much does a self-hosted Fineract project cost?

Apache Fineract carries no license fee, so the cost sits in the work around it. Most of the spend falls into product configuration, front-end build, integrations with payments and KYC providers, infrastructure in your own cloud or data center, testing, regulatory reporting and ongoing support. Infrastructure and support recur every year, while configuration, integration and testing are largely one-time costs that rise with the number of loan and savings products, channels and tenants. To compare quotes, ask each partner to itemize these components separately, state who pays for each licence or subscription you will still need (database, monitoring, identity), and confirm which items are fixed scope and which are billed on change requests. A quote is only comparable when the written scope names the same products, channels and integrations.

How long does a Fineract core banking implementation take?

The timeline depends mainly on how many products, accounting rules, channels and third-party connections are in scope, and on how quickly your own decisions and approvals arrive. Product design and accounting sign-off usually set the pace, because every loan or savings rule has to be confirmed before it is built and tested. Other timing drivers include the front end you choose, the number of payment and KYC providers, the depth of regulatory reporting, and the number of test cycles you require before go-live. Ask the partner to show the phases in the written scope, the entry and exit criteria for each phase, the dates that depend on your staff, and the assumptions behind them. Any duration that is not tied to a defined scope should be treated as an estimate, not a commitment.

What does the bank's own staff need to provide during the project?

The project needs named business owners who can decide product rules, accounting staff who sign off the general ledger mapping and interest, fee and provisioning logic, and security and risk approvers who accept access controls, hosting design and change procedures. Operations and IT staff must also provide access to cloud accounts or data center environments, network connectivity to payment and KYC providers, and time for user acceptance testing. Ask the partner to list each role, the decisions expected from it, the expected turnaround, and the point at which work stops if a decision is late. A written RACI or responsibility table in the scope is the most practical way to make these dependencies visible before work starts.

Can our internal team implement Fineract without an outside partner?

An internal team can implement Fineract, but it needs skills across several disciplines at once: Java and Spring, PostgreSQL administration, Kubernetes or container operations, API integration, banking product design, accounting and reporting, and security testing. The Fineract project provides the platform and documentation, but it does not supply a comprehensive production deployment guide, so the design of hosting, backup, batch scheduling and instance layout falls to your team. Assess the skills you already have against each area, identify gaps you would fill by hiring or training, and decide which pieces, such as the front end, payment connections or testing, might be better handled by a partner under a fixed-scope agreement. Keeping ownership of the running system in-house is a separate decision from who builds it, and the answer should be written into the operating model.

What does the Fineract README mean by a complex production deployment?

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. In practice, complexity comes from the number of components you must run and govern: the Fineract application instances, a PostgreSQL database with replicas, a tenants database for multi-tenant setups, front-end and integration services, monitoring, backup and restore, and secrets management. The documentation describes separate read, write and batch instance types, and notes that Liquibase database migrations run only on write instances. Ask a partner to explain how they size and separate these instances, how they schedule batch jobs for end-of-day processing, how they run migrations safely during upgrades, and how they test restoration. These answers reveal whether the design has been run in production rather than only installed.

What should a written scope for a Fineract project include?

A written scope should name the products (loans, savings and deposits), the accounting rules and chart of accounts, the tenants, the channels and front ends, each payment, card and KYC integration, the regulatory reports, the batch jobs, the performance targets and the required security controls. It should also list the third-party providers and the ICT third-party risk register entries they affect, the test types and acceptance criteria, the handover and documentation deliverables, and the post-go-live support model. Anything excluded should be stated explicitly so that later change requests can be priced against a known baseline. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for the written scope before comparing any quotes.

How do quarterly Fineract releases affect ongoing cost and effort?

The Fineract README states that official releases are created quarterly, at the end of each quarter, so a running system will need a steady rhythm of upgrade assessment and testing. Each release has to be evaluated against your configured products, custom code, integrations and database version, and end-of-life releases are archived, which means an unpatched version eventually stops being supported by the project. Recurring costs therefore include regression testing, staging environments, change approvals and the staff time to review release notes. Ask the partner whether upgrades are included in a retainer or quoted separately, how many releases they expect to skip, how they test migrations on copies of production data, and how rollback is handled if an upgrade fails.

How to verify batch jobs, performance targets and release adoption

This table lists the operational requirements a Fineract deployment must meet, from instance sizing and Liquibase migrations to batch completion, peak performance, restoration and quarterly releases. Each row names how to verify the requirement before go-live and on an ongoing basis, so the checklist becomes evidence rather than a list of intentions.

Requirement	What it asks for	How to verify
Read, write and batch instance sizing	Separate write, batch and read instances set by environment variables, with read instances on database read replicas for high load	Confirm the instance roles in the deployment configuration, then run a load test that mixes read and write traffic against the agreed targets
Liquibase migrations	Schema migrations run only on write instances, or separately with the liquibase-only Spring profile on Kubernetes	Review the deployment manifests to confirm no other instance type runs migrations, and rehearse a migration in a non-production environment
End-of-day batch scheduling	Batch jobs run on the batch instance in a defined order, with a known finish time and a documented restart procedure	Run a full end-of-day cycle on production-sized data, check job logs and balances, and test a forced failure with restart
Batch completion checks	Control totals that show every batch ran once, completed and reconciled to the general ledger before the business day closes	Compare control totals and general ledger balances against an independent source after each trial run, and keep the signed results
Performance targets at peak volume	Targets for transaction throughput, response times and batch windows, agreed with the business for peak days such as month-end and payment runs	Load test the agreed peak profile in a production-like environment, record results against each target, and repeat after material changes
Backup and restoration	Regular backups of the PostgreSQL database and configuration, with copies held separately from the primary environment	Run a restore drill to a clean environment, measure the time taken, and confirm the restored balances reconcile to the source
Quarterly release adoption	Official releases arrive quarterly under the ASF release policy, so the bank needs a defined test and approval path for each one	Keep a dated upgrade log, test each release in staging against custom products and integrations, and track change approvals
End-of-life release archiving	End-of-life releases are archived by the project, so a deployed version can lose upstream support on a known schedule	Check the release status on the project site each quarter, and plan an upgrade before the running version reaches end of life

Building the ICT third-party risk register for a self-hosted core

A self-hosted Fineract core still depends on outside parties: the open-source project, an implementation partner, infrastructure providers, payment and KYC vendors, and the database and hosting stack. Each one needs a register entry that names what it supplies, what data it touches and how the institution would leave it. The DORA mapping for these entries is covered on a sibling page.

Apache Fineract project

The Fineract code carries no license fee, but the institution depends on the project's release cadence. Record the version in production, the Apache-2.0 license terms and the support status of each release line. The Fineract README says official releases come quarterly and end-of-life releases are archived, so note who applies security fixes between releases and who tests them. Ask your implementation partner which release line they will keep you on and how long they will backport fixes to it.

Implementation partner

The partner configures products, builds integrations, hardens the platform and often runs upgrades, so it holds privileged access to core systems. Record the services in scope, the staff roles with system access, where their support tooling runs and which subcontractors they use. Ask for written incident notification commitments, the location of any data they handle, and the process for returning credentials and documentation at the end of the contract.

Cloud and data centre providers

The infrastructure provider hosts the compute, storage, network and backups that carry customer and ledger data. Record the facility locations, the regions used for primary and backup copies, the provider's own third-party dependencies and any shared responsibility split. Ask whether the provider can supply contractual audit rights, its incident notice periods and the options to move workloads or copies to another location if the contract ends.

Payment and KYC vendors

Card processors, payout rails, identity verification and sanctions data providers exchange customer data with the core, so each is a data flow as well as a service. Record which fields leave the core, the data residency of each vendor, and whether the vendor is a critical function for any payment or onboarding service. Ask each vendor how it handles data deletion, what its availability commitments are and how the institution can switch providers without re-keying customer records.

Database and hosting components

PostgreSQL, the container runtime, the orchestration layer, the message broker and monitoring tools are separate dependencies, each with its own patch cycle and licence. Record the exact versions, the vendor or community that maintains each one, and the support route for security advisories. The Fineract README recommends PostgreSQL and states that MariaDB and MySQL are deprecated, so note that choice explicitly. Confirm with your partner which component versions are certified for the chosen Fineract release.

Exit and replacement path

The register should show how the institution would leave each dependency without losing ledger history or customer records. For the core, record the export formats for clients, loans, savings and journal entries, the backup copies that stay under institution control and the parallel run approach for a replacement. Test the exit path on a copy of production data and record the date and result. Ask your partner to document the steps and the rollback point before any cutover.

How to turn the checklist into a signed requirements baseline

This sequence turns the checklist into a single, agreed requirements baseline that names an owner for every area, scores each requirement, ties it to a way of proving it works, and is signed off before any written scope is drafted. The output is the document a implementation partner can price and build against.

Assign an owner to each area
Name one accountable owner for each area of the checklist: products, finance, compliance, security, operations and channels. Each owner is responsible for the requirements in their area, for resolving open questions and for speaking for their function in the workshop. Ask each owner to confirm in writing which requirements they can answer and which need input from another area. The step is done when every checklist item has exactly one owner and no area is left without a named person.
Score each requirement in a workshop
Hold a cross-functional workshop where each owner presents the requirements in their area and the group scores every item as must, should or later. A must is a condition for going live, such as a loan product the bank cannot launch without or a regulatory report it must file. A should is expected but can follow go-live, and later is recorded for a future phase. Record the reason for each score, especially for anything marked must, so the decision can be challenged later. The step is done when every requirement carries a score and a rationale.
Map each requirement to a verification method
For each requirement, agree how it will be proven before go-live. Typical methods include a configuration review against the product catalog, a test script run in a test tenant, a reconciliation report compared with the general ledger, a reviewed control walkthrough, or evidence from a penetration test. Note which requirements need a regulator, auditor or internal risk function to accept the evidence, and confirm that with them rather than assuming. The step is done when each must-level requirement has a named verification method and an evidence owner.
Agree performance and batch targets
Set the performance and batch targets the platform must meet, covering transaction volumes, concurrent users, read and write load, the end-of-day batch window and recovery expectations. Ask operations and the business to state these as measurable figures drawn from their own volume forecasts and service commitments. Confirm how the read, write and batch instance model in Fineract will be sized against those figures, and ask the implementation partner to explain their sizing method in writing. The step is done when every target is a number with a stated basis and an owner.
Record the ICT third-party register entries
Record every third party involved in the core banking system in the ICT third-party risk register: the hosting provider, the implementation partner, the database and infrastructure vendors, payment and KYC providers, and any data or reporting service. For each entry, note the service it provides, the data it touches, where that data is stored and what exit or substitution option exists. Confirm with compliance which register fields the institution's own policy and applicable rules require. The step is done when every party in the design has a register entry reviewed by compliance.
Obtain sign-off on the requirements baseline
Compile the scored requirements, verification methods, performance and batch targets and third-party entries into one baseline document. Circulate it to every area owner, the sponsoring executive and the risk or compliance function for written approval, and log any open items with a named owner and a resolution route. Changes after sign-off go through a documented change request. The step is done when all named approvers have signed, and only then does the written scope with the implementation partner get drafted from this baseline.

Which partner answers separate credible Fineract implementations

The strongest signal of a credible Fineract partner is how specifically it answers requirement-level questions. Ask which Fineract deployments it runs in production today, how many of them handle loans and savings at your scale, and whether it can describe one of them without naming the client. A partner that answers in generalities about open source and digital banking has not necessarily delivered this work. Ask for the answers in writing, with the version of Fineract each deployment runs. The Apache Fineract GitHub repository lists 1.15.0 as the release published on July 14, 2026, so a partner's answer should say which release it has deployed and how it moved between releases.

Test how the partner would configure products and accounting. A credible answer names the product definitions it would build for loans, savings and deposits, how it maps each product to general ledger accounts in Fineract's accounting setup, and who signs off on accounting rules before go-live. Ask how it sizes the write, batch and read instances described in the Fineract documentation, including which instance runs Liquibase migrations and how read replicas are used at peak load. Ask how it plans to adopt quarterly releases: who tests each release, how long a parallel environment is kept, and how a rollback is handled. Also ask how it integrates KYC and payment providers, and what it will own for data protection and logging.

Compare each answer against the checklist in this guide, and record gaps as open items in the statement of work. Ask for a written list of the deliverables, the responsibilities split between your team and the partner, and the evidence the partner will hand over, such as configuration exports, test records and runbooks. Treat vague answers, or promises that the partner will work these out later, as a finding rather than a neutral result. Confirm any credential, certification or vendor relationship the partner claims directly with the issuing body, because DeployOpen does not hold any vendor or standards-body status unless a source says so. DeployOpen can be assessed with the same questions, and its written scope should answer each one before work starts.

How DeployOpen scopes and delivers a Fineract requirements baseline

DeployOpen turns a core banking requirements checklist into a written, fixed-scope baseline for a self-hosted Apache Fineract project, inside the institution's own infrastructure. We cover the product, accounting, tenant, channel, integration, reporting and third-party risk items listed on this page, and we document each decision so the bank's own team can review and maintain it.

How we scope

Review each checklist item with the bank's product, finance, risk and compliance owners before any build starts.
Record the loan, savings and deposit products in scope, with the accounting rules each one needs.
Agree in writing which tenants, channels, payment and KYC integrations, and regulator reports are included.
Confirm the ICT third-party risk register entries and the owner for each hosting and support dependency.

How we build

Configure Fineract products and business rules against the agreed requirements baseline, with traceable decisions.
Set up PostgreSQL, read, write and batch instances in the bank's chosen cloud, data center or air-gapped environment.
Build and test integration interfaces for payments, KYC data and general ledger postings against documented test cases.
Run security testing of the APIs and deployment before go-live, and report findings with remediation owners.

How we hand over

Deliver the requirements baseline, configuration records, architecture diagrams and operating runbooks as versioned documents.
Train the bank's administrators on tenant setup, batch scheduling, backup and restore, and change procedures.
Provide compliance evidence packs that the bank's internal and external auditors can review, without issuing any attestation ourselves.
Confirm acceptance against the written scope before the engagement closes.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, with scope agreed in writing.
Plan the adoption of Fineract's quarterly releases as a documented change, tested in a non-production tenant first.
Update the requirements baseline and risk register when products, regulations or integrations change.
Quote any follow-on work from a new written scope, so the bank can see what each change costs and why.

Core banking requirements checklist