Open source loan management for microfinance institutions: why the build is different
For most microfinance institutions and credit unions, Apache Fineract with Mifos X covers the core of group and individual lending, including loan products, repayment schedules and savings linked to loans. The harder question is not whether the software fits the lending model. It is whether a small IT team can host, configure and keep a multi-tenant production system running with the controls a regulator will ask about. Those hosting and tenant decisions, not the loan features, are where most of the effort sits. The Fineract README is direct about this. It 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. Fineract is also headless: it exposes REST APIs and provides no user interface of its own. The README points to Mifos X as the front end used in its Kubernetes example, but field officers working offline or in branches need a client that handles their workflows, so the front end is a separate selection you must make and test. Confirm with the vendor whether the Mifos X version you plan to use matches the Fineract release you deploy. Before committing, confirm three things in your own environment: how tenants are created and isolated for each institution or branch network, which database you will run (the README recommends PostgreSQL and deprecates MariaDB and MySQL), and who in your team owns Liquibase migrations, which the documentation says run only on write instances. Ask any implementation partner to show how they would separate those roles in your hosting plan, and to document the result before go-live.
Which lending and security requirements shape a microfinance build
This table maps each requirement that can apply to a microfinance lender to its source, what it means for a Fineract deployment, tenant design and logging, and whether it depends on licence or jurisdiction. Read each row first to confirm applicability, then treat the build consequence as the design input for your scope.
| Requirement | Source and trigger | What it means for the Fineract build | Depends on licence or jurisdiction |
|---|---|---|---|
| Encryption of customer information | 16 CFR 314.4 requires encryption in transit over external networks and at rest | Enforce TLS on API, reporting and field officer endpoints. Encrypt PostgreSQL storage, backups and document stores holding client KYC files. | Yes. Applies if the institution is a covered non-bank financial institution under FTC jurisdiction. |
| Multi-factor authentication for all system users | 16 CFR 314.4(c)(5) requires MFA for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing | Mifos X and admin consoles need MFA in front of them. Field officers on shared devices need a documented approach, and any exception needs written approval. | Yes. Same FTC scope as above. Confirm whether your regulator sets stricter rules for credit unions or microfinance licences. |
| Change management | 16 CFR 314.4 requires change management procedures | Track Fineract product, rule and configuration changes through approved tickets, with separate environments and tested rollback. Keep tenant configuration in version control where practical. | Yes for FTC-covered entities. Other regulators may set their own change control expectations. |
| Logging of authorized user activity | 16 CFR 314.4 requires logging of authorized user activity | Enable audit logging for loan approvals, disbursements, fee waivers and write-off actions by user and tenant. Forward logs to a central store the write instance cannot alter. | Yes for FTC-covered entities. Retention periods depend on the institution's own record rules and local law. |
| Penetration testing and vulnerability assessment | 16 CFR 314.4(d)(2) requires annual penetration testing and assessments at least every six months, absent effective continuous monitoring | Schedule penetration tests against the Fineract API, Mifos X front end and tenant isolation. Document scope, findings and fixes for the assessor. | Yes for FTC-covered entities without continuous monitoring. Confirm the cadence with your Qualified Individual and regulator. |
| Cardholder data handling | PCI DSS applies only where card or payment data is stored, processed, transmitted or could affect that environment | If loan repayments use card rails, keep card data out of Fineract. Route payments through a validated provider and limit Fineract to tokens or payment references. | Conditional. Scope depends on whether the institution or a payment provider touches cardholder data. Confirm with the acquirer or payment brands. |
| ICT third-party and exit controls | DORA Articles 28 and 30 for EU financial entities, covering the register of ICT contracts, exit strategies and contract terms | Document Fineract hosting, backup and support providers in the register. Plan data export and a tested exit path for the loan book and tenant databases. | Only where the institution is an EU financial entity in DORA scope. Not applicable to US-only lenders. |
| Network and incident obligations | NIS2 (Directive (EU) 2022/2555) and GDPR (Regulation (EU) 2016/679) for EU entities and personal data | Map Fineract hosting into incident response and breach notification workflows. Keep client personal data in defined regions and document processing locations. | Only where the institution falls under NIS2 or processes EU personal data. Confirm entity status and national transposition with counsel. |
How group loans, repayment schedules and savings map to Fineract products
Fineract models every lending arrangement as a loan product, and the product carries the rules: principal limits, interest method, repayment frequency, grace periods, fees and the accounting mapping. Individual loans and group loans both sit on this model, but a group loan is not a native object in Fineract's core. The usual pattern is to create a group record, attach member clients to it, and then issue loans either to the group or to each member under a product that the field team and the credit committee have agreed on. The first decision is whether the group is the borrower of record or a set of linked individual loans, because that choice determines how disbursement, repayment allocation and write-offs are reported. Confirm with the vendor or in a configuration workshop exactly how group membership, group-level collections and meeting-based attendance are represented, and whether the Mifos X front end exposes them the way your field officers work.
Repayment schedules are generated from the product definition, so the team must define repayment frequency, the amortization or flat interest method, grace periods, moratoriums and how partial payments are allocated across principal, interest and fees before build. Savings linked to loans, such as compulsory savings held as a loan guarantee or voluntary savings used for repayment, are configured as savings products and connected to the loan product rules. Test these rules with a realistic set of scenarios: a missed installment in a group, an early repayment by one member, a top-up loan and a savings withdrawal during an open loan. Fineract provides client data and KYC document handling, loan and savings portfolio management, and accounting entries, so the reader should map which client identity records, KYC artifacts and member-level data must be stored in the platform and which stay in an external system.
Before build, the team should write down the product catalogue with worked examples, the group formation and dissolution rules, the meeting calendar and who records attendance, the field officer assignments and approval limits, and the savings-to-loan rules in plain language that the configuration can be tested against. Ask the implementation partner to run a configuration workshop that produces a signed product specification, and to demonstrate schedule generation for each product using your own sample data. Confirm the Fineract version the partner will configure, since the Apache Fineract release line is published quarterly, and make sure the configuration is documented so it can be reproduced in a test tenant during upgrades.
Where a microfinance lender can host Fineract
A single-country microfinance institution with a small IT team usually benefits from the simplest supportable layout: one Fineract write instance, one batch instance and PostgreSQL as the database. Fineract is headless and exposes REST APIs, so Mifos X or another front end sits on top, and the core runs on your own servers or cloud account. The Fineract documentation recommends one write instance, one batch instance and multiple read instances on database read replicas for high load, so read replicas are added only when reporting or field traffic justifies them.
- Database choice: PostgreSQL is the recommended database under FSIP-9, and MariaDB and MySQL are deprecated, so plan for PostgreSQL backups, point-in-time recovery and patching from the start.
- Instance pattern: Start with one write instance and one batch instance for interest accrual and scheduled jobs, and add read instances on replicas only after load testing shows the need.
- Liquibase migrations: Migrations run only on write instances, so upgrades must be sequenced so that exactly one write instance applies schema changes.
- Staffing: A small team needs someone who can run PostgreSQL, someone who owns Fineract configuration and product setup, and someone who handles the front end and integrations, even if one person covers more than one role.
- Operations: Confirm who performs quarterly upgrades, since official releases follow a quarterly cadence and end-of-life releases are archived.
Before committing, ask the implementation partner to show the upgrade runbook and the restore test for the database.
A credit union with a data-residency preference typically needs the database, backups and logs held in a named region or on premises, with access limited to staff in that jurisdiction. The Fineract architecture still uses the same write, batch and read roles, but the placement of each component becomes a governance decision. Fineract is multi-tenant, with requests carrying a Fineract-Platform-TenantId header and tenant connections configured from a tenants database, so a federation or shared-service arrangement must be designed around tenant boundaries and not only server locations.
- Database placement: Keep PostgreSQL, its replicas and its backups in the approved location, and record which replica serves reporting users.
- Instance roles: Place the write and batch instances in the controlled environment, and confirm that read replicas do not cross a border unless the contract allows it.
- Migration control: Because Liquibase runs only on write instances, change approval should name the instance and the window in which schema changes occur.
- Staffing: Expect to need a named data protection contact, a platform administrator and a person who can produce access logs for examiners.
- Vendor terms: Under DORA Article 30(2), ICT service contracts must state where services are provided and data processed, so any partner that touches the environment needs the same location commitments.
Ask the partner to map each component, including backups and support access, to a location and an owner before the design is approved.
A network of branches with limited connectivity cannot rely on a single central Fineract instance reached over a fragile link for every teller and field officer transaction. The usual approach keeps the write and batch instances centrally, supports regional read instances for branch reporting, and defines what happens to transactions captured offline. Because the Fineract documentation describes read, write and batch instance types set by environment variables, the topology can be expressed in configuration, but the connectivity model is a business and engineering decision that must be tested with the actual links.
- Central write path: Keep the single write instance in a location with reliable power and connectivity, since every posting depends on it.
- Regional read capacity: Place read instances on database read replicas near branch clusters for statements and portfolio views, with a stated replication lag that staff understand.
- Batch scheduling: Run the batch instance during off-hours so interest and fee jobs do not compete with branch traffic.
- Offline handling: Decide whether field collection is captured on devices and posted later, and confirm how duplicate or late postings are reconciled in Fineract.
- Staffing: Assign someone to monitor link health and replica lag, and someone to handle branch-level incident triage.
Ask the partner to test a branch outage scenario end to end, including a failed write path and a late batch run, and to document the recovery steps.
Which open source platforms fit microfinance lending and why
Microfinance lending usually needs a core that handles group and individual loans, savings and accounting, plus a front end for field staff. The options below separate the core system from the user interface and the adjacent tools, so you can see which pieces your scope actually requires and where each one stops.
Apache Fineract as the core
Fineract is the system of record for clients, loan and savings products, portfolios and accounting. It is licensed under Apache-2.0 and its current stable release is 1.15.0, published July 14, 2026. Fineract is headless: it exposes REST APIs and has no staff screens of its own, so every workflow your field officers use must be supplied by a front end. Check that its product configuration covers your group and solidarity methods, and confirm which items need custom work before you commit.
Mifos X as the web front end
Mifos X is the web application the Fineract README names as the front end in its Kubernetes example. It gives loan officers and branch staff screens on top of the Fineract APIs, so it is the natural choice when you want a ready-made interface on the same core. Confirm that its screens match your field workflows, such as group meetings, collection sheets and client onboarding, and test them against your own product rules before you accept it as the operating console.
Frappe Lending for Frappe stacks
Frappe Lending is the alternative to consider when your organization already runs ERPNext or other Frappe applications and wants lending in the same stack, with one team supporting one framework. It is a different core from Fineract, so you cannot mix the two into one ledger without a deliberate integration design. Ask any partner to show how it handles group lending, savings linked to loans and portfolio reports, because microfinance scope is narrower than the general lending features most buyers evaluate first.
Kill Bill for recurring fees
Kill Bill is an Apache-2.0 subscription billing and payments platform. It fits only when your institution bills recurring membership, insurance or service fees outside the loan schedule, and it does not replace loan repayment schedules, which belong in the core. If you add it, define which system owns each receivable, how entries reach the general ledger, and how the two reconcile at month end.
Hyperswitch for payment collection
Hyperswitch is an Apache-2.0 composable payments platform that routes to multiple payment and payout providers, with SaaS and self-hosted options. It becomes relevant when repayments arrive by card, mobile wallet or bank transfer and you want routing and fallback outside the core. Each added provider brings its own contractual and data location questions, and card data introduces PCI DSS scope, so confirm who holds that scope before connecting it to your repayment flow.
Scope decisions before selection
Some tools are only worth adding when a specific function sits in scope, so decide that first. Fineract plus a front end covers most group and individual lending. Add billing or payment tools only when repayments or fees flow through systems outside the core, and record that boundary in your architecture document. Ask each partner which components they would install by default and why, and confirm the answer against your written requirements.
How a microfinance Fineract rollout moves from scoping to field use
The sequence turns a microfinance product catalog into a hosted Fineract environment that field officers can use, with each phase closing on a signed-off output. Done in order, it keeps product rules, data quality and hosting decisions from being settled late and under pressure at cutover.
Define products and interest methods
The institution's credit committee, finance lead and operations manager document each individual and group loan product, including principal limits, grace periods, repayment frequencies, fees, penalties and the interest calculation method. The DeployOpen team translates these rules into Fineract product configuration and a written product matrix that maps each rule to its setting. The step closes when the product owner signs the matrix and the team has tested sample loans against hand calculations.
Design tenants and environments
The team decides how many Fineract tenants the institution needs, how tenant identifiers are assigned and how development, test, training and production environments are separated and refreshed. Fineract is multi-tenant and routes requests with a tenant identifier header, so tenant design affects access control, reporting and migration paths. The step closes with an environment register, a tenant naming standard and a documented decision on who may create or change tenants.
Lay out PostgreSQL and instance topology
Infrastructure engineers provision PostgreSQL, which the Fineract project recommends as its database, and size the write, batch and read instances. Project documentation recommends one write instance, one batch instance and multiple read instances on database replicas for high load, and it places Liquibase migrations on write instances only. The step closes with a reviewed architecture diagram, tested backup and restore for the database, and a runbook for running migrations separately if the deployment uses Kubernetes.
Configure the Mifos X front end
Fineract does not ship a user interface, so the team installs and configures Mifos X as the front end for loan officers, branch staff and administrators. Role definitions, permissions, branch hierarchy and field officer assignments are set up here, along with the access controls that staff will use daily. Confirm the Mifos X version and its compatibility with the chosen Fineract release before configuration. The step closes when test users in each role can complete their core tasks without administrator help.
Migrate and reconcile legacy portfolio data
Staff extract client records, loan balances, repayment histories and savings balances from spreadsheets or the legacy system, and the team maps them to Fineract fields and loads them into a test tenant. Each batch is reconciled against source totals for principal outstanding, interest, arrears, savings balances and client counts, and mismatches are logged and resolved by the business owner. The step closes with a signed reconciliation report for every migrated portfolio and a documented list of accepted exceptions.
Run the field officer pilot
A small group of field officers and one branch work through real disbursement, repayment, group meeting and collection tasks in the test environment, using migrated clients. The DeployOpen team records every defect, workflow gap and offline or connectivity constraint that affects field work, and the product owner decides which fixes must land before cutover. The step closes when pilot users confirm the critical workflows and the open issue list contains no blocking items.
Cut over to production
The team freezes changes in the legacy system, runs a final migration and reconciliation, and switches branches to Fineract in a sequence agreed in advance. Backups are verified before cutover, rollback criteria are written down, and staff are supported during the first days of live transactions. The step closes when the reconciled production portfolio matches the frozen legacy totals and the operations lead signs the cutover record.
Plan quarterly upgrades
After go-live, the operator sets an upgrade calendar aligned with Fineract's quarterly release cadence, which the project creates at the end of each quarter. Each upgrade is tested in a non-production tenant against the product matrix, reporting outputs and Mifos X compatibility, then scheduled with a change record. The step closes with a documented upgrade plan, an owner for release tracking and a tested rollback path for each planned release.
Integration points that microfinance lenders usually need to connect
Fineract is a headless core, so the loan book only becomes useful when it exchanges data with KYC storage, payment rails, the general ledger, reporting tools, staff identity and backup. Each connection below is a place where data leaves or enters the system, so each one needs a named owner, a tested path and a written answer from your vendor before go-live.
Member and KYC document storage
Client records and identity documents live in Fineract's client data model, but scanned IDs, photos and group membership forms usually sit in a separate document store. Decide whether files are stored in the Fineract instance, in an object store inside your network, or in a document management system, and who can read them. Confirm with your implementation partner how document links are kept in step with the client record, how access is logged, and how retention periods are enforced.
Mobile money and bank payment rails
Disbursements and repayments move through mobile money wallets or bank transfer files, and each rail has its own callbacks, reconciliation files and failure states. A failed or duplicated payment must not leave a loan balance wrong. Ask your partner which connector pattern they will build, how repayments are matched to schedules, how reversals are handled, and who holds the provider credentials and their rotation schedule.
Savings and cash accounting ledger
Savings deposits, withdrawals and loan repayments must post to the general ledger in a way your finance team and external auditors can trace. Fineract provides real-time integrated accounting, but the chart of accounts, product-to-GL mappings and cash handling rules are your decisions. Confirm the export format your accounting package expects, how month-end close is run, and who approves manual journal entries.
Regulatory and donor portfolio reporting
Regulators, donors and investors each ask for portfolio figures in their own format, such as portfolio at risk, write-offs and client counts by branch or gender. Fineract's reporting covers many standard views, but the reports you must file are defined by your supervisor and funders. List every recurring report with its deadline and field definitions before design starts, and confirm whether reports are generated inside the platform or exported to a data warehouse.
Staff identity with multi-factor authentication
Field officers, branch managers and administrators need individual accounts, and the FTC Safeguards Rule requires multi-factor authentication for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing. Connect Fineract and Mifos X to your identity provider through an approach your partner can test, and map roles to products and branches. Confirm how accounts are removed when staff leave and how the access review is evidenced.
Backup and restore of tenant databases
Fineract is multi-tenant, and tenant connections are configured from a tenants database, so a restore must bring back the right tenant data, configuration and migration state together. PostgreSQL is the recommended database, and Liquibase migrations run only on write instances. Ask your partner to demonstrate a full restore into a separate environment, state the recovery point and recovery time they can meet, and document how backups are encrypted and kept away from production credentials.
Evidence a regulator or auditor will ask a microfinance lender for
This table maps each item an examiner or auditor commonly requests to the component that produces it and the gap to close before the request arrives. Read it as a checklist for the evidence pack, not as a list of tools you must own. DeployOpen prepares systems, controls and evidence for assessments, but auditors and certification bodies issue the opinions and attestations.
| Evidence item | Produced by | What to confirm before the request |
|---|---|---|
| Access logs for authorized users | Fineract audit and login records, Mifos X staff activity, reverse proxy and host logs | Logs are retained long enough for your examiner, are centralized, and cannot be edited by administrators |
| MFA configuration records | Identity provider or SSO in front of Mifos X and admin consoles, host bastion settings | MFA covers every staff account, including database and server administrators, with exceptions approved in writing |
| Change management records for Fineract configuration | Git repository for configuration, ticketing system, Liquibase migration history | Each product, fee or rule change has an approver, a test record and a rollback path |
| Upgrade and release records | Fineract quarterly release notes, deployment pipeline logs, test results in staging | Upgrades are tested on a copy of the loan book before production and the record names the version used |
| Encryption in transit and at rest settings | TLS configuration on load balancers and ingress, PostgreSQL SSL settings, storage and backup encryption | Certificates, cipher settings and key custody are documented and reviewed on a schedule |
| Penetration test and vulnerability assessment reports | Independent tester output, scanner reports, remediation tracker | Reports cover the Fineract APIs and Mifos X front end, with findings closed or risk-accepted in writing |
| Portfolio and audit trail reports | Fineract portfolio and accounting reports, loan transaction history, journal entry trail | Reports reconcile to the general ledger and show who changed a loan or schedule and when |
What do microfinance institutions ask before self-hosting Fineract?
What drives the cost of self-hosting Fineract for a microfinance institution?
The cost depends on the scope of the implementation, the hosting model and the people who run the system after go-live. Cost falls into a few components: implementation work (product configuration, data migration, integrations with payment and reporting tools), infrastructure in your own cloud account or data center, security and compliance preparation, and ongoing support. Implementation and infrastructure are mostly one-time or setup costs, while hosting, monitoring, backups, upgrades and support recur. The number of loan products, the volume of historical data to migrate and the number of integrations are the largest drivers. Ask any partner for a quote built from a written scope that separates one-time and recurring items.
How long does a Fineract implementation take?
Duration depends on scope, and no fixed timeline applies to every institution. The Fineract 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. The main variables are the number of loan and savings products to configure, how much legacy data needs cleaning and migration, how many integrations are required, and how quickly your staff can make product decisions. Ask a partner to break the timeline into phases with acceptance criteria, and to name the institution-side tasks that could delay each phase.
Can a small IT team run Fineract on its own?
A small IT team can run Fineract, but it needs clear ownership of the database, the application servers, backups, security patching and upgrades. Fineract is headless, so it has REST APIs and no built-in user interface, which means you also need a front end such as Mifos X and the integrations around it. Fineract recommends PostgreSQL as its database and expects the deployment to be designed for read and write separation at higher load. Many institutions combine an internal operations owner with an external partner for the initial build, hardening and a support retainer. Confirm which tasks your team can own in the first year before you decide.
What does the institution need to provide during implementation?
The institution provides the business decisions, the data and the staff time, and the project stalls when any of these is missing. Product definitions are the first input: loan products, interest methods, repayment schedules, fees, savings products and group lending rules. Data is the second: client records, existing loan balances, repayment histories and KYC documents must be exported, cleaned and reconciled. Staff time is the third, covering field officers and branch managers who test real workflows, approve configurations and sign off on portfolio reports. Ask a partner to list these inputs in the written scope with named owners and dates.
Is Mifos X required to run Apache Fineract?
Mifos X is not required to run Apache Fineract, but most microfinance deployments use it as the front end. Fineract itself is a core banking platform with REST APIs and does not provide its own user interface. The Fineract README points to Mifos X as the web application used in its Kubernetes example. You can also build a custom front end or connect Fineract to other applications through its APIs. Confirm with your partner which front end fits your field officer workflows, offline needs and device mix, because that choice affects training, support and integration effort.
What happens during Fineract quarterly upgrades?
Fineract publishes official releases quarterly, at the end of each quarter, following the Apache Software Foundation release policy, and archives end-of-life releases. Each upgrade needs a plan: reviewing release notes, testing configuration and custom code, running database migrations and validating reports and integrations in a non-production environment. Liquibase database migrations run only on write instances, and on Kubernetes they can run separately with the liquibase-only Spring profile, which shapes the rollout sequence. Confirm who performs upgrades, how long a test cycle takes in your environment and whether the support retainer covers them. The current release at the time of writing was 1.15.0, published July 14, 2026.
Which compliance evidence should we expect from a self-hosted lending system?
Expect the system to support the evidence your regulators request, but the platform itself does not certify compliance. In the United States, the FTC Safeguards Rule requires encryption of customer information, multi-factor authentication for anyone accessing information systems, change management and logging of authorized user activity. Penetration testing and vulnerability assessments must occur at least every six months where continuous monitoring is not in place. Where card data is involved, PCI DSS applies, and assessments are documented by a Qualified Security Assessor or a Self-Assessment Questionnaire. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the reports and attestations.
Who pays for ongoing hosting and support after go-live?
The institution pays for hosting and support directly, whether through its own cloud account, a data center contract or a managed arrangement with a partner. Hosting costs cover compute, storage, database capacity, backups and network, and they scale with the number of clients, loans and transactions. Support covers monitoring, security patching, incident response, upgrades and user help, and it is often sold as a retainer under a written scope. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Ask any partner which items are included, what response times apply and who owns the cloud account and its billing.
What to ask an implementation partner before signing a Fineract scope
Before you sign, ask the partner to show microfinance product configuration they have delivered on Apache Fineract, not only generic lending work. Ask them to walk through how they modeled a group loan with joint liability, how the repayment schedule handles missed meetings and early repayment, and how savings accounts are linked to loan products. Ask for references you can contact, shared with the client's permission. Treat any example without a named reference as unverified until you have seen it. Ask for a written description of Mifos X configuration as well, covering which front end the partner will set up for field officers, how branch and officer roles are defined, and which configuration changes will be made in the UI versus through API calls that must be versioned.
Ask how the partner designs tenants and instances. Fineract identifies tenants with the Fineract-Platform-TenantId header and reads tenant connections from a tenants database, so ask who creates tenants, how a new institution is added without downtime, and how read, write and batch instances are sized. Confirm that the partner knows Liquibase migrations run only on write instances and can be run separately with the liquibase-only Spring profile. For PostgreSQL, the project recommends PostgreSQL as the database, so ask the partner to describe its backup schedule, point-in-time recovery, and the restore test they run at least once and record. A backup that has never been restored is not evidence. Ask for the restore runbook and the date of the last successful test.
Ask for penetration testing scope in writing. If your institution falls under the FTC Safeguards Rule, 16 CFR 314.4(d)(2) requires annual penetration testing and vulnerability assessments at least every six months unless effective continuous monitoring is in place, so the partner should state which option applies to your design. Require change management procedures, covering how Fineract configuration, product changes and code upgrades are approved and logged. Finally, insist on a fixed-scope written statement of deliverables, a clear separation between one-time implementation fees and recurring retainer support, response targets only if the partner commits to them in writing, and the notice period for upgrades to later quarterly Fineract releases.
Official sources for Fineract and the rules that apply
Where is the official Apache Fineract project website?
The official project site is the Apache Fineract website, maintained by the Apache Software Foundation project. It lists the current stable release, which is 1.15.0, and describes the core capabilities: client data and KYC documents, loan and savings portfolio management, real-time integrated accounting, reporting and configurable products and business rules. Start here to confirm the release your implementation will target. Fineract is licensed under the Apache License 2.0, so confirm the license terms with your legal team before you build any custom modules on top of it.
Where can I find the Fineract platform documentation?
The Fineract platform documentation describes the REST API, instance types and deployment patterns. Read it for the read, write and batch instance model, which the project recommends for high load, and for the note that Liquibase database migrations run only on write instances. Your engineers should also check how tenants are configured, since every API request carries a Fineract-Platform-TenantId header. The documentation is the reference to test against, but it is not a full production deployment guide, so plan the hosting design, backups and upgrade path as separate deliverables.
Where is the source code and issue tracker for Fineract?
The source code lives in the apache/fineract repository on GitHub. The README states that official releases are created quarterly at the end of each quarter, following the ASF release policy, and that end-of-life releases are archived. Use the release history to plan upgrade windows and to decide which version your team will certify in testing. Review open issues that touch the products you plan to use, such as group lending or savings accounts, before you commit to a configuration. Ask your partner to record the exact release tag used in the build so that patches can be traced later.
Why does Fineract recommend PostgreSQL over MariaDB or MySQL?
The Fineract README names PostgreSQL as the recommended database and states that MariaDB and MySQL are deprecated under proposal FSIP-9. The official Docker image ships only the PostgreSQL JDBC driver. Read the FSIP-9 proposal on standardizing on PostgreSQL to understand the reasoning and the timeline the project has set. If your institution has a database standard built on MySQL or MariaDB, raise it in scoping, because it changes the migration, backup and support work. Confirm with your partner how PostgreSQL will be run, backed up and patched inside your environment.
What does the FTC Safeguards Rule require for lenders?
The FTC Safeguards Rule at 16 CFR 314.4 applies to non-bank financial institutions under FTC jurisdiction, which can include microfinance lenders and some credit unions depending on their charter, so confirm your status with counsel. The rule requires encryption of customer information in transit over external networks and at rest, multi-factor authentication for any individual accessing an information system, change management procedures and activity logging for authorized users. Read the eCFR text of 16 CFR 314.4 directly, since the requirements are specific and your Qualified Individual must map each one to controls. DeployOpen can prepare systems, controls and evidence for that assessment, but it does not issue audit reports or certifications.
How often must penetration tests and vulnerability assessments run under the Safeguards Rule?
Under 16 CFR 314.4(d)(2), an institution without effective continuous monitoring must run annual penetration testing and vulnerability assessments at least every six months. The eCFR text is the authoritative wording, so read it before you write the test plan. Continuous monitoring, if it is effective, can replace the periodic tests in part, which affects the testing budget. Ask your security partner to confirm whether their scope covers the Fineract APIs, the Mifos X front end, the database and the hosting layer, and whether results will be retained as evidence for your examiners.
Can a small IT team run Fineract without an implementation partner?
A small team can run Fineract, but the project's own README warns that production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. Organizations often pay a vendor for deployment and maintenance. The workload that tends to fall on small teams includes PostgreSQL operations, read replica setup, tenant configuration, Liquibase migrations during upgrades, backup testing and evidence collection for change management. Before you decide, list who will own each item and how many hours per month that ownership takes. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own cloud, data center or air-gapped network, under written, fixed-scope agreements, with ongoing support available as a retainer.
How DeployOpen scopes, builds and supports a microfinance Fineract deployment
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and that is how we approach a microfinance lending deployment on Apache Fineract with Mifos X. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope covers loan products, interest methods, repayment schedules and the savings products linked to loans.
- Field officer roles, group lending structures and branch or center hierarchy are documented before configuration begins.
- Hosting target, database choice and tenant design are agreed with your team, including who owns each environment.
How we build
- Fineract is configured on PostgreSQL with the Mifos X front end, with products and business rules tested against your loan policy.
- Client data and KYC document migration is planned, rehearsed and reconciled against source records before cutover.
- Accounting integration, portfolio reports and security hardening are built and tested as named deliverables in the scope.
How we hand over
- Runbooks cover deployment, upgrades, backups, restores and the read, write and batch instance layout you approve.
- Configuration, product settings and change records are documented so your staff can audit and reproduce them.
- Your IT team is trained on administration tasks, and handover criteria are signed off against the written scope.
How we support
- Ongoing support, quarterly Fineract upgrades and continuous testing are available as a retainer after handover.
- Security testing of the application, APIs and infrastructure can be scheduled on a recurring basis under the same arrangement.
- Compliance evidence, such as access logs and change records, is prepared for your own auditors and assessors, who issue all opinions.
