Apache Fineract vs Mifos X: which to choose

Apache Fineract or Mifos X: when each one fits

Choose Apache Fineract alone when your team will build its own user interface and channels. Fineract is a headless, API-first core banking system licensed under Apache-2.0, and it ships without a front end of its own. If you already plan to build staff tools, client channels and partner integrations on your own stack, the bare API keeps the license simple and leaves the front end entirely in your hands. Choose Mifos X when you need staff and client applications sooner and can accept MPL-2.0 terms for the web and mobile layers. Mifos X is the Mifos Initiative's distribution that pairs a platform, a web client and a mobile client with Fineract as the backend, so it is a layering choice, not a rival product choice.

The decision turns on four questions. First, who owns the front end: if your product team will design every screen, Mifos X's web app may become code you replace rather than extend. Second, license terms: confirm with your legal team whether MPL-2.0 file-level obligations for the web app and mobile apps fit your distribution model, while Fineract itself stays under Apache-2.0. Third, release alignment: the Mifos X web app release v1.0.0-fineract1.14 targets Fineract 1.14, while Fineract's latest release is 1.15.0, so plan a test cycle to confirm that the front end and backend versions you deploy work together. Fourth, in-house skills: your team needs Java and PostgreSQL operations for Fineract in either case, plus Angular and OAuth/OIDC expertise if you adopt the web app.

Which platform fits which scenario

This table matches common team situations to the platform that fits better and the condition that decides it. Read each row as a starting point: where Mifos X's front ends would need replacing, the cell says so, because Fineract itself ships no user interface.

Scenario	Better fit	Condition that makes it so
Fintech building its own mobile banking app	Apache Fineract	Your team owns the customer app and wants only the API layer. Fineract's REST APIs carry the product logic, and the Mifos Mobile client would be a reference rather than a dependency you must keep.
Microfinance lender needing loan officer screens on day one	Mifos X	Staff need working screens for clients, loans and savings from launch. Mifos X's web client supplies these, and the Field Officer mobile app covers field collection, so confirm both match your workflows before committing.
Bank with an existing UI team	Apache Fineract	Your front-end engineers already build channel and staff interfaces. Fineract's headless design lets them build against the API, so the Mifos X web client would be replaced rather than extended, and its Angular stack would add a second framework to maintain.
Public-sector program wanting an out-of-the-box operator console	Mifos X	The program needs a staff console quickly and accepts the Mifos X web app's configuration options for OAuth or OIDC sign-in and role-based access control. Confirm that its access model and audit requirements meet the program's policy.
Team that wants an MPL-2.0 front end inside an Apache-2.0 back end	Mifos X	Your legal review accepts two licenses in one deployment. Mifos X is MPL-2.0 while Fineract is Apache-2.0, so have counsel confirm how the combined distribution fits your license policy.
Team that must keep the back end license permissive and fully separable	Apache Fineract	You want to swap or retire the front end without affecting the core. Fineract's API-only design makes that separation possible, though you will carry the cost of building or buying every screen.
Team planning to run a multi-tenant core for several lenders	Apache Fineract	You need tenant isolation handled by the core. Fineract uses the Fineract-Platform-TenantId header and a tenants database, and the web client must be configured to target the correct tenant for each deployment.
Team relying on Mifos X's upstream development path	Apache Fineract	You expect current Mifos X work to land in Fineract and the openMF web and mobile repositories. The original mifosx repository is archived, so plan upgrades against the Fineract release cycle and confirm the web app's current Fineract target.

How Mifos X sits on top of Fineract

Apache Fineract is the engine and Mifos X is the distribution built around it. Fineract is a headless, API-first core banking system licensed under Apache-2.0. It exposes REST APIs for client data and KYC documents, loan and savings portfolios, real-time integrated accounting, reporting and configurable products. It is multi-tenant: each API request carries a Fineract-Platform-TenantId header, and tenant connections are read from a tenants database. Fineract does not ship its own user interface. Mifos X adds a platform, an Angular web client and mobile apps on top of that backend, and the platform components are licensed under MPL-2.0 rather than Apache-2.0, so license review must cover both layers.

The Mifos X web app is an Angular single-page application that calls Fineract as its backend. Its release line is versioned against Fineract: the newest release, v1.0.0-fineract1.14, was published on December 23, 2025, while Fineract's latest release is 1.15.0, released July 14, 2026. Your front end can therefore trail the backend by a release. Before you upgrade Fineract, confirm which web app build supports the target version, test the role-based access, OAuth or OIDC sign-in and client data masking settings against the new backend, and plan the front end upgrade as its own change.

The original openMF/mifosx repository is archived and renamed Deprecated-mifosx, so current development sits in Apache Fineract and in the separate openMF web and mobile app repositories. Treat any tutorial or fork that starts from the archived code as legacy. When you scope a deployment, ask which repositories and release branches your chosen partner will track, and who will maintain the forked web client if you customize it. The Mifos X web app repository is the natural starting point for checking the current release line.

How each deployment is built and what it means for operations

Fineract ships as an API-only engine, while Mifos X adds a web client and mobile apps on top of it. The cards below cover what your team runs, how instances and migrations are split, which database to standardize on, and how the front-end pieces are installed and released.

Headless API-only engine

Apache Fineract is a headless, API-first core banking system with REST APIs and no user interface of its own. Your team owns every screen, staff workflow and customer channel unless you deploy a front end. Mifos X supplies one, so with Mifos X you run the engine and the web client together, while with Fineract alone you plan the front-end build as a separate workstream. Confirm early which channels you need on day one.

Read, write and batch instances

Fineract instance types are set by environment variables. The documentation recommends one write instance, one batch instance and multiple read instances on database read replicas for high load. Mifos X does not change this model, so the topology is the same whichever distribution you choose. Size the read tier from your reporting and self-service traffic, and confirm the exact variable names against the current documentation for your release.

Liquibase migrations on write instances

According to the Fineract documentation, Liquibase database migrations run only on write instances. On Kubernetes you can run them as a separate job using the liquibase-only Spring profile, so schema changes happen before application pods roll. Build this ordering into your upgrade runbook and test it in a non-production tenant first. Whoever upgrades the platform, whether your team or a Mifos X partner, needs to know which pod runs the migration.

PostgreSQL as the standard database

PostgreSQL is the recommended database for Fineract. The README marks MariaDB and MySQL as deprecated under FSIP-9, and the official Docker image ships only the PostgreSQL JDBC driver. If you are starting fresh, plan on PostgreSQL and your team's PostgreSQL operations skills. If you already run MariaDB or MySQL, confirm the migration path with your Fineract or Mifos X provider before you upgrade.

Mifos X web app install paths

The Mifos X web app documents manual, Docker and Docker Compose installation, with configuration for the Fineract backend, OAuth and OIDC sign-in, password policy, client data masking, interbank transfers and role-based access control. Manual installs give the most control over hosting, while Docker Compose suits evaluation and small environments. Choose the path your platform team can patch and monitor, and confirm which options your production security baseline requires.

Separate mobile apps and cadence

The Field Officer app and Mifos Mobile banking app live in their own openMF repositories, separate from Fineract and the web app. Each has its own release cycle, so the mobile versions you ship may not match the backend release you run. Ask for a compatibility matrix in writing, include both mobile apps in your test plan, and decide who owns app store publishing and updates.

How identity and extensibility differ between the two

Fineract is headless. It exposes REST APIs and does not ship a user interface, so the identity, front end and channel logic are yours to design and integrate. Your team decides how staff and customers authenticate, which framework renders screens, and how mobile or partner channels call the API. Tenant handling is also part of your design, because API requests carry a Fineract-Platform-TenantId header and tenant connections are read from a tenants database.

Identity integration: Fineract's own authentication model and your identity provider must be connected deliberately. Confirm how your provider's tokens map to Fineract users and roles before build starts.
Front-end choice: Any framework can call the APIs, which suits teams with an existing design system. The cost is that screens, workflows and accessibility work are built and maintained by you.
Channel logic: Customer onboarding, consent and KYC flows sit in your code, so their control evidence must be designed in from the start.
Tenancy design: Decide early whether one tenant or several serves your business units, since the tenant header is part of every request.
Extension surface: Custom logic is added around the APIs in your own services, which keeps upgrades separate from your code but moves testing work to your team.

Before committing, confirm with your identity provider vendor and your Fineract version which authentication mechanism your integration will use, and have your security team review the token flow end to end.

Capability comparison: Fineract and Mifos X

This table compares Apache Fineract, the API-only core banking engine, with Mifos X, the distribution that adds web and mobile apps on top of it. Read each row as a question about what your team receives out of the box and what it must build, configure or confirm before go-live.

Capability	Apache Fineract	Mifos X
License	Apache-2.0 for the core engine	Mifos X distribution is MPL-2.0; the web app is MPL-2.0; confirm the license of any custom code you add
Scope	Headless core banking engine covering client data, KYC documents, loan and savings portfolios, accounting and configurable products	Fineract backend plus web client and mobile clients, so staff and client screens come with the distribution
User interface	None. REST APIs only, so your team builds or chooses every screen	Angular web app for staff, plus Field Officer and Mifos Mobile apps; extend or brand them through your own build
Database	PostgreSQL is the recommended database; MariaDB and MySQL are deprecated	Inherits the Fineract database choice; confirm the supported setup with the current distribution documentation
Deployment paths	Self-hosted on your infrastructure; the project warns production deployment can be complex and may need a vendor	Manual, Docker and Docker Compose installation documented for the web app; cloud or on-premises deployment through partners
Multi-tenancy	Multi-tenant through the Fineract-Platform-TenantId header and a tenants database	Inherits Fineract tenancy; confirm how the web app is pointed at each tenant in your build
Identity sign-in options	Authentication is handled by the Fineract backend; you design identity integration around it	Web app documents OAuth and OIDC sign-in, password policy and role-based access control
Release line	Fineract 1.15.0 released July 14, 2026; quarterly releases at quarter end	Web app v1.0.0-fineract1.14 published December 23, 2025, targeting Fineract 1.14; confirm the matching backend release
Mobile apps	None included	Mifos X Field Officer app and Mifos Mobile banking app are maintained in the openMF organization

What each license and distribution gives you

Apache Fineract is an Apache Software Foundation project licensed under the Apache License 2.0 (SPDX: Apache-2.0). That license lets you use, modify, redistribute and embed the engine in commercial products, provided you keep the license and notices. The project publishes official releases quarterly, at the end of each quarter, following the ASF release policy, and archives end-of-life releases. The current stable release is 1.15.0.

Permissive license: You can fork, patch and ship Fineract inside your own product without releasing your changes under the same license.
Quarterly cadence: Releases arrive at quarter end, so plan an upgrade window at least once per quarter if you intend to stay on supported lines.
End-of-life archiving: Old releases are archived when they reach end of life, which means your upgrade path has to land on a supported version.
No bundled interface: The license covers the headless API engine only, so the screens your staff and customers use are a separate decision.
Governance: Support comes from the community and from any vendor you contract, not from a single commercial owner.

Check with your legal team that Apache-2.0 terms fit your redistribution model, and confirm with your vendors which Fineract release line they support and for how long.

What drives the running cost of each

Running Fineract or Mifos X costs more in people and infrastructure than in licenses, since both are open source. The cards below separate the infrastructure you size, the skills you hire, the support you may buy, and the upgrade and front-end work that recurs after go-live.

Database and read replicas

Fineract standardizes on PostgreSQL, so your database footprint is a PostgreSQL estate with its own backup, failover and patching work. The Fineract documentation recommends one write instance, one batch instance and multiple read instances on database read replicas for high load. Each replica adds compute, storage and monitoring. Ask any implementation partner to size the replica count from your expected transaction and reporting load, and to state who runs failover.

Write, read and batch instances

Fineract's documentation describes read, write and batch instance types set by environment variables. Liquibase migrations run only on write instances, and on Kubernetes they can run separately using the liquibase-only Spring profile. Batch work such as scheduled accruals and interest postings runs on its own instance, so it does not compete with customer traffic. Each extra instance type is another deployment unit to monitor, scale and roll forward during upgrades.

Java and Spring engineering skills

Fineract is a headless REST API written on the Java and Spring stack, so the team that extends it, tunes it and debugs production issues needs Java and Spring experience. Mifos X adds the same backend skills, plus the web and mobile clients around it. Confirm whether your team already has Java engineers on staff, or whether you will pay a partner for that capacity on an ongoing basis.

Angular skills for the web app

The Mifos X web app is an Angular single-page application under MPL-2.0. If you choose Mifos X, your frontend team must maintain Angular code, including customizations to screens, roles and configuration such as OAuth and OIDC sign-in, password policy and client data masking. Ask whether that work is in scope for the first deployment, and whether it will be carried by your staff or a partner retainer.

Vendor support options

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. It notes that organizations may pay a vendor for deployment and maintenance. Mifos X can be deployed in the cloud or on premises through partners listed in a partner directory. Compare the scope of each quote: installation only, a managed run service, or a fixed-scope implementation followed by a support retainer.

Upgrades and trailing front ends

Fineract publishes official releases quarterly, and the latest is 1.15.0. The newest Mifos X web app release, v1.0.0-fineract1.14, targets Fineract 1.14, so the web app can trail the backend by a release. Each backend upgrade therefore may need a web app upgrade or a wait, plus regression testing of your customizations. Ask any partner how many upgrade cycles per year their quote covers and who signs off on compatibility before each release moves to production.

Moving from Fineract alone to Mifos X, or the reverse

This sequence shows how a team moves between a bare Fineract deployment and a Mifos X deployment without losing portfolio data, and which front-end work has to be rebuilt rather than carried over.

Confirm tenant and data model compatibility
Start by confirming that both environments run the same Fineract line and point at the same tenant layout. Fineract is multi-tenant, with requests carrying the Fineract-Platform-TenantId header and tenant connections defined in a tenants database, so the team should list every tenant, its database, and its configured products, offices and business rules in both environments. Your platform engineer and the Fineract administrator own this check. It is done when a written inventory matches tenant by tenant and a sample of client and loan records reads back identically through the API in both stacks. Because Mifos X uses Fineract as its backend, the data model is shared, so most of the work is confirming configuration, not converting schemas.
Decide the fate of custom front ends
Next, list every custom front end, mobile app, integration and channel workflow that calls the Fineract REST APIs today. Moving to Mifos X replaces the standard web client, and moving the other way means you must supply your own user interface, because Fineract does not provide one. Decide for each item whether it is retired, kept as-is against the API, or rebuilt. The product owner, the channel team and the security lead should sign the decision register. The step is complete when every custom client has an owner and a disposition. Most of the effort here sits in channel logic, such as approval flows and customer-facing screens, which does not move with the data.
Align the web app with the Fineract release line
Match the front-end version to the backend before any cutover. The Mifos X web app is a separate Angular repository under MPL-2.0, and its newest release, v1.0.0-fineract1.14, targets Fineract 1.14, while the current Fineract release is 1.15.0. A web app can trail the backend by a release, so the team must decide which Fineract line it will run and then confirm the web app release that supports it. The platform lead should record the pinned versions for both components and confirm with the openMF maintainers or in the web app documentation that the combination is supported. The step is done when the pinned pair is documented and tested in a non-production environment.
Stage a copy of the database and test Liquibase
Restore a recent copy of the production PostgreSQL database into a staging environment and run the Fineract upgrade or migration against it. Fineract runs Liquibase migrations only on write instances, and on Kubernetes they can run separately with the liquibase-only Spring profile, so the team should follow that sequence in staging and record the output. Standardizing on PostgreSQL is the recommended path, so any MariaDB or MySQL source needs its own plan before this step. The database administrator and the Fineract operator should confirm that migrations complete, that row counts and loan balances reconcile, and that the application starts cleanly against the migrated schema. Keep the staging log as evidence for the change record.
Cut over authentication
Move sign-in before users reach the new front end. The Mifos X web app supports OAuth and OIDC sign-in and role-based access control, so the identity team should map existing roles and groups to the Fineract and web app roles and test each one with named test accounts. If you are moving away from Mifos X, the replacement front end and the Fineract API must accept the same identity provider and token claims. Confirm that password policy and client data masking settings carry over. The identity lead signs off when test users reach only the screens and records their roles allow, and when a rollback path for sign-in is documented.
Run the cutover and verify transactions
Schedule the production cutover in a change window agreed with the business owners. Freeze writes, run the verified migration, start the new front end, and reconcile a set of loan, savings and accounting transactions against the pre-cutover snapshot. The release manager runs the cutover and the finance lead validates the reconciled figures. Keep the old environment intact until reconciliation passes. The step closes when balances, accounting entries and reports match the snapshot and at least one full business cycle has been observed without incident in the new environment.
Retire unused components and document the result
Once the new stack has run cleanly, remove what is no longer used: old front-end builds, unused custom clients, stale service accounts, and the previous environment's scheduled jobs. Update the architecture diagram, runbooks and backup scope so that they reflect the new components. The operations team should archive the old configuration and record which custom items were rebuilt and which were dropped. The step is complete when the inventory from the first step has no open items and the documentation lists the pinned Fineract and web app versions, tenant configuration and authentication setup.

Where Fineract and Mifos X implementation projects run long

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. Plan for that gap before you compare licenses or features. Mifos X inherits the same backend work, so the effort sits mostly in Fineract configuration and operations, with the web client as an additional layer on top. Organizations that lack in-house Fineract operators often pay a vendor for deployment and maintenance, which the README itself notes. The longest workstreams are usually the ones with no default answer. Multi-tenant setup is one: API requests carry a Fineract-Platform-TenantId header and tenant connections come from a tenants database, so each legal entity, brand or environment needs a deliberate tenant design. Read, write and batch instance topology is another. The Fineract documentation recommends one write instance, one batch instance and multiple read instances on database read replicas for high load, and it sets these roles through environment variables. Confirm your expected load profile before sizing the topology, because the replica count and failover design drive both infrastructure and testing time.

Migrations and integrations add more time. Liquibase migrations run only on write instances, and on Kubernetes they can run separately with the liquibase-only Spring profile, so your release pipeline must sequence them correctly. Identity integration (OAuth and OIDC sign-in in the Mifos X web app, role-based access control) needs mapping to your directory and roles. Product and business rule configuration, data migration from legacy loan or savings systems, and front-end customization of the Angular web app each need written acceptance criteria. DeployOpen scopes these areas in writing before work starts, through a fixed-scope agreement with defined deliverables. Ask any implementation partner, DeployOpen included, to name each tenant, instance, migration, identity and data-migration item, and the acceptance test for each. No duration is promised here. Timelines follow from that written scope and your own environment.

Questions buyers ask before choosing Fineract or Mifos X

Can we run Apache Fineract without Mifos X?

Yes. Fineract is the headless, API-only core banking engine, so it runs without any user interface and does not depend on Mifos X. The Fineract README points to the Mifos X web application only as the front end in its Kubernetes example. Without Mifos X, your team or a partner builds the staff screens, customer channels and integrations against the REST APIs. Confirm the API coverage for each product and workflow you need before you decide, because the work you skip with Mifos X becomes your build list if you go headless. Fineract also uses a Fineract-Platform-TenantId header for multi-tenant requests, which your integration design must handle.

Is Mifos X enough for a regulated lender?

Mifos X can supply the staff and client-facing applications on top of Fineract, but it does not make a lender compliant on its own. Regulatory fit depends on your licensing jurisdiction, the products you offer and the controls you can evidence. The Mifos X web app documents OAuth and OIDC sign-in, password policy, client data masking and role-based access control, which map to common control areas. Confirm each of these against your regulator's expectations and your own control library. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.

What skills does our internal team need?

Plan for database, integration and security skills first. Fineract standardizes on PostgreSQL, and its README marks MariaDB and MySQL as deprecated, so your DBA team needs PostgreSQL operations experience. Fineract is a Java backend that exposes REST APIs, so your engineers must be comfortable with API integration and Liquibase-managed schema changes. If you adopt Mifos X, add Angular web app configuration and OIDC setup. Your team also owns the operating model: upgrades, backups, monitoring and access reviews. Ask any implementation partner which of these they will hand over and which they will keep running.

How long does an implementation take, and what drives the timeline?

No supplied fact gives a standard implementation duration, so treat any figure you hear with caution and ask for one based on your scope. 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 drivers are the number of products you configure, the integrations with your ledger, KYC and payment rails, the data migration from legacy systems, and the hosting design, including how you split write, batch and read instances on database replicas. Mifos X adds time for branding, role design and identity integration. Ask for a milestone plan tied to these drivers.

What drives cost, and what should we ask for in a fixed-scope quote?

Costs fall into one-time work and recurring work. One-time items include discovery, configuration, integration, data migration, hardening and documentation. Recurring items include hosting, database operations, upgrades, backups, monitoring and support. Fineract and Mifos X are open source, so license fees are not the main line item; the work and infrastructure are. DeployOpen does not publish prices, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask the quote to list each product and workflow in scope, each integration, the environments and hosting model, the migration volume, the test approach, the handover items and which upgrades and support tasks are included or sold as a retainer.

Does MPL-2.0 create obligations for our Mifos X deployment?

It can, and the obligations fall on how you distribute modified MPL-2.0 files, not on running the software internally. Mifos X is licensed under MPL-2.0, while Apache Fineract is Apache-2.0. The Mifos X web app is an MPL-2.0 Angular single-page application. MPL-2.0 is a file-level copyleft license, so modifications to MPL-licensed files you distribute may need to be shared under MPL-2.0, but separate files you add can remain under other terms. Confirm the exact obligations with your legal counsel, especially if you ship a customized front end to customers or partners. Keep a record of every modified file so the answer is easy to produce.

What happens when the web app trails the Fineract release?

The web app can lag the backend. Fineract 1.15.0 was released July 14, 2026, while the newest Mifos X web app release, v1.0.0-fineract1.14, was published December 23, 2025 and targets Fineract 1.14. Plan a compatibility check before every backend upgrade, and test the web app against the new Fineract version in a non-production environment. Decide whether you will pin to a tested pair, backport fixes, or move to a headless front end that your team controls. Ask your vendor how they handle this gap, who owns the regression tests, and how long a tested pair stays supported. Fineract releases quarterly, so the cadence matters for your upgrade budget.

What a core banking deployment still needs from your own controls

Neither Apache Fineract nor Mifos X comes with a certification, and neither product issues an audit report or attestation. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies are the ones who issue reports. Whatever the software does out of the box, your team owns the design of its controls and the proof that they work in your jurisdiction, and you should confirm the applicable requirements with your own compliance and legal advisers before go-live.

Start with access control and tenant isolation. Fineract is multi-tenant: API requests carry a Fineract-Platform-TenantId header and tenant connections are read from a tenants database, so a misrouted or spoofed header is a data exposure risk. Decide who may create tenants, which roles can read across them, and how the tenants database itself is protected. If you deploy Mifos X on top, its web app adds OAuth and OIDC sign-in, a password policy and role-based access control, and those settings must be mapped to your identity provider and your approval workflow, not left at defaults. Audit logging and backup are the other two areas that the software will not design for you. Confirm where Fineract's application events are written, how long they are kept, and who can alter them. Test restores of the PostgreSQL database, and of the tenants database, on a schedule you can document, because a backup that has never been restored is not evidence of recovery.

KYC document handling is the area where Fineract's data model makes the decisions for you, so review it early. Client data and KYC documents are stored within the platform, which means retention periods, encryption at rest, access to scanned identity documents and deletion requests all become your obligations. Mifos X's client data masking setting can limit what field officers see, but you must verify which fields it covers in your configuration. A useful first step is a short written control matrix that names each control, its owner, the evidence it produces and the test that proves it works. DeployOpen can help plan and document that matrix and the testing behind it, while the assessment itself stays with your independent auditor.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Apache Fineract vs Mifos X, that means starting from your product list, control expectations and front-end plan, then building only what the chosen stack needs.

How we scope

Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts
Scope records whether Fineract alone or the Mifos X web and mobile apps are in the build
Written scope names the Fineract version, PostgreSQL setup and tenant layout being delivered
Scope lists which custom front ends, integrations and reporting your team must still build
Quotes follow from the written scope, so ask for line items per component and per deliverable

How we build

Deployment into your own infrastructure, with read, write and batch Fineract instances configured as agreed
Configuration of identity sign-in, role-based access and password policy for the chosen front end
Integration work covering your general ledger, payment rails and KYC data sources as scoped
Security testing of the deployed APIs and front end before handover
Documentation of configuration, upgrade steps and evidence needed for your compliance assessment

How we hand over

Written handover covering architecture, configuration, runbooks and known gaps versus your requirements
Knowledge transfer sessions so your platform or banking engineers can operate the stack
Clear record of which components are Apache-2.0 and which are MPL-2.0 for your legal review
Evidence packages prepared for independent auditors, which DeployOpen does not itself issue

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers can cover tracking Fineract quarterly releases and planning upgrades against your change windows
Front-end upgrades can be scheduled separately, since the web app can trail the backend by a release
Support scope is agreed in writing, including who handles database and infrastructure changes

Apache Fineract vs Mifos X