Does a self-hosted Mambu alternative for data residency need Fineract?
When a supervisor or internal policy fixes the country or infrastructure where the banking ledger must sit, the constraint decides the option, not the feature list. Mambu's cloud regions may meet the requirement if the contract and the region match, so the first step is to ask Mambu in writing which regions and hosting providers would hold your production ledger, backups and replicas, and whether the contract names those locations. Where that answer does not fit, self-hosted Apache Fineract on premises or in a local cloud is the fit. Mambu announced general availability on Amazon Web Services, Google Cloud and Microsoft Azure on October 24, 2022, but cloud availability alone does not prove that your data stays in the jurisdiction your regulator expects. Confirm the exact region and any support access from outside it.
Fineract is a headless application with REST APIs and no user interface of its own, and its README warns that a production deployment can be complex, costly and time-consuming. Choosing it for residency means your team, or a partner, owns the database (PostgreSQL is the recommended option), the multi-tenant configuration, backups, patching, monitoring and the front end. Before committing, confirm which regulated functions must stay in-country, which vendors and sub-processors touch the data, and whether your regulator requires an exit plan for the hosting arrangement. Fineract's official documentation is the natural starting point for estimating the operating load.
Plan the residency decision with a written checklist: where the ledger, backups, logs and support access sit, who can reach them from abroad, and how you would prove the location to an examiner. Treat a self-hosted core as a commitment to run a production banking system, not as a one-time installation. Ask any implementation partner for a fixed scope covering hosting design, hardening, backup and restore testing and documented evidence, and ask Mambu for the same location commitments in writing. The choice should follow from what the regulator will accept, with the feature comparison used only to confirm that the chosen platform covers your products.
What a data residency requirement obliges the institution to show
A residency requirement is rarely satisfied by a single setting. Supervisors and assessors ask where the ledger and card data sit, who can reach them, and how the institution would move them if the provider failed. The cards below cover the obligations most likely to apply to a Mambu or self-hosted Fineract decision, and what to confirm with your provider or assessor before committing.
Service location in the contract
Under DORA Article 30(2), every ICT services contract must state where the services are provided and where data is processed, and the provider must give advance notice of changes to those locations. For a SaaS core, check whether the contract names specific cloud regions and whether a region change triggers notice and a right to object. For a self-hosted Fineract core, the same clause still applies to any hosting or support provider, so the contract with DeployOpen or a cloud host must name the sites and the notice period.
Register of information
Article 28(3) of DORA requires the institution to keep a register covering all contractual arrangements for ICT services. Each entry should record the provider, the services, the functions they support and the locations where data is held. A Mambu contract and a self-hosted Fineract stack with a hosting provider each need an entry, and the locations recorded must match the contract. Confirm the register format with your supervisor before the first submission.
Card data scope under PCI DSS
PCI DSS applies to any entity that stores, processes or transmits cardholder data, or that could affect the security of the cardholder data environment. A core ledger that holds only account balances may stay outside that scope, but a payments component that stores card numbers pulls it in. Before choosing where card vaulting runs, map which systems touch card data and which assessment type applies, since a Report on Compliance or a Self-Assessment Questionnaire each require an Attestation of Compliance from the right party.
Personal data and GDPR context
GDPR, Regulation (EU) 2016/679, governs personal data about customers and staff regardless of where the ledger runs, and it restricts transfers of personal data outside the EU or EEA. Residency decisions therefore need a record of processing activities that names each system holding client data, the country of storage and any support access from outside the region. Ask any SaaS vendor for its transfer mechanisms and sub-processor list, and map the same information for a self-hosted deployment.
Operator obligations under NIS2
NIS2, Directive (EU) 2022/2555, sets security and incident reporting duties for essential and important entities, and these duties follow the operator of the systems whether it is in-house or a provider. Where the core is self-hosted, the institution must be able to show the security measures, the incident handling process and the supply chain controls itself. Where the core is SaaS, it must show that the provider's controls meet the same bar. Confirm with your national competent authority whether your sector and size fall within scope.
Where Mambu's cloud regions meet residency and where they do not
Mambu describes itself as a cloud-native SaaS core banking platform, and it announced general availability on Amazon Web Services, Google Cloud and Microsoft Azure on October 24, 2022. For an institution whose residency rule is satisfied by hosting in a named cloud region under a signed contract, a SaaS deployment can answer the requirement without moving the ledger off the vendor's platform. The question then becomes whether the specific region, backup location and support access path match what the rule describes.
- Region availability: Confirm in writing which regions your tenant can be provisioned in, and whether that list includes the country you need.
- Data location terms: Ask where production data, backups, logs and replicas are stored, and whether that location is fixed in the contract.
- Subprocessors: Obtain the current list of subprocessors and the notice period for changes, since a new subprocessor in another jurisdiction can change your position.
- Support access: Establish from which countries Mambu staff can view or export data for support, and under what approval.
- Exit and data return: Confirm the format and timing of data return if the contract ends.
If Mambu's written terms cover all five points, a regional SaaS deployment may be sufficient. Keep those terms with your register of ICT arrangements so the position can be evidenced later.
Some rules go further than a region and require the ledger to sit in a named country, in a data center the institution controls, or in a local cloud the institution contracts directly. In that situation a vendor-operated SaaS core usually does not meet the requirement on its own, because the institution cannot show direct control over where the data physically resides and who can reach it. Self-hosting Apache Fineract, which is Apache 2.0 licensed open source software, lets the institution choose the facility, the cloud account and the operating staff.
- Chosen facility: Fineract runs in your own data center or in a local cloud account you contract directly, so location is set by your architecture.
- Database placement: The README recommends PostgreSQL, so the database, its replicas and its backups can be placed in the same jurisdiction as the application.
- Operating responsibility: You take on hosting, patching, backups and upgrades, which Fineract's README notes can be complex, costly and time-consuming to run in production.
- Vendor support: Organizations often buy deployment and maintenance from a provider, so the residency of that provider's access to your environment becomes part of the assessment.
- Documentation gap: The project does not provide a comprehensive production deployment guide, so the design and runbooks must be written by your team or a partner.
Before committing, confirm which regulator and which clause defines the location rule, and whether it covers backups and support access as well as primary storage.
Air-gapped environments have no route to the public internet, which affects how software, container images and updates reach the platform. A SaaS core cannot run inside such a network because its service is delivered from the vendor's cloud. Any self-hosted Fineract deployment would need to be built from artifacts brought in through a controlled transfer process, and every upgrade would be a planned import rather than a routine pull.
- Artifact transfer: Fineract publishes Docker images and releases, and each image, dependency and database driver must be validated and imported through your own approved process.
- Release cadence: Official releases are created quarterly, so your plan should set how often you import new versions and how you test them offline.
- Dependencies: The official Docker image ships only the PostgreSQL JDBC driver, and messaging components such as ActiveMQ or Apache Kafka must also be mirrored if you use them.
- Offline support: Vendor help that depends on remote access will need a secured, logged channel that your security team approves.
- Monitoring and backup: Logs, backups and alerts must stay inside the enclave, which requires local tooling.
Ask whether any Mambu capability you rely on can operate without a connection to the vendor's cloud, because this is not something the public material confirms and should be answered in writing.
Which open-source options fit a data residency constraint
This table compares the open-source platforms that can keep a banking ledger or card vault in a location you choose, and shows where each one fits. Read the first column as the requirement, then check whether the option can run in your region and whether you have the team to operate it. The main takeaway is that Mambu's cloud regions answer some residency rules, while self-hosted Fineract is the option when you need the ledger on infrastructure you control.
| Option | How it keeps the ledger in your chosen location | Trade-offs to weigh |
|---|---|---|
| Apache Fineract | Runs as a self-hosted, headless REST core on your own servers, in an on-premises data center or a cloud region in your country. Client, loan, savings and accounting data stay in the PostgreSQL database you operate. | Apache 2.0 licensed with no licence fee, but the README warns that production deployment is complex, costly and time-consuming. Docker images are not production-ready, so you build and harden your own deployment. |
| Fineract user interface | Fineract provides no UI of its own. Staff access the ledger through REST APIs, so any screens must be built or supplied separately, and they can be hosted in the same residency zone. | Expect to build or source the front end, its access controls and audit logging. Confirm how your regulator expects staff access to the ledger to be logged. |
| Mifos X | Packages a web application and mobile apps on Apache Fineract, so you can run the complete stack inside the same jurisdiction and network boundary. | Mifos X is an MPL-2.0 distribution, and its web app releases can trail Fineract. Confirm the version pairing and who maintains the packaged components before you commit. |
| Hyperswitch (payment routing and vaulting) | Self-hosted with Docker, Kubernetes with Helm charts, or on AWS, GCP and Azure, so routing logic and the card vault can run in your chosen environment. Use it only if card data is in scope. | Apache 2.0 with a card vault service and connections to over 100 processors. Confirm the vault's PCI DSS scope and whether your chosen cloud region meets your card data rules before go-live. |
| Mambu cloud regions | Mambu runs on Amazon Web Services, Google Cloud and Microsoft Azure, and its approach was announced in October 2022. Check which regions are available to you and whether the vendor will commit to them in writing. | The ledger is run by the vendor in a SaaS model, so residency depends on contract terms, sub-processors and support access. Ask for the data location clause and any remote access from other countries. |
How to deploy Fineract inside a residency boundary
This sequence turns a residency requirement into a running, self-hosted Fineract core whose database, tenants, events and backups all stay inside the boundary you define. Each step ends with a check you can show your compliance and architecture reviewers.
Confirm the residency zone and contract terms
Your legal, compliance and procurement leads define which countries, facilities and administrators may hold the ledger, customer records and backups, and which subprocessors may touch them. Write these as requirements for the infrastructure team, including where logs, support access and disaster recovery copies may sit. Confirm with counsel whether any regulator-specific rule applies to the chosen location. The step is done when the boundary is written down, signed off, and each system in scope is mapped to it.
Choose on-premises or a local cloud region
Select a data center you operate or a cloud region inside the required zone, then confirm that the provider's control plane, snapshot storage and managed services used by the deployment are also covered by the boundary. Ask the provider in writing where backups, metadata and support access are located. If no cloud region satisfies every condition, the on-premises or air-gapped option becomes the only fit. The step is done when the hosting decision and its residency evidence are recorded.
Size write, batch and read instances
Plan one write instance, one batch instance and as many read instances as the load requires, as the Fineract documentation recommends for high load. Each instance type is set through environment variables, so define those values per role in your deployment manifests. Your team should also confirm the expected transaction and reporting load with the business before fixing instance counts. The step is done when a sizing sheet maps each instance role to its configuration and expected load.
Set up PostgreSQL with read replicas
Provision PostgreSQL, which the Fineract README names as the recommended database, inside the residency boundary, with read replicas for the read instances. The official Docker image ships only the PostgreSQL JDBC driver, so MariaDB and MySQL are not a default path. Your database administrators should set backup, encryption and access controls at this layer and document them. The step is done when replication to the read replicas is verified and the database sits entirely inside the boundary.
Run Liquibase migrations on the write instance
Run database migrations only on the write instance, as the documentation specifies, or separately using the liquibase-only Spring profile on Kubernetes. Keep migration jobs in your change control process so every schema change has a ticket, an approver and a rollback plan. Run the migration against a non-production copy first and compare the resulting schema with the expected version. The step is done when the schema matches the target release and the migration log is archived as change evidence.
Configure tenants and connect events
Create the tenants database and register each tenant, since API requests carry the Fineract-Platform-TenantId header and tenant connections come from that database. Connect event delivery to ActiveMQ or Apache Kafka, whichever your operations team can run inside the boundary, and confirm which topics carry customer data. Your integration team should document which downstream systems consume the events. The step is done when each tenant responds to an API call with its own identifier and events flow only to approved consumers.
Harden, test and document the deployment
Apply your hardening baseline to the containers, Kubernetes cluster, network paths, secrets and administrative access, and remember that the project warns its images are not production-ready. Run security testing against the APIs and the cluster, and record remediation. Document the architecture, data flows and access model so auditors can trace them. The step is done when test findings are closed or accepted in writing and the evidence pack is complete.
Plan backups and quarterly upgrades
Define backup schedules, restore tests and retention periods for the database, event store and configuration, all held inside the residency zone. Fineract publishes official releases quarterly, so set a recurring review that assesses each release, schedules test upgrades and retires any version that reaches end of life. Agree in writing who performs restores and upgrades, whether your team or a support partner. The step is done when a restore has been demonstrated and the upgrade calendar is owned by a named person.
What a self-hosted Fineract residency deployment costs and who pays for it
The main cost of a self-hosted Fineract residency deployment is not the software licence, because Apache Fineract is licensed under the Apache License 2.0. The cost sits in the components the institution, or a partner it pays, must build and run inside the residency zone: compute and storage in the approved country or facility, a highly available PostgreSQL service with backups and replicas, the read, write and batch instances the Fineract documentation describes, network controls, and the front end, since Fineract is headless and ships no user interface. Infrastructure is a recurring cost. Implementation and product configuration of loan and deposit products, tenant setup, integration with payments, general ledger and reporting, data migration, and security testing are largely one-time or per-release costs. Backup, restore testing, upgrades and monitoring recur for the life of the platform. The in-house team is the largest recurring cost and the one most often underestimated.
The Fineract README warns that a production deployment can be complex, costly and time-consuming, that the project does not provide a comprehensive production deployment guide, and that organizations may pay a vendor for deployment and maintenance. Treat that as a planning assumption. Each cost rises with the number of products, the number of integrations, the volume of transactions, the number of regulated jurisdictions the tenants serve, and the frequency of quarterly releases your team chooses to adopt. Each falls with reuse of tested configuration, managed PostgreSQL in the residency zone where the regulator accepts it, and a stable upgrade cadence. Ask any vendor for a written scope that separates one-time work from retainer work, names the people and skills per phase, lists every environment to be built (including non-production copies of client data, which the residency rule also covers), and states who carries the cost of a failed upgrade or a restore test. Confirm with your regulator whether the residency requirement also applies to support access from outside the zone, since remote administration can pull that cost back into scope.
Evidence supervisors and auditors ask for under a residency constraint
A residency requirement is only as credible as the records behind it. The items below are documents and test results your institution produces and keeps current, whether the core runs on Mambu's cloud regions or on self-hosted Apache Fineract. DeployOpen can prepare much of this evidence, but auditors and certification bodies, not DeployOpen, issue opinions and attestations.
Contract clauses on location and notice
Your ICT contracts should state where services are provided and where data is processed, and require advance notice before those locations change. DORA Article 30(2) makes this explicit for ICT services contracts, and it also covers data return on insolvency or termination. For a Mambu deployment, check the chosen cloud region and the notice terms for region changes. For a self-hosted Fineract core, check the hosting and any integrator or support agreements, which should name the data location.
Register of information
DORA Article 28(3) requires a register covering all contractual arrangements for ICT services. For a residency case, each entry should record the provider, the service, the country where data is stored and processed, and whether the service supports a critical or important function. A self-hosted Fineract core still needs entries for the cloud provider, the database operator and any support partner, so the register reflects the real data path rather than just the software license.
Data location maps
A data location map traces where each category of banking data lives: client records and KYC documents, loan and savings ledgers, backups, replicas, logs and reporting extracts. Build it from the actual architecture, including read replicas and any copies held by monitoring or analytics tools. Regulators tend to probe the places that are easy to forget, so confirm with your Mambu region settings or your own Fineract deployment diagrams that no copy leaves the permitted jurisdiction.
Access control and MFA evidence
Keep exports of who can reach the core, from which networks and under which roles, along with proof that multi-factor authentication is enforced for every person with access to the information system. The FTC Safeguards Rule requires MFA for any individual accessing any information system unless the Qualified Individual approves an equivalent control in writing, which makes the approval itself a document to keep. For Fineract, include administrative access to the database and to the tenant configuration, not only the front end.
Backup and restore test records
Residency rules often assume that data stays local, so the restore path must stay local too. Record backup schedules, storage locations, encryption arrangements and the dates of restore tests, including a test that rebuilds a tenant in the permitted location. Document the results and the defects found. Ask your Mambu contract team what backup and restore access you hold, and for a self-hosted Fineract core, make sure restores are rehearsed on infrastructure you control.
Change and upgrade records
Auditors look for controls over program changes, computer operations and access to programs and data, areas named in SEC guidance for internal control assessments. For a Mambu core, keep the release notes and your own test sign-offs for vendor-run changes. For a self-hosted Fineract core, the institution sets the upgrade timing, so keep change tickets, test evidence and rollback plans for each release. Fineract publishes quarterly releases, which sets a regular cadence for those records.
Questions buyers ask before choosing a residency-driven Fineract deployment
Can Mambu meet a data residency requirement on its own?
It depends on what the regulator or policy actually requires, and that is the first thing to confirm. Mambu describes itself as a cloud-native SaaS core banking platform and announced general availability on Amazon Web Services, Google Cloud and Microsoft Azure on October 24, 2022, so the question is whether the cloud regions and hosting arrangement your supervisor accepts match where your ledger must sit. Ask Mambu in writing which regions your tenant can run in, where backups and support access are located, and whether the arrangement can be placed on infrastructure you control. If the requirement is that the ledger sits on premises or in a specific local facility you operate, a SaaS tenant will not satisfy it, and a self-hosted core becomes the only fit.
How long does a self-hosted Apache Fineract deployment take?
No duration is fixed by the project, and the timeline depends on scope, data volume, integrations and how much hardening your security team requires. 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. Its Docker images are also documented as not production-ready, so you should expect to build the production packaging, database, messaging and backup layers yourself or with a partner. Ask any implementation partner for a fixed-scope plan with milestones agreed in writing before work starts, and check that the plan covers product configuration, cutover rehearsals and evidence for your assessors.
What does the in-house team need to run Fineract?
The team needs skills in Java application operation, PostgreSQL administration, container or Kubernetes operations, event messaging, security configuration and banking domain knowledge for loan and deposit products. The Fineract documentation describes separate read, write and batch instance types, with Liquibase migrations running only on write instances, so operators must understand how those roles are deployed and scaled. Fineract is headless and has no built-in user interface, so you also need a front end, either built in-house on the REST APIs or taken from a distribution such as Mifos X. Confirm these skills in your own staff assessment before committing to a self-hosted core.
Can we run a self-hosted Fineract core without an implementation partner?
Some organizations do, but the Fineract project itself points out that organizations may pay a vendor for deployment and maintenance, which signals how common outside help is. Running it alone requires a team that can handle installation, configuration of the multi-tenant setup, database operations, upgrades and incident response, plus the documentation a supervisor will ask for. A partner can plan, implement, customize, integrate, harden, back up, upgrade and document the platform inside your own cloud account, data center or air-gapped network, under a fixed-scope agreement. DeployOpen is one such option, and its work covers security testing and compliance readiness, but it does not issue audit reports or certifications. Decide the split of responsibilities in writing.
What drives the cost of a residency-driven Fineract deployment?
The cost has several components: Fineract software itself carries no license fee under Apache 2.0, while infrastructure, implementation, product configuration, integration, data migration, security testing, support and staffing are paid to others or to your own payroll. Costs are one-time for design, build, migration and initial testing, and recurring for hosting, database and messaging operations, support retainers, upgrades and staff time. Costs rise with the number of loan and deposit products, the number of integrations, data volume, the availability level you need, and the number of environments your assessors expect. Ask Mambu for its subscription and any residency-related hosting terms in writing, and ask each provider for a line-item quote tied to a written scope.
How are Fineract upgrades handled once the core is self-hosted?
You control the upgrade timing, but you also carry the work. The Fineract README states that official releases are created quarterly, at the end of each quarter, following the ASF release policy, and that end-of-life releases are archived. The current stable release listed on the project website is 1.15.0, and its documentation was built on July 10, 2026. Plan a test environment that mirrors production, run Liquibase migrations on a controlled write instance or through the liquibase-only Spring profile on Kubernetes, and keep rollback steps documented. Agree with any partner who will own quarterly upgrades, testing and the evidence trail, and confirm how long each upgrade cycle will take before signing.
What should we ask for in a quote before we commit?
Ask for a written scope that lists the residency boundary, the hosting location of every component, the products and integrations in scope, and the environments to be delivered. Request separate line items for design, implementation, data migration, product configuration, security testing, documentation, training, backup and recovery testing, and recurring support or upgrade retainers. Ask how the provider will deliver the evidence your supervisor and auditors need, and which parts remain your responsibility. Confirm with your supervisor which controls and reports they expect, because DeployOpen prepares systems and evidence but does not issue audit reports, attestations or certifications, and independent assessors do that work. Also request an exit and data return plan, which your contract should cover.
How a fixed-scope residency engagement is defined
A residency engagement with DeployOpen starts from a written, fixed scope. DeployOpen plans, implements, hardens, backs up and documents the self-hosted core inside your own infrastructure, whether that is a cloud account in the country your regulator names, a data center you operate, or an air-gapped network. The scope states which components are in, such as the Fineract application tier, the PostgreSQL databases, the tenant database layout, the read, write and batch instances, the event broker and the backup chain, along with the deliverables and timelines agreed before work begins. Ongoing upgrades and continuous testing are not part of the fixed build. They are covered by a retainer, which you can scope separately once the initial deployment is accepted.
Three inputs decide whether the scope can be written at all. First, the residency decision must be explicit: which country or facility holds the ledger, which copies of client and KYC data may sit outside it, and whether backups and logs follow the same rule. Second, DeployOpen needs infrastructure access in your accounts or facilities, with named administrators, network paths to any Mambu extract source, and approval of the hardening baseline. Third, you need named data owners for clients, accounts, products and reconciliation, who sign off on the mapping and cutover checks. Without them, the scope will carry open assumptions that change the price.
DeployOpen does not publish prices. A quote follows from the written scope, so ask for it to list each component, who performs each task, what is one-time (build, configuration, migration rehearsal, documentation) and what recurs (infrastructure, licences you choose to hold, retainer, testing). Confirm with your infrastructure team which costs they will carry, since cloud or data center charges are paid to your provider, not to DeployOpen. Ask also for the acceptance criteria and the change process for scope additions, because those terms determine how much of the quoted figure is actually fixed.
How DeployOpen deploys Apache Fineract under a data residency constraint
When a regulator or policy fixes where the banking ledger must sit, we start by writing down the residency requirement, the jurisdictions involved and the systems that touch client data. We then plan a self-hosted Apache Fineract deployment inside infrastructure the institution controls, whether on premises or in a local cloud.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which data stores, backups, logs and integrations must stay within the required country or facility.
- We confirm with your compliance and legal teams which residency obligations apply and where the evidence must come from.
How we build
- We install Apache Fineract on your chosen infrastructure, using PostgreSQL as the recommended database for the deployment.
- We configure tenants, read, write and batch instances, and database replicas to match your expected load and operating model.
- We test backup, restore and failover within the residency boundary, and document where every copy of client data resides.
How we hand over
- You receive architecture, data flow and hosting location documentation that your auditors and supervisors can review.
- We provide runbooks for upgrades, Liquibase migrations and tenant onboarding, so your team can operate the platform.
- Handover includes a written list of open risks and the controls you own, such as access management and change approval.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We can keep residency controls under review as Fineract releases move forward on the project's quarterly cycle.
- Retainer scope, response expectations and fees are agreed in writing with your team and quoted from that scope.
