Thought Machine Vault vs Apache Fineract: which fits your institution
Start with the reason you are looking at this comparison. It is usually a renewal date, a licence question raised by finance, or a board-level decision to own the core system rather than depend on a single vendor. Those triggers point in different directions. Vault Core is built for banks that want to buy a licensed, cloud-native product engine, where financial products are modelled as Python smart contracts on a single ledger and the vendor supports the platform across deployment options. Apache Fineract is an Apache 2.0 core that lenders and microfinance institutions host, configure and change themselves, with no product licence to renew. The two are rarely interchangeable for the same institution, so the first question is which of these operating models you actually want to run.
The decision turns on four things. First, product complexity: if your roadmap needs many custom deposit, lending or fee behaviours expressed as code and tested as a product engine, Vault Core's model is designed for that. If your products are mainly loans and savings with configurable rules, Fineract's configuration-driven products may be enough. Second, in-house engineering depth: Fineract is a headless REST system with no built-in user interface, and its own documentation warns that a production deployment can be complex, costly and time-consuming, and that organizations may pay a vendor for deployment and maintenance. Third, regulatory expectations: ask how each option maps to your change management, access control and audit evidence requirements, and confirm which of those controls you would build yourself. Fourth, the run team you can staff. Ask yourself who will patch, upgrade and back up the platform after go-live, and whether that team exists today.
Which option fits which institution and situation
This table matches common institution types and situations to the platform that usually fits better, and names the condition that drives each choice. Read each row as a starting point: both products can be configured for many of these cases, so the deciding factor is usually the operating model, the team and the product set.
| Situation | Better fit | Condition that drives the choice |
|---|---|---|
| Tier-one bank replacing a legacy core | Thought Machine Vault | Vault is built for large, multi-product banks with a smart-contract engine, and its vendor documents on-premise, hybrid and SaaS options. Fineract can serve large volumes, but the bank must own the product engineering, testing and run team. |
| Lender with loan and savings portfolios | Apache Fineract | Fineract covers client data, loan and savings portfolio management and accounting in one headless system. A lender with standard products and a team comfortable running Java and PostgreSQL will find its configuration model a direct match. |
| Microfinance network running multiple tenants | Apache Fineract | Fineract is multi-tenant by design, with a tenant header on API requests and a tenants database. Confirm tenant isolation, backup and upgrade procedures for your own deployment model before committing. |
| Fintech with a narrow product set | Apache Fineract | A small number of standard products suits configuration over custom code. Confirm that the products you need are supported by configuration and identify which ones would require custom development. |
| Institution with a strict data residency rule | Depends on hosting model | Both can run in your own cloud account or data center. Confirm the vendor's supported hosting options for Vault, and for Fineract, confirm that your team will operate the stack and its database in the required jurisdiction. |
| Institution that needs a vendor-supported run service | Thought Machine Vault | Vault is a licensed product with vendor-run deployment options. Fineract's README notes that organizations may pay a vendor for deployment and maintenance, so ask a partner for a written support scope. |
How the product models differ: smart contracts versus configured products
In Thought Machine Vault Core, a financial product is modeled as a Python smart contract that runs on a single ledger. The contract is where the product's behavior is expressed, so a product definition is source code that the bank can version, review and deploy in the same way as other software. Teams that adopt this model treat a loan or deposit product as a software artifact with an owner, a change history and a release path.
- Code as the definition: Fee, interest and schedule logic is written in Python, so a change to product behavior is a change to a source file.
- Shared ledger: Products run against one ledger model, so posting behavior is defined in the platform rather than repeated in each product build. Confirm exactly which posting primitives the contract interface exposes.
- Skill requirement: Product changes need developers who can read and write the contract interfaces, which shifts some product work from business analysts to engineers.
- Vendor-supplied versus bank-built: Confirm which product types the vendor supplies and which the bank must write.
Before you map your product list, confirm with the vendor which contract interfaces, versioning and deployment controls are available in your chosen deployment model.
Apache Fineract describes itself on its website as covering client data and KYC documents, loan and savings portfolio management, real-time integrated accounting, reporting, and configurable products and business rules. In this model a product is a set of parameters and rules that the platform evaluates through its REST APIs, so many product changes are made by supplying configuration rather than writing new code. Read the Fineract project site for the current feature list before you scope.
- Headless design: Fineract exposes REST APIs and provides no user interface of its own. Its Kubernetes example uses the Mifos X web application as the front end, so the staff experience depends on the front end you select.
- Multi-tenant model: API requests carry a Fineract-Platform-TenantId header, so each tenant or legal entity is configured and reported on separately.
- Limits of configuration: Behavior outside the configurable options generally requires development in the Java codebase. Confirm how often your products depart from the standard options.
- Accounting and reporting: Accounting is integrated with the portfolio records, which reduces the number of reconciliation steps between systems. Confirm the chart of accounts and report formats your finance team requires.
For each product on your list, identify the configuration option that covers it and flag any feature that needs code.
The two models place product ownership in different roles. In a smart-contract engine, product behavior changes pass through engineers who build and release the contract code, with product owners approving the intent. In a configured platform, trained administrators can change many parameters directly, and developers are needed mainly for capabilities the configuration does not cover. This split determines how quickly a product team can respond to market changes and who must be available for each change.
- Product owners: In Fineract, staff with the right administrative permissions can adjust product parameters through the front end, subject to access controls you define.
- Engineers: In Vault Core, a product change is usually a code change that moves through a release pipeline and approval gates.
- Partner role: Both models often involve an implementation partner or vendor for initial build, so confirm who supports changes after go-live and under what terms.
- Release cadence: The Fineract README states that official releases are created quarterly, so plan an upgrade cycle for the platform itself as well as for product changes.
- Approval records: Define who can approve a parameter or code change and where that approval is recorded.
Write down the approval chain for product changes in each model before you decide which skills to hire or contract.
Testing follows the design. Contract logic can be covered by automated tests in the same repository as the product, and the release gate can be tied to those results. Configured products are tested by exercising the APIs in lower environments and comparing the resulting settings with production, which makes configuration drift a central control. Either way, a regression set of representative accounts is the strongest evidence that a change did what was intended.
- Code tests: Contract logic can be tested before release, but confirm the platform's test tooling and how it integrates with your pipeline.
- Configuration drift: Fineract product settings live in the database, so promotion between environments requires an export and comparison step.
- Schema migrations: The Fineract documentation states that Liquibase migrations run only on write instances, and on Kubernetes they can run separately with the liquibase-only Spring profile. Put that step in the release runbook.
- Production guidance: The Fineract README notes that it does not provide a comprehensive production deployment guide, so the controls must be written by your team or partner.
- Regression set: Maintain sample loans, deposits and fee scenarios that every change must pass.
Ask each vendor or project for its promotion model and test tooling, then agree one regression suite that covers your highest-volume products.
How Thought Machine Vault and Apache Fineract compare on capability
This table compares Thought Machine Vault Core and Apache Fineract on licence, product modelling, delivery, interface, APIs, tenancy, messaging, database, release cadence and production readiness. Rows marked for confirmation depend on Vault terms that are only available from Thought Machine, so verify them in writing before drawing conclusions. The main takeaway is that Fineract is open and self-operated but needs your own production engineering, while Vault is a licensed, vendor-supported product.
| Capability | Thought Machine Vault Core | Apache Fineract |
|---|---|---|
| Licence | Commercial licence to banks. Confirm terms, IP ownership and support scope with Thought Machine. | Apache License 2.0 (Apache-2.0), with no vendor licence fee for the software |
| Product modelling | Financial products written as Python smart contracts on a single ledger | Configurable products and business rules set through the platform, without custom code as the default model |
| Delivery model | Google Cloud, AWS, Microsoft Azure, IBM Cloud, on-premise, hybrid with Red Hat OpenShift, and SaaS, per the 2020 announcement | Self-hosted by the operator. Docker images and a Kubernetes deployment are documented, but production build and operation are your responsibility |
| User interface | Vendor-supplied product surfaces. Confirm which operator and customer interfaces are included in your contract. | Headless with REST APIs and no UI of its own. The Kubernetes example uses Mifos X as the front end |
| APIs | Confirm the API surface and versioning with the vendor before integration design | REST APIs as the primary interface |
| Multi-tenancy | Confirm tenancy model for your deployment with the vendor | Multi-tenant. Requests carry a Fineract-Platform-TenantId header, and tenant connections come from a tenants database |
| Event messaging | Confirm supported event and streaming integration with the vendor | Supports ActiveMQ and Apache Kafka for events |
| Database | Confirm supported data stores with the vendor | PostgreSQL recommended. MariaDB and MySQL are deprecated under FSIP-9, and the Docker image ships only the PostgreSQL driver |
| Release cadence | Confirm release and upgrade schedule, and who tests and deploys upgrades | Official releases quarterly at the end of each quarter, under the ASF release policy. Current release is 1.15.0 |
| Production readiness | Vendor-delivered and supported. Confirm the support scope in your contract. | Docker images are not production-ready per the project. The README warns production deployment can be complex, costly and time-consuming |
Who controls data and hosting in Thought Machine Vault vs Apache Fineract deployments
Hosting model, key handling, access and audit evidence decide who controls customer data in a core banking deployment. Vault Core and Fineract answer these questions very differently, so the cards below set out what the institution owns and what the vendor or the project provides.
Where the data lives
Vault Core is offered as SaaS, on-premise, in hybrid setups with Red Hat OpenShift, or on Google Cloud, AWS, Microsoft Azure and IBM Cloud, according to Thought Machine's announcement of June 29, 2020. Fineract has no hosting model of its own: it runs wherever the institution deploys it, including its own data center or air-gapped network. Confirm with Thought Machine which option, region and sub-processors apply to your contract, and whether backups and logs leave that region.
Hosting responsibility split
With Vault Core in SaaS, the vendor operates the platform and the bank governs it through contract and oversight. Bank-hosted Vault shifts operations, patching and capacity to the bank. Fineract puts every layer on the institution or its integrator, including the database, which the project recommends as PostgreSQL. Write the split down by layer (infrastructure, database, application, backups, monitoring) before comparing costs.
Key management and secrets
Ask who holds the encryption keys for databases, backups and any cloud key service, and whether the bank can rotate them without vendor involvement. For Fineract, the institution chooses the key store, secrets tooling and database credentials, and must handle the Docker and Kubernetes secret path itself. The Fineract Docker images are not production-ready, so the hardened image and secret handling are part of the build scope.
Identity and access for operators
Fineract is headless and exposes REST APIs, with multi-tenant access controlled by the Fineract-Platform-TenantId header and a tenants database. Access control for staff, admins and integrations therefore sits in the surrounding stack, such as the front end, gateway and identity provider. For Vault Core, confirm how vendor support staff reach production, who approves that access, whether sessions are logged, and whether the bank can revoke it.
Audit evidence and logs
Each platform produces different evidence. Vault Core audit trails and vendor operational logs depend on the deployment option and contract, so request sample logs and a retention statement before signing. Fineract logs, database audit settings and the event bus (ActiveMQ or Apache Kafka) are configured by the institution, so the bank must decide what to record, where it is kept and how it is protected.
Compliance responsibilities
Neither product confers certification. Readiness depends on the institution's own controls, documentation and operating evidence, and attestations come from independent auditors or certification bodies. Confirm with Thought Machine and the Fineract project (or your integrator) what documentation they supply for data processing terms, support access and shared responsibility, and have your legal and compliance team review it against the regulator's expectations.
What running Fineract on Kubernetes and cloud involves
Running Apache Fineract on Kubernetes is possible, but the project does not present it as a finished path. Fineract publishes Docker images and documents a Kubernetes deployment, yet its images are not production-ready, and the README warns that a production deployment can be complex, costly and time-consuming. The project does not provide a comprehensive production deployment guide, and it notes that organizations may pay a vendor for deployment and maintenance. Your platform team should treat the cluster design, hardening, backup and upgrade process as work you own or contract out, and plan that work before choosing Fineract for a regulated core.
Fineract's runtime is split by role, and those roles are set through environment variables. A read instance serves queries, a write instance handles changes, and a batch instance runs scheduled work. The Fineract documentation recommends one write instance, one batch instance and multiple read instances on database read replicas for high load. Liquibase database migrations run only on write instances, and on Kubernetes they can run as a separate job using the liquibase-only Spring profile. Ask your engineers to confirm these settings against the release you plan to run, and to write down which pod owns migrations, so an upgrade does not run schema changes from several places at once.
Fineract is multi-tenant. Each API request carries a Fineract-Platform-TenantId header, and tenant connections are read from a tenants database, so each institution or business unit usually gets its own tenant database. That design affects backup scope, restore testing, and how you size PostgreSQL, which the README recommends. Compare this with Vault Core, where Thought Machine offers on-premise, hybrid with Red Hat OpenShift, bank-hosted and SaaS options, so the operating burden sits with the vendor or a managed partner rather than only with your team. Before you commit, confirm with your security team which cloud provider, cluster standard, image provenance rules and key management approach they require, and whether a self-run Fineract cluster meets them.
What drives the cost of each option
Both sides of this comparison carry costs in different places. A Vault Core program pays a vendor for the platform and its delivery, while a self-hosted Fineract build moves those costs onto your own team and partners. Quotes for each side follow from a written scope, so the cards below list what to ask each vendor or partner to include.
Licence or subscription
Vault Core is a commercial licence delivered as SaaS or bank-hosted, so the recurring line is what the vendor charges for the platform and its updates. Apache Fineract is Apache 2.0 licensed, so there is no licence fee, but the code, its upgrades and its security fixes still need a funded owner. Ask Thought Machine exactly what the subscription covers, including hosting, upgrades, support tiers and any usage-based terms tied to accounts or transactions. Ask what the contract says about exit and data return.
Infrastructure and hosting
With Fineract you pay for the Kubernetes clusters, PostgreSQL, messaging and environments that you run, and these recur every month. The Fineract documentation describes separate read, write and batch instances, so sizing depends on transaction volume and how many read replicas you need. Vault Core moves much of this into the vendor's cloud or your bank-hosted environment, so ask which infrastructure lines appear on your own bill.
Product engineering
Vault Core models products as Python smart contracts, so new products are built and tested by engineers who know that language and the vendor's product model. Fineract's products are configured, but custom business rules still require Java development and careful testing. Estimate this cost by counting planned product types and variants, then ask each side which product templates, rule libraries and changes to roadmap items are included in the quote.
Integration and data migration
Core banking cost is often dominated by connecting payments, card, KYC, general ledger and reporting systems, plus moving customer and account balances from the current core. Fineract exposes REST APIs and supports Kafka or ActiveMQ for events, so you build and maintain each connector. Ask whether the Vault quote includes integration work, migration tooling and reconciliation support, and who owns cutover risk.
Testing and assurance
Testing a core for a regulated bank includes functional, regression, performance, security and control evidence. The Fineract README warns that a production deployment can be complex and time-consuming and that it lacks a comprehensive production deployment guide, so most self-hosted programs must fund that work themselves. Ask Thought Machine what test environments, reference data and assurance evidence it supplies, and what your own testers, auditors and penetration testers must still provide.
Run team for operations and upgrades
The run team covers patching, upgrades, backups, monitoring, on-call and incident response, and this cost recurs for the life of the platform. Fineract publishes quarterly releases, so someone must plan and test each upgrade. Vault Core shifts much of the upgrade and platform operation to the vendor, but you still need product owners and operations staff. Ask both sides which on-call hours, service levels and upgrade windows are covered, and what skills you must hire or retain.
What moving from Thought Machine Vault to Fineract involves
The sequence turns Vault's smart-contract product set into Fineract's configured products, moves client and portfolio records with reconciled balances, and ends with a run team that owns upgrades. Effort depends on how many products and integrations exist and on what each vendor's export formats allow, which the reader must confirm early.
Inventory products, rules and integrations
Your product owners, risk team and engineers list every Vault product in use, including its parameters, fee and interest logic, scheduled events, posting rules and account types. They also list every system that calls Vault or consumes its ledger, such as payments, card, reporting, general ledger and regulatory feeds. The output is a signed-off register with one row per product and per integration, marking which items are standard lending or deposit behavior and which are custom logic written as Vault smart contracts. This register sets the scope for every later step.
Map Vault products to Fineract products
Architects and product specialists take each entry in the register and find its closest Fineract equivalent: loan or savings product, charge, accrual rule, repayment schedule and chart of accounts mapping. Where Vault logic is custom code, the team decides whether Fineract's configurable products and business rules can express it, whether a small extension is needed, or whether the product should be retired. Each gap is written down with the decision and its owner. The check is a mapping document that finance and operations sign off, showing every Vault balance type linked to a Fineract ledger account.
Define the data model and migration scope
Data engineers and the core banking team define how client records, KYC documents, identifiers, loan and savings accounts, schedules and transaction history will be represented in Fineract's data model. They confirm what Vault can export, in which formats and at what granularity, and whether historical postings are available or only closing balances. Records that cannot be exported cleanly are flagged early. The output is a data specification and a field-level mapping, along with a list of what must be re-captured or re-verified, such as KYC evidence that your compliance team requires.
Build and reconcile the migration
Engineers write the extraction, transformation and load scripts, then load them into a non-production Fineract tenant. Finance reconciles migrated balances, accruals and ledger totals against Vault's own figures for a set of sample and full-population cut-off dates. Each difference is logged and resolved before the next load. The check is a reconciliation report showing zero unexplained variances per product and per account type, with the reconciliation approved by the finance function and the relevant controls owners.
Rebuild or re-point integrations
Integration engineers rework each dependency on the register. Fineract exposes REST APIs and no user interface of its own, so channels and staff screens must be provided by your team or a front end you choose. Event consumers are configured against Fineract's supported messaging options, either ActiveMQ or Apache Kafka. Each interface is tested against sandbox data for success, failure and retry paths. The check is a passing test record for every integration, including the reporting and general ledger feeds.
Run a parallel period and cut over
Operations runs Vault and Fineract side by side for an agreed window, with new transactions recorded in both and compared daily. Discrepancies go to the defect log and are fixed or accepted with a documented reason. The cutover runbook sets the freeze, final extract, load, reconciliation, rollback point and the switch of channels to the new core. Management approves the go-live decision against written criteria. The output is a signed cutover record and a rollback plan that was tested, not only written.
Set up the run team and upgrade cadence
After cutover, your platform team takes ownership of Fineract's deployment, which the project documents on Kubernetes with a PostgreSQL database as the recommended choice. Roles are assigned for application support, database administration, security patching, release management and product configuration. The team agrees an upgrade cadence aligned with Fineract's quarterly releases and its end-of-life archiving policy, and tests each upgrade in a non-production tenant first. The check is a documented run model, on-call rota and upgrade calendar that have been exercised at least once.
Questions buyers ask before choosing between Vault Core and Fineract
Does running Apache Fineract cost less than licensing Vault Core?
Fineract removes the vendor licence, but it does not remove cost. The software is Apache 2.0 licensed, so the recurring cost moves to people, infrastructure and support. Your budget will include a production platform team, database and cloud or data center capacity, integration and testing, product configuration, security hardening, backup, and upgrades. The Fineract README warns that a production deployment can be complex, costly and time-consuming, and that organizations may pay a vendor for deployment and maintenance. The cost sibling page on this site sets out these components side by side. Ask any vendor for a written breakdown of one-time and recurring items before comparing totals, and ask Thought Machine for the licence and run model it would quote for your volume and product range.
How long does a migration to Fineract take?
The duration depends on the number of products, the volume of existing accounts, the number of downstream integrations and how much of the current core's behavior must be reproduced. Public sources for this topic do not give a timeline, so treat any duration as something to confirm in writing. Plan separately for the build of the target environment, product configuration and business rule testing, data migration with reconciliation, integration rebuilds, parallel running and cutover. Each stage has its own exit criteria. Ask any implementation partner to show these stages in a fixed-scope plan with agreed deliverables before work starts.
Can an in-house team run Fineract without outside help?
A capable in-house team can run Fineract, but it needs the full set of roles rather than developers alone. Fineract is headless and exposes REST APIs, so the team needs people who own the front end, the integrations, the database, the cloud or Kubernetes platform, security, and the product and accounting configuration. Many banks and lenders choose a mixed model, with internal staff owning business decisions and an outside team supplying deployment, hardening, backup, upgrades and support under a retainer. Decide which of these roles you can staff permanently before committing to a self-run model.
Which skills does a self-hosted Fineract program need?
The work spans platform engineering, database administration, application integration and banking domain knowledge. Engineers should be comfortable with Docker images and Kubernetes, since the project documents Kubernetes deployment. Database specialists must run PostgreSQL, which the README recommends as the database. Integration engineers handle REST APIs and the event layer, which supports ActiveMQ and Apache Kafka. Finance and operations staff must configure products, interest, fees and accounting rules. Security staff need to cover access control, multi-tenant configuration and evidence for audits. The official images are not production-ready, so the team must build and test a hardened production image.
Does Fineract suit tier-one banks or mainly lenders and microfinance?
Fineract fits lenders, microfinance institutions and smaller or specialized operations best, because its design centers on loan and savings portfolios, client and KYC data, accounting and configurable products. Tier-one banks usually run wide product sets, complex payments and many regulated channels, which raises the requirements for scale, operational tooling and vendor accountability. Fineract can be made to work in larger settings, but that depends on your architecture, staffing and testing capacity. Ask any candidate platform for reference deployments at your scale and for its published roadmap and support terms, and confirm each claim in a proof of concept with your own workloads.
How does Fineract handle multiple tenants and database scaling?
Fineract is multi-tenant. API requests carry a Fineract-Platform-TenantId header, and tenant connections are configured from a tenants database. The documentation describes read, write and batch instance types, set by environment variables. It recommends one write instance, one batch instance and multiple read instances on database read replicas for high load. Liquibase migrations run only on write instances, and on Kubernetes they can run separately with the liquibase-only Spring profile. Your platform team should test these settings under realistic load, and confirm how tenant isolation and backups are designed for your regulatory obligations.
What does the Apache 2.0 licence cover, and what does it leave to you?
The Apache License 2.0 lets you use, modify and run Fineract without a licence fee, and it carries a patent grant from contributors. It does not cover the work around the software. You still own the security hardening, the upgrade program, the testing and the evidence your regulator or auditor requests. The project releases quarterly and archives end-of-life releases, so plan for regular upgrades. Note that MariaDB and MySQL connectors are excluded from the distribution for licensing reasons, so confirm your database driver choices with your legal team before you build. Have counsel review the licence terms against your own use and any third-party components you add.
How DeployOpen helps evaluate, implement or migrate a Fineract core
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Fineract core, we start with a written scope that tests whether Fineract fits the institution's products, controls and hosting model before any build begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map your lending, savings and accounting products to Fineract configuration and flag any that need custom development.
- We confirm your target cloud account, data center or air-gapped network, and the database and event broker you intend to use.
- We agree which tenants, instance roles and environments are in scope, including read, write and batch instances.
How we build
- We deploy Fineract in your own Kubernetes or virtual machine estate, using PostgreSQL as the recommended database.
- We configure tenants, products, business rules and integrations with your general ledger, KYC tooling and reporting.
- We harden the deployment and test it, treating the project's images as a starting point because they are not production-ready.
- We prepare the Liquibase migration path, running schema changes on the write instance as a controlled release step.
How we hand over
- We deliver architecture, configuration and runbook documentation written for your platform and operations teams.
- We document backup, restore and upgrade procedures tied to Fineract's quarterly release cadence and end-of-life archiving.
- We prepare control and evidence packs for your compliance assessors, while independent auditors issue any formal opinion.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover quarterly Fineract upgrades, security testing of the deployment and changes to products or integrations.
- We ask you to confirm your internal run team and vendor arrangements, since the project notes production deployments can be complex and costly.
