Open-source alternatives to Thought Machine Vault: when a self-run ledger fits
If your bank is weighing a renewal, a cost review, a data residency rule or concern about lock-in with Thought Machine Vault, Apache Fineract is the core ledger option to evaluate. Hyperswitch is relevant only for the payment flows that sit around that ledger, not as a replacement for the ledger itself. The decision you face is whether your team can run a ledger as a platform it owns, with its own release cycle, hosting and operations, rather than consuming a ledger as a managed service. The reason teams look at alternatives usually comes down to where and how the ledger runs. Thought Machine has announced that Vault is available on Google Cloud, AWS, Microsoft Azure and IBM Cloud, on-premise, in hybrid cloud with Red Hat OpenShift, and as SaaS, with that availability announced on June 29, 2020. Those options matter if your constraint is a specific jurisdiction or an existing data center. If your concern is that the vendor controls the deployment model, the question to ask is whether that choice is contractual or technical, and what it would take to move. Confirm with Thought Machine which deployment models are offered to your institution today, since a 2020 announcement does not establish current terms.
Which open-source core options a bank should evaluate
Vault is a ledger and product engine configured through smart contracts, so no open-source platform replaces it one for one. The cards below cover the options a bank should test: a self-hosted core ledger, a payment orchestration layer that sits beside it, and the gaps you must close yourself. Each one answers a different part of the Vault decision.
Apache Fineract as the ledger
Apache Fineract is licensed under Apache 2.0 and its current release listed on its site is 1.15.0. It is designed as a cloud-ready, headless core with open APIs, so your channels and integrations talk to it directly. The trade-off is that its product model is built around lending and savings, not Vault-style product engines, so you must map your products to its configuration and confirm the fit early. Check that your product types exist in the configuration before you commit.
Docker and Kubernetes packaging
Fineract publishes Docker images and documents a Kubernetes deployment, which fits a platform team that already runs containers. The project warns that its images are not production-ready, so your team must build hardened, scanned images, pin versions and own the Helm or manifest layer. Ask who maintains your base images and how you will patch them between Fineract releases.
Event streaming with ActiveMQ or Kafka
Fineract supports ActiveMQ and Apache Kafka for events, so downstream fraud, reporting and ledger consumers can receive postings as they happen. Choosing between the two shapes your operations: Kafka suits high-volume streams with retention, while ActiveMQ may be simpler for a smaller estate. Confirm event ordering, replay and delivery guarantees with your engineers before you design consumers.
Multi-tenant design and data isolation
Fineract's quick start creates separate tenant databases, which reflects a multi-tenant design. This matters if you run several legal entities, brands or regions on one platform, because tenant boundaries affect backup, restore and access control. Test how a single tenant can be restored without touching others, and document the database topology for your auditors.
Hyperswitch beside the ledger
Hyperswitch is an Apache 2.0 payment orchestration layer written in Rust that connects to over 100 payment processors and includes a card vault service. It handles routing and payment method storage rather than the ledger, so it sits beside a core such as Fineract or Vault. The main trade-off is that a self-hosted card vault brings PCI DSS scope into your environment, so confirm that scope with your QSA before deployment.
No drop-in for smart contracts
No open-source option matches Vault's smart-contract-based product engine, where product behavior is coded and versioned as contracts. Fineract and Hyperswitch both expect you to configure or extend products through their own models, which means some Vault product logic will need redesign or custom code. Inventory your product logic early, then decide which parts you rebuild and which you accept as configuration.
How Thought Machine Vault capabilities map to open-source coverage
This table compares the main Thought Machine Vault capabilities with Apache Fineract, Hyperswitch and a custom build. Read the gap rows first, since they decide whether a self-hosted ledger can carry your product set without significant engineering. Confirm each Fineract capability against the current documentation and your own test environment before you rely on it.
| Capability | Apache Fineract | Hyperswitch or custom build |
|---|---|---|
| Ledger and account balances | Core ledger with savings and loan accounts; confirm posting, journal and balance behavior for your product types | Hyperswitch does not hold a customer ledger; a custom build would need double-entry posting and reconciliation |
| Product configuration | Configured through product definitions and settings rather than code; confirm how far it reaches for your rules | Not covered by Hyperswitch; custom build means writing and governing your own product rule engine |
| Configurable product logic (smart contracts) | Gap: Vault expresses product behavior as smart contracts, which Fineract does not offer in the same form; expect custom Java extensions or process changes | Gap: no equivalent; a custom build would need its own rule language, testing harness and change control |
| Lifecycle events (accrual, fees, interest, closure) | Batch and scheduled jobs handle many lifecycle tasks; confirm timing and end-of-day behavior against your products | Custom build only; must be designed, tested and audited from scratch |
| APIs | REST APIs with a headless design; confirm endpoint coverage for your integrations | Hyperswitch exposes payment APIs; custom build APIs are your responsibility |
| Event streaming | Supports ActiveMQ and Apache Kafka for events; confirm the event set you need | Hyperswitch event capabilities should be confirmed; custom build can use any broker you operate |
| Deployment flexibility | Docker images and Kubernetes deployment documented; images are not production-ready, so plan your own hardening and build | Hyperswitch supports Docker, Kubernetes with Helm charts, and AWS, GCP and Azure; on-premise fit depends on your environment |
| Payment vaulting | Not a card vault; payment instruments need a separate component | Hyperswitch includes a card vault service; confirm PCI scope and key management in your environment |
| Multi-tenancy and data isolation | Uses separate tenant databases in its quick start design; confirm the model fits your entity structure | Depends on the custom design; isolation must be built and evidenced |
Product configuration versus smart contracts: what changes for your product team
Fineract and Vault put product logic in different places, and that difference decides who on your team can change a product and how changes get tested. In Apache Fineract, a loan or savings product is defined through the platform's configuration: product parameters, fee and interest settings, and accounting mappings are set in the product definitions, typically by operations or product staff through the administrative interface and API, with no change to the application code. Thought Machine describes Vault differently. Product behavior is modeled as smart contracts, its own term for versioned product logic that runs on the ledger. Changing that logic is a software change, so your product team needs developers or Thought Machine's own engineers to write, review and deploy it. Confirm with Thought Machine exactly which parts of a product a non-engineer can edit, and which require a contract change and release.
Testing and versioning follow from that split. A configuration change in Fineract can be exercised in a non-production tenant and promoted by re-entering or exporting the settings, so your controls should record who changed which product parameter, when, and what was tested. A smart contract change needs the normal software lifecycle: source control, peer review, automated tests against sample account lifecycles, and a controlled rollout with a rollback plan. Ask both vendors how existing accounts are handled when a product definition changes, because some changes apply only to new accounts and others affect balances already on the ledger. Plan your regression suite around interest accrual, fees, delinquency and end-of-day postings, since those are where product changes usually surface errors.
If your product logic is custom, the build or hire decision is the real cost driver. With Fineract, you need people who understand its product model, its accounting setup and its Java-based customization points, and you own every extension you write and must keep it working through upgrades. With Vault, you need engineers who can write and test smart contracts in Thought Machine's approach, and you depend on the vendor's tooling and roadmap for the language and runtime. Either way, budget for product analysts who can translate lending or deposit rules into specifications, a QA function with ledger test data, and on-call engineers for batch processing. Ask for a written inventory of your products, the custom logic each one needs, and which team will own each item after go-live.
Which option fits by bank situation
When data residency or sovereignty is the main driver, Apache Fineract is the option that can run entirely in your own data centers or in a sovereign cloud tenancy you control. Fineract is Apache 2.0 licensed, so there is no license fee that depends on where it runs, and its Docker images and Kubernetes documentation give you the deployment building blocks. Thought Machine Vault also offers on-premise and hybrid options, so the question becomes which model your regulator and your data protection team will accept.
- Deployment boundary: Confirm that every component, including the database, message broker and backups, can run inside the boundary your regulator defines.
- Vendor access: Ask what remote access, support tooling and telemetry each vendor requires, and whether any of it leaves the perimeter.
- Images: Fineract's documentation warns its images are not production-ready, so plan to build, scan and harden your own images before use.
- Database choice: Fineract's distribution excludes MariaDB and MySQL connectors for licensing reasons, so confirm your database driver and license position early.
- Hosting model: Compare on-premise, sovereign cloud and hybrid options against your residency rules.
Before you choose, confirm with your regulator and data protection officer exactly which data must stay in-region and which operations need to be audited from outside it.
A self-hosted core is only as sound as the team that runs it. If you have engineers who already operate Kubernetes, message brokers and relational databases in production, Fineract's Kubernetes deployment path and its support for ActiveMQ and Apache Kafka for events fit that skill set. Thought Machine's model shifts much of the operating burden to the vendor, which may suit a team without that depth. The right answer depends on who will be on call at 2 a.m.
- Platform skills: You need staff who can manage Kubernetes upgrades, storage, secrets, network policy and observability for a stateful financial system.
- Event backbone: Choose between ActiveMQ and Apache Kafka, and confirm who owns its capacity planning and recovery.
- Release cadence: Track the current Fineract release, which the project lists as 1.15.0, and plan a tested upgrade path rather than running the version you first installed.
- Runbooks: Write and rehearse incident, backup and restore procedures before go-live.
- Support contract: Decide whether you want a retainer for upgrades and out-of-hours cover.
Confirm with your platform leads whether your current on-call rota and tooling can carry a ledger service with strict availability needs.
Thought Machine Vault is built around configurable product definitions, which many banks use to launch and vary deposit and lending products through its model. Fineract takes a different approach: it is a headless system with open APIs, so product logic is configured in the platform and extended through integration code you own. Neither model is a substitute for a product design function, so the question is how much new product behavior you expect to add over the next several years and who will write it.
- Configuration coverage: Map your current and planned products against what Fineract configures out of the box and what needs custom development.
- Extension ownership: Decide who maintains custom code through each Fineract upgrade, since that work recurs.
- API integration: Confirm your channel, risk and general ledger integrations can use Fineract's open APIs without bespoke middleware.
- Testing: Build regression suites for each product so changes are verified before release.
- Vendor roadmap: Ask Thought Machine about its product roadmap and how it prices new product work.
Confirm with your product team which features are must-have on day one, because that list determines how much custom engineering your business case will carry.
Fineract's origins lie in the Mifos X platform, which started in 2012 and was incubated at the Apache Software Foundation from 2016, and the project is widely associated with microfinance and lending use. That history makes it a plausible candidate for a small lender or microfinance institution, but the Fineract documentation describes the platform's capabilities, not a certified fit for any segment. Verify each product type against the documentation and a proof of concept before assuming it works for your portfolio.
- Segment fit: Test your loan and savings products against Fineract's documented features and list any gaps.
- Scale and budget: Compare the internal staffing needed to run a self-hosted ledger with the vendor-managed alternative at your size.
- Regulatory reporting: Confirm the reports your supervisor requires can be produced from the platform's data.
- Multi-tenancy: Fineract's quick start creates separate tenant databases, which matters if you plan to host several entities together.
- Migration: Plan data migration and parallel running before committing to a go-live date.
Confirm with your supervisor and a Fineract specialist whether your specific product set and reporting obligations are covered before you commit.
What you give up when you leave Thought Machine Vault
Leaving a vendor-managed core means taking over work the vendor did for you, from upgrades and hosting to support and product tooling. Each card below names one loss and a practical workaround, so you can decide which gaps your own platform engineering team can carry and which need an outside retainer.
Vendor-managed upgrades and hosting
Thought Machine runs Vault on the infrastructure options it lists, and that service covers much of the upgrade and patch cycle. With Fineract in your own cloud account or data center, your team owns every release, dependency update, database migration and rollback. Ask who will test each Fineract release against your product configuration before it reaches production, and how long a rollback takes in your environment. A hardening and upgrade retainer or an internal platform team with a written runbook can carry this work.
Smart-contract product model and tooling
Vault's product model is built around smart contracts and the tooling that authors, tests and versions them. Fineract models products through its own configuration of loan, savings and accounting features, so the authoring workflow, test harness and change review will differ. Your product team should map each existing contract to a Fineract product definition and list any behavior that has no direct equivalent. A custom product layer that holds bespoke logic outside the core can close the gap, but it adds code your team must maintain.
Vendor support depth
A commercial vendor provides a named support path, escalation procedures and contractual response commitments. The Apache Fineract project is community-supported, so incident response depends on your own staff, community forums and any third party you contract. Before you leave, ask Thought Machine for its exit terms and ask any Fineract support provider for written response expectations. An internal on-call rota with documented runbooks, backed by a support retainer, is the usual workaround.
Pre-built integrations
Vault customers often rely on vendor-maintained connectors to payment rails, data platforms and channel systems. Fineract exposes open APIs and supports ActiveMQ and Apache Kafka for events, but each connector you use today may need to be rebuilt or rewritten against those interfaces. Inventory every integration, classify it as rebuild, reuse or retire, and confirm which event contracts your downstream systems depend on. Integration work is usually scoped as a fixed project with written deliverables.
Production-ready images
The Fineract project warns that its Docker images are not production-ready, so you cannot deploy the published images as they are. Your team will need to build hardened production images, set a base image policy, scan dependencies, and document the build pipeline. Plan for the Kubernetes deployment, secrets handling and image signing as part of this work, and confirm the image build and release process with your security and compliance leads before the first production change.
How the multi-year cost of self-hosting compares
This table sets the cost components of a commercial Thought Machine Vault deployment against a self-hosted Apache Fineract platform, marking each as one-time or recurring. No vendor prices were supplied, so the cells name who is paid and what to request in writing. Read it as a checklist for building comparable quotes, since the largest differences usually sit in recurring platform operations and internal skills.
| Cost component | Commercial Vault (who is paid) | Self-hosted Fineract (who is paid) |
|---|---|---|
| Software licence or managed service fees | Recurring fee to Thought Machine or its cloud or SaaS delivery partner; request the pricing model and what it covers from the vendor | None for the Apache 2.0 software; any fees apply to a third-party support or hosting provider you choose |
| Infrastructure for Kubernetes and databases | Usually included in managed or SaaS delivery; confirm which parts you still pay for in your own cloud account | Recurring cloud or data center cost for clusters, databases, messaging (ActiveMQ or Kafka) and environments |
| Implementation and configuration | One-time: product configuration and integration, often through the vendor or a partner | One-time: Fineract deployment, product configuration and integration, usually through an implementation partner such as DeployOpen |
| Data migration and parallel running | One-time: mapping accounts, balances and history; ask whether migration tooling is included | One-time: same mapping work plus tenant setup and reconciliation against the existing ledger |
| Testing and security hardening | One-time and periodic: functional, security and penetration testing; confirm who runs it and what evidence you receive | One-time and periodic: the same testing plus hardening of images, which the project warns are not production-ready |
| Upgrades and ongoing support | Recurring: vendor release cadence and support tier; confirm upgrade effort and who tests it | Recurring: you or a retained partner track releases (current release 1.15.0), test and apply upgrades |
| Internal skills and staffing | Recurring: smaller platform team for configuration and vendor management | Recurring: Java, Kubernetes, database and security skills, often the largest line item to validate |
How a migration off Thought Machine Vault runs
The sequence moves product configuration, customer balances and posting history from Vault into a self-hosted ledger in controlled stages, so each step ends with evidence that the new platform matches the old one. Each stage has an agreed exit check before the next one starts. Durations depend on scope and must be agreed in writing before work begins.
Inventory products, accounts and integrations
The bank lists every Vault product, account type, parameter set, scheduled event and downstream consumer, including payment rails, general ledger feeds, regulatory reporting and customer channels. DeployOpen and the bank's product owners map each item to a Fineract equivalent or record it as a gap that needs custom work or a process change. The step closes when the bank signs off a written inventory with a gap register, because gaps found later usually cost more to resolve.
Export and map balances and postings
The team confirms with Thought Machine which export formats, historical depth and posting detail the bank's contract and deployment allow, since export options differ by how Vault is hosted. Balances, account holder data, postings and product parameters are extracted and mapped to Fineract's data model, including currency precision, accrual timing and status codes. The step closes with a reconciliation report showing that exported balances match Vault's totals on the extraction date.
Run a pilot with a limited product set
The bank selects one or two low-risk products, such as a simple savings or current account product, and loads them into a Fineract instance in its own Kubernetes environment. Testers run representative transactions, interest and fee events, end-of-day processing and statement generation, and compare results with Vault for the same inputs. The pilot is complete when the differences are explained and fixed or accepted in writing. Fineract's own documentation warns that its Docker images are not production-ready, so the bank's team should treat the pilot as a hardening exercise as well as a functional test.
Parallel run with daily reconciliation
Both platforms process live or replayed activity for an agreed window while the bank reconciles balances, postings and general ledger outputs every business day. Discrepancies are logged with a root cause, an owner and a fix date, and recurring differences trigger a change to mapping or configuration. The step ends when the bank's finance, operations and risk teams accept the reconciliation results against criteria set before the run began.
Cut over with written rollback criteria
Before cutover, the steering group signs rollback criteria covering balance variance, failed end-of-day runs, payment rail errors and customer-facing incidents. The bank freezes Vault changes, performs the final delta extraction, loads it into Fineract and switches channels and integrations in a defined order. The step closes when the post-cutover checks pass and the rollback window expires without triggering the criteria, with the rollback path kept intact until then.
Decommission the Vault platform
Once the retention and audit obligations are met, the bank archives Vault data it must keep, confirms export and retention terms with the vendor in writing, and removes integrations, credentials and infrastructure. The team updates the configuration management database, access reviews and operational runbooks so that Vault no longer appears in monitoring or backup scope. The step is complete when the bank holds signed records of archival, access removal and final vendor confirmation.
Questions banks ask before self-hosting a core ledger
What does it cost to self-host a core ledger like Apache Fineract?
The cost is mostly people and infrastructure, and it splits into one-time and recurring parts. One-time work covers architecture, configuration of your products, integration with payments and general ledger, data migration, security hardening and testing. Recurring costs cover cloud or data center capacity, database and messaging licensing or support (if you buy it), your platform team, upgrades and on-call support. Apache Fineract itself is Apache 2.0 licensed, so there is no license fee to the project. Ask any implementation partner for a quote built from a written scope, listing each deliverable, who performs it, and which costs are one-time versus monthly.
How long does a core ledger migration take and what sets the timeline?
The timeline depends on how many products you configure, how much history you migrate, how many downstream systems depend on the ledger, and how much parallel running your risk team requires. Migration of balances and transaction history usually takes the longest, because reconciliation has to be repeated until the numbers match. Regulatory reviews, change freezes and the availability of your own staff also add time. Ask for a written plan with phases, exit criteria for each phase and named dependencies. Treat any duration without a stated scope as a sales estimate to challenge.
Can our internal team run a self-hosted core ledger on its own?
Some banks can, but it depends on whether you already run stateful, regulated workloads on Kubernetes and have database administrators with backup and recovery experience. A workable internal team usually covers application configuration, Kubernetes platform operations, database operations, security patching, monitoring and an on-call rota. Fineract's documentation warns that its Docker images are not production-ready, so you will need to build, scan and validate your own production images. Many teams start with an external partner for the first deployment and then move operations in-house, or retain a support contract for upgrades.
What Kubernetes and database skills does a Fineract deployment need?
You need people who can operate Kubernetes in production, including namespaces, secrets, persistent volumes, network policies, ingress, rolling upgrades and backup of stateful services. On the database side, Fineract uses separate tenant databases, so your team should understand schema creation per tenant, connection pooling, replication, point-in-time recovery and restore testing. Fineract's quick start excludes MariaDB and MySQL connectors from the distribution for licensing reasons, so confirm which driver and database engine your team will supply before you design the image. Messaging with ActiveMQ or Apache Kafka adds another operational component to monitor.
How do we test product changes before they reach production?
Test product changes in a non-production environment that mirrors production configuration, data shape and integrations, then promote them through a controlled change process. Build automated regression suites for interest, fees, posting rules, end-of-day runs and reconciliation, and keep a set of reference transactions with expected outcomes. Store product configuration as version-controlled artifacts so every change has an author, a reviewer and a rollback path. Ask any partner to show how they separate configuration changes from code changes, and how they evidence test results for your model risk and audit teams.
How do Fineract's licensing and release cadence affect our planning?
Fineract is Apache 2.0 licensed, which allows commercial use and modification with attribution and notice obligations, and the project currently lists 1.15.0 as its current release. Because you run the software yourself, every new release becomes your upgrade project, including regression testing, data migration checks and security review. Plan a recurring budget line for upgrades and decide your policy for how far behind the current release you will run. Confirm the project's release and support policy directly on the Fineract website and documentation before you commit to a version.
What compliance evidence should we prepare before a self-hosted ledger goes live?
Prepare documentation that shows how the system is configured, how access is controlled, how changes are approved, how backups are tested and how incidents are handled. Your compliance and audit teams will ask for evidence of segregation of duties, logging, encryption in transit and at rest, and disaster recovery testing. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and your regulator decide whether your controls are adequate, so agree the evidence list with them early.
How DeployOpen scopes, migrates and supports a self-hosted ledger
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a ledger replacement, that means a fixed-scope engagement that covers the Fineract deployment, the product configuration work, and the evidence your teams need before any balances move.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which Thought Machine Vault product behaviors map to Fineract configuration and which need custom development.
- Scope also names the cloud or on-premise target, Kubernetes platform, event broker choice and integration partners in your environment.
How we build
- We deploy Fineract in your infrastructure, replacing the Docker image defaults with hardened, production-grade builds your team approves.
- Product configuration is tested against your loan, savings and account rules using agreed test cases before any integration work.
- Security testing of the applications and APIs runs alongside the build, so findings are fixed before cutover rather than after.
How we hand over
- Deliverables include architecture, configuration records, runbooks for Kubernetes operations, and the control evidence your compliance team requests.
- Your operations staff receive training on backups, upgrades and incident handling for the ledger and its messaging layer.
- Handover ends with a written acceptance checklist, so ownership of each component is clear before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades to new Fineract releases are planned, tested in a non-production environment and documented before rollout.
- Compliance preparation supports your assessment with systems and evidence, while independent auditors and certification bodies issue any formal opinion.
