Mambu alternative for DORA exit strategy requirements: the short answer
If your EU bank or lender runs its core on Mambu, DORA does not ban a SaaS core. It requires you to hold documented, tested exit strategies and transition plans for ICT services that support critical or important functions, and contracts that carry an exit strategy with an adequate transition period, full service levels, audit and access rights. Self-hosted Apache Fineract, licensed under Apache 2.0, changes who controls the exit path: you hold the code, the deployment and the data stores, so the exit no longer depends on a vendor's export tooling or contract timing. It does not remove your obligations. DORA applied from 17 January 2025 as Regulation (EU) 2022/2554 (EUR-Lex text of DORA), and it applies directly in every member state without national transposition.
DORA sets no certification scheme. No authority issues a DORA badge for a core platform, and the only authority-issued attestation the Regulation provides for concerns a threat-led penetration test. Your supervisor will judge whether your exit plan works from evidence: the register of information, the contract terms, the results of exit rehearsals and the records of who approved each decision. Confirm with your national competent authority which documentation format and level of testing it expects, because supervisory practice varies by entity type.
Moving to Fineract also moves work onto your side of the table. The exit plan you write must cover your own hosting, patching, backups and the staff who run them, not only the Mambu contract. Ask your legal and compliance team to confirm how your current Mambu agreement handles data return on termination, and whether your register of information already records Mambu as supporting a critical or important function. Those answers set the scope of the plan before any platform decision is made.
What DORA requires of a SaaS core supporting critical functions
When a core banking platform supports a critical or important function, DORA puts obligations on the contract, the register, the exit plan and the supervisory relationship. The six points below are the ones that change how a Mambu exit or a self-hosted Apache Fineract core has to be documented and tested.
Register of information
Article 28(3) requires you to keep a register of information covering every contractual arrangement for ICT services, including the core banking provider and its sub-providers. For a SaaS core, the entry should name the service, the hosting regions, the contract owner and whether the service supports a critical or important function. Check that the register is current before any exit or migration decision is taken, because supervisors will compare it against your contracts and your actual architecture.
Documented and tested exit strategies
Article 28(8) requires documented, tested exit strategies and transition plans for ICT services that support critical or important functions. A plan that exists only on paper does not meet the test, so the plan should cover data extraction, parallel running and cutover steps for loans, deposits and payments. Ask what evidence your team can show of a past exit test, and who signs off the plan when the provider changes its terms.
Data location and data return terms
Article 30(2) requires every ICT services contract to state where the services are provided and data is processed, and to give advance notice of changes to those locations. It also has to cover return of data if the provider becomes insolvent or the contract ends. For a SaaS core, confirm the hosting regions named in the contract, the notice period for region changes, and the format and timing in which your ledger, customer and product data can be returned.
Mandatory transition period and audit rights
Article 30(3) requires contracts for critical or important functions to include exit strategies with a mandatory adequate transition period. The same clause set also requires full service levels, audit and access rights. Review whether your Mambu contract gives you a transition period long enough for a parallel run, and whether your auditors and supervisors can reach the provider's relevant records. Clarify with the vendor how these rights are exercised in a multi-tenant SaaS environment.
Threat-led penetration testing participation
Article 30(3) also requires the contract to oblige the provider to take part in the financial entity's threat-led penetration testing. Article 26 sets the testing framework that this participation supports. For a SaaS core, confirm that the provider has agreed in writing to join tests scoped to your environment, and that the scope, rules of engagement and evidence handling are defined in advance. The ECB states that DORA TLPT and TIBER-EU core requirements are identical.
Supervisory oversight by the competent authority
Article 46 assigns supervision of each type of financial entity to a national competent authority, and the ECB handles credit institutions classified as significant. Supervisors will ask how the core's concentration risk, exit plan and provider oversight are managed, and they can review your register and contracts directly. Confirm which authority supervises your institution, and prepare documentation that shows how the exit and concentration picture changes if you move the core in-house.
Where a Mambu deployment meets DORA and where the institution still carries the gap
Mambu being a SaaS core does not move DORA obligations to Mambu. 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. For your ICT third-party risk file, the first questions are which provider and region hold the ledger and customer data, which entity contracts with Mambu, and whether the contract states where services are provided and data processed, with advance notice of changes, as Article 30(2) requires. Check the chosen hosting region against your data location commitments and confirm the change-notice terms in writing, because a cloud region choice made during onboarding is easy to forget at renewal.
The exit strategy, the entry in your register of information under Article 28(3) and the tested transition under Article 28(8) are your work, whichever vendor you use. Mambu can supply contract terms and documentation, but it cannot test your plan for you. Ask Mambu to confirm in writing its contractual exit assistance, the export formats for accounts, schedules, client records and transactions, the time it needs to return data on termination or insolvency, and what transition support, if any, is included or priced separately. Do not assume these from marketing material or from a general SaaS norm. Record the answers as evidence, then test them with a rehearsal that proves your team can actually read the exported data.
Which open-source options change the exit and concentration picture
Apache Fineract is an Apache 2.0 licensed, headless core that exposes REST APIs and runs on infrastructure you control, either on Kubernetes or on virtual machines. Moving the core in-house removes the single SaaS provider as the only party able to run, patch and restore your ledger, and it gives you the source code to inspect and the option to fork it if the project changes direction. Concentration shifts from one vendor to a set of components you choose and can replace, such as the database, message broker and hosting provider.
- Exit path: The product, data and configuration sit in your own database and cloud accounts, so an exit plan can be written against your own systems rather than a vendor export.
- Upgrade timing: Releases are created quarterly and end-of-life releases are archived, so you set the schedule for moving to each new version.
- What it does not cover: Fineract provides no user interface, so product teams and staff need an application built on the raw API or a packaged front end.
- Operational load: The 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. Vendors offer paid deployment and maintenance, so support is a contract, not a feature.
- Feature gaps: Confirm product, accounting and reporting coverage against your loan and deposit portfolio, since the project's documentation does not replace a Mambu-to-Fineract fit assessment.
Ask your team which component owns each runbook, backup and restore test, and who holds the on-call duty before you count the core as a reduced-concentration option.
Mifos X is a web application and mobile apps built on Apache Fineract, distributed under MPL-2.0. It addresses the gap that a headless core leaves for lenders who need staff screens on day one. Choosing it does not change the core's concentration profile, because the same Fineract back end still holds the ledger, but it can reduce the number of teams that must build and maintain an interface from scratch.
- Concentration effect: The front end is a separate component you can host and replace, so the user interface is not tied to a single SaaS vendor's release cycle.
- Release lag: Web app releases can trail Fineract, so check which Fineract version each Mifos X release targets before you commit to an upgrade sequence.
- Partner dependence: Deployment is often led by a partner, which can recreate a provider dependency in a different form. Ask for runbooks that your staff can execute without that partner.
- Scope: Mifos X is aimed at microfinance and inclusive lending, so confirm that its product and screen coverage matches your lending or deposit products.
- Licence and support: MPL-2.0 is a different licence from Fineract's Apache 2.0, so have legal review how the two components are combined and distributed.
Before relying on this tab, confirm with the Mifos Initiative which Mifos X release is supported with which Fineract release, and how security patches reach each component.
Hyperswitch is an Apache 2.0 licensed, Rust-based payments orchestration platform from Juspay. It connects to over 100 payment processors and includes a card vault service. It applies where card and payment traffic sits outside the core banking ledger, so the exit question concerns the vault and routing layer rather than the loan or deposit system. Self-hosting it can reduce dependence on a single payment orchestration provider and keep card tokens under your control.
- Multi-processor routing: Connections to many processors reduce the risk that one processor or orchestrator becomes a single point of exit failure, subject to your own certification with each processor.
- Deployment options: It can run on Docker, on Kubernetes with Helm charts, or on AWS, GCP and Azure, so you choose the environment that fits your residency and exit requirements.
- Card vault: Vault data stays in your environment, but PCI DSS obligations for storing cardholder data remain with your institution and must be assessed.
- What it does not cover: Processor contracts, acquiring, fraud operations and chargeback handling are not provided by the software and must be arranged separately.
- Maturity: Confirm the production readiness, support model and release history with Juspay and your own testing before you treat it as a replacement for a managed vault.
Confirm with your QSA how the card vault's scope affects your PCI DSS assessment and how token export would work in an exit.
How to deploy Fineract as a tested exit target
This sequence turns a self-hosted Apache Fineract deployment into a documented, rehearsed fallback core that an institution can actually switch to if its Mambu arrangement fails or ends. It is built from the project's documented architecture, not from a turnkey production guide.
Confirm critical function scope and register entries
Compliance, the business owner of the lending or deposit function and the ICT risk lead agree which services support critical or important functions and where Mambu appears in the register of information. The output is a signed scope note listing the products, data sets, interfaces and recovery objectives the exit target must cover. Confirm the scope with your competent authority's expectations and your own DORA policy before any build work starts.
Choose infrastructure inside your own control
The infrastructure team selects a cloud account, data center or private environment that the institution controls and that meets the data location terms your Mambu contract and register entries describe. Record where Kubernetes, the databases, message brokers and backups will run, and who holds administrative access. The output is an approved architecture decision record that also names the separate environment used for rehearsal.
Deploy PostgreSQL and the Fineract instance pattern
Engineers provision PostgreSQL, which the Fineract README recommends over MariaDB and MySQL, and deploy Fineract with the read, write and batch instance pattern described in the Fineract documentation: one write instance, one batch instance and several read instances on database read replicas. Use the official Docker images or your own build, knowing the project warns those images are not production-ready. The check is that each instance type starts with its intended environment variables and that health endpoints respond.
Run Liquibase migrations on the write instance
Per the Fineract documentation, Liquibase migrations run only on write instances, and on Kubernetes they can run as a separate job using the liquibase-only Spring profile. Schedule the migration job before the application pods start so schema changes are applied once and in order. The output is a migration log showing every changeset applied to the target schema, retained with the environment's change records.
Configure tenants and tenant databases
Fineract is multi-tenant: requests carry a Fineract-Platform-TenantId header and tenant connections come from a tenants database. Set up each tenant that represents a legal entity or a separate portfolio, and confirm that a request with one tenant identifier cannot reach another tenant's data. The check is a documented access test per tenant, run by someone other than the person who configured it.
Connect events through ActiveMQ or Kafka
Configure the event broker the institution has chosen, either ActiveMQ or Apache Kafka, which the Fineract repository lists as supported for events. Wire downstream consumers such as the general ledger, reporting and payment interfaces to those topics, and document the replay and retention settings. The output is a tested message flow showing that business events from a Fineract test tenant reach each consumer.
Rehearse the exit or transition in a test environment
Run a timed rehearsal in an isolated environment: extract a representative data set from Mambu through the export route your contract allows, load it into Fineract, reconcile balances, schedules and client records, and confirm that the critical functions run. Record gaps, unsupported products and manual steps, and feed them back into the exit plan and the contract's transition terms. The output is a dated rehearsal report with reconciliation results that the board or risk committee reviews, and that a qualified assessor can inspect.
Evidence supervisors and auditors ask for
DORA does not create a certification, so the evidence you hold is what a supervisor or auditor will test. The six items below connect the contractual, planning, testing and assurance sides of the exit obligation for a SaaS core such as Mambu. DeployOpen can help prepare these records, but independent auditors and competent authorities decide what they conclude.
Register of information entries
Article 28(3) requires a register covering every contractual arrangement for ICT services. For a Mambu core, each entry should name the provider, the services supporting critical or important functions, the locations where data is processed, and the sub-contractors involved. Check that the register is kept current when you change hosting regions or add a Mambu integration, and that it links to the exit plan for the same service.
Documented exit strategy and transition plan
Article 28(8) requires documented exit strategies and transition plans for ICT services supporting critical or important functions. For the core, the plan should set out the trigger events, the target platform (for example a self-hosted Apache Fineract deployment), the data to extract, the order of product and portfolio migration, and who decides to start the exit. Confirm that the plan covers both an orderly exit and a sudden provider failure.
Test records of the exit or transition
A documented exit plan must also be tested, and the test records are what show it works. Keep dated records of extraction runs, reconciliation of account balances and loan schedules, and any cutover rehearsal in a non-production tenant. Record what failed, who approved the fix and when the test was repeated. Records from a parallel run are often the strongest evidence of an exit you can actually execute.
Contract clauses on data return and transition
Article 30(2) requires contracts to state where services are provided and data processed, with advance notice of changes, and to cover data return on insolvency or termination. Article 30(3) requires exit strategies and a mandatory adequate transition period, along with service levels and audit and access rights. Check the Mambu agreement for the export formats, the timing of data return and whether the transition period is stated in terms your exit plan can meet.
Threat-led penetration test participation records
Article 26 requires eligible financial entities to run threat-led penetration testing, and Article 30(3) requires the contract to allow participation in that testing. Keep records showing which ICT providers were in scope, the provider's agreed role in the test, and remediation of findings that touch the core. The only authority-issued attestation DORA provides for is that a TLPT met the requirements under Article 26(7), so confirm with your competent authority how it expects the records to be presented.
Independent assessment reports from qualified auditors
DORA sets no certification scheme, so the independent view on your controls comes from auditors you engage, not from a DORA certificate. Ask for reports that cover the core's access controls, change management and operations, and whether the scope includes the self-hosted Fineract environment if you move there. DeployOpen prepares systems, controls and evidence for these assessments but does not issue audit reports or attestations.
Questions buyers ask before a DORA-driven core exit
Does DORA force a bank to leave Mambu?
No. DORA does not require any institution to replace a SaaS core. It requires a financial entity to have documented, tested exit strategies and transition plans for ICT services that support critical or important functions, under Article 28(8) of Regulation (EU) 2022/2554. Staying on Mambu is compatible with DORA if the exit plan exists, has been tested, and the contract contains an exit strategy with an adequate transition period, as Article 30(3) requires. Moving to self-hosted Apache Fineract is one way to change the exit picture, but it is a business decision, not a regulatory requirement. Confirm the exact obligations with your competent authority and your own legal and compliance team.
What does a Fineract exit plan cost, and what drives the cost?
Cost depends on the scope you agree in writing, so there is no fixed figure to quote here. The main components are infrastructure (hosting, databases, messaging, backups and separate environments for test and production), implementation and product configuration, data extraction and reconciliation, integration with payment, general ledger and reporting systems, security testing, and an in-house team to operate the platform after go-live. Infrastructure and licensing are recurring costs, while implementation and migration are largely one-time. Fineract itself is Apache 2.0 licensed, so there is no license fee, but the README warns that production deployment can be complex, costly and time-consuming. Ask each provider for a line-item quote that separates one-time work from recurring run costs.
How long does a migration from Mambu to Fineract take?
The duration depends on the product catalogue, the number of clients and accounts, the integrations that depend on Mambu's APIs, and how much parallel running your regulator and risk function expect. No timeline is established here. Ask for a written scope and timeline before work starts, with milestones for product mapping, data extraction, reconciliation runs, testing, cutover and a post-cutover review. Ask how the plan covers a rollback path and how the exit plan itself will be tested, since Article 28(8) expects a tested plan, not only a documented one. A realistic plan treats the exit test as a deliverable with its own schedule.
Can the bank run a Fineract exit without outside help?
A bank can do it alone only if it already has a skilled platform team and banking domain experts who can operate a core banking system, not just deploy containers. Fineract is headless, has no built-in user interface, and expects you to own deployment, database operations (PostgreSQL is the recommended database), Liquibase migrations, multi-tenant configuration, read and write instance design and backups. Most in-house teams will need to build or source skills for loan and deposit product configuration, reconciliation and accounting. Many institutions combine internal ownership with an implementation partner for the first release and then keep part of the work in-house. Assess your team against that list before choosing a model.
Does moving to Fineract change concentration risk and Article 28 obligations?
Yes, it changes where the concentration sits, but it does not remove your obligations. Under Article 28(3), you still need a register of information on every ICT contractual arrangement, including any implementation partner, hosting provider and cloud platform you use for Fineract. Article 30(2) still requires contracts to state where services are provided and data is processed, and to cover data return on termination. Self-hosting shifts concentration from one SaaS vendor to your own infrastructure and to the people operating it, and it may concentrate dependence on a single cloud or data center. Document those dependencies, assess them as ICT third-party risk, and test the exit from each one.
What does the bank still own after leaving Mambu for Fineract?
The bank owns the outcome. Responsibilities that remain with you include the ICT risk management framework, incident management and reporting, digital operational resilience testing, the register of information, the exit plan and its testing, security hardening and patching, access control, backup and recovery testing, and evidence for supervisors. Fineract's Apache 2.0 license does not transfer any of these duties to the project. The Apache project does not provide a comprehensive production deployment guide, so the architecture, hardening and operating runbooks must come from you or your partner. DeployOpen can plan, implement, harden, back up, document and test these elements in your own environment under a written scope, but it does not issue audit reports or certifications, which independent auditors provide.
What should an exit test prove before a supervisor sees the plan?
An exit test should show that the bank can move the core's functions, data and dependencies to a target platform within the transition period in the contract, without losing records, misstating balances or breaking regulatory reporting. For Mambu, test the extraction paths you intend to use, such as the APIs, database backups or an ETL route, and reconcile the results against the source. For Fineract, test a restore into the target, product behaviour for each loan and deposit type, interest and fee accruals, the general ledger postings and reporting outputs. Record the results, the defects and the decisions, because that record is the evidence a competent authority will ask for. Confirm the test scope with your supervisor and your own risk function.
What supervisors still expect you to own after switching
Moving a core from Mambu's SaaS to self-hosted Apache Fineract does not move your regulatory obligations to a vendor. It moves operating responsibility to you or your chosen partner. DORA's ICT risk management and third-party rules still apply to every system that supports a critical or important function, and the Fineract platform, its hosting, its database and its release cycle become your ICT risk to document, test and report. Confirm early which team owns each of these: patching of the Fineract application, the PostgreSQL database and the container and Kubernetes layers, backups and restore testing, incident detection and the reporting clock, and access control for administrators and integrations. Fineract's official releases arrive quarterly, so you need a written upgrade process that tests each release before production, and the Fineract README notes that end-of-life releases are archived, which means an unsupported version can quietly become your problem.
Two obligations deserve a named owner from day one. The threat-led penetration testing cycle under DORA Article 26 is yours to schedule, scope and fund, and a self-hosted core must be in scope if it supports critical or important functions. Your own exit plan under Article 28(8) also has to cover the self-hosted stack, including the hosting provider, backup copies and the people who can run the platform. If you handle card data around the core, PCI DSS v4.0.1 applies to the cardholder data environment, and the payment brands decide who must validate, so the scope of your assessment may grow when you host more components. If you are a Swift user, the Swift Customer Security Controls Framework still requires independent assessment and an annual attestation in the KYC-SA application, whatever runs the core. Ask your assessor and your supervisor to confirm which of these apply to your entity before you sign any implementation contract.
How to test an exit plan so it holds in a supervisory review
This sequence turns a written DORA exit strategy into evidence that a Mambu exit to a self-hosted Apache Fineract core can run, with reconciled data, a contract transition clause, and recorded test results that a supervisor can review.
Define the exit triggers and critical functions
Name the events that would start an exit, such as a provider insolvency, a material service failure, a contract termination or a regulator direction, and list which critical or important functions depend on the Mambu core. Assign an owner in the business and in technology for each trigger. Done when the trigger list is approved by the exit plan owner and mapped to the ICT services register entry for Mambu, as Article 28(3) requires for the register of information.
Export Mambu data into a Fineract test tenant
The technology team extracts clients, accounts, loan and savings products, schedules and transaction histories from Mambu using the export routes the bank has confirmed with the provider, then loads them into a non-production Apache Fineract tenant. Fineract is multi-tenant, so the test tenant should be isolated from production and identified by its own Fineract-Platform-TenantId value. Done when the load completes without rejected records and the load log is archived as evidence.
Reconcile balances, schedules and accounting
Finance and operations staff compare account balances, outstanding principal, interest accruals and repayment schedules in the Fineract test tenant against the Mambu source for a defined cut-off date. Differences are classified as mapping errors, rounding differences or missing product rules, and each class has a named fix. Done when every population has a signed reconciliation report with zero unexplained differences, and the product configuration mapping used to load it is versioned.
Document the transition period in the contract
Legal and procurement confirm that the Mambu contract includes an exit strategy, a transition period sized by the bank's own risk assessment, data return on termination or insolvency, and stated locations for service and data processing, as Articles 30(2) and 30(3) require. Ask the provider in writing for its export formats and assistance obligations during transition. Done when the clause text and the provider's written confirmations are filed with the register entry. Confirm the wording with counsel, since the contract is the bank's own document.
Run a tabletop exercise with decision makers
Senior management, the operational resilience lead, compliance, legal and the Fineract platform team walk through one trigger scenario from declaration to restored service, including who can approve the exit, how customers and the competent authority are informed, and how incidents are reported under the bank's DORA processes. Facilitators record decisions, gaps and open questions. Done when the minutes list every decision made, every gap with an owner and a due date set by the bank, and the scenario is repeated in the next review cycle.
Perform a technical rehearsal of the cutover
The platform team runs a timed cutover rehearsal in a staging environment: freeze a Mambu extract, run the load into a Fineract instance built from the hardened production baseline, start the read, write and batch instances as documented, switch integrations to the new endpoints, and confirm that payments and reporting work. Fineract's documentation recommends separate read, write and batch instances for high load, so the rehearsal should test that topology. Done when the rehearsal log shows each step, its elapsed time and any manual intervention.
Record results and track remediation
Compile the trigger list, load logs, reconciliation reports, contract clauses, tabletop minutes and rehearsal logs into one exit test file. Each failed check becomes a tracked remediation item with an owner, a fix and a retest. Share the file with the board-level body that approves the exit strategy and keep it current when the Mambu contract, Fineract release or data model changes. Done when every remediation item is closed or formally accepted by the risk owner, and the file can be produced to a supervisor on request.
How DeployOpen plans the exit and the self-hosted core
DeployOpen scopes a self-hosted Apache Fineract core as a written, fixed-scope engagement, covering the Fineract deployment, hardening, backup and integration work inside the client's own cloud accounts, data centers or air-gapped network. The scope document names the components in play: the Fineract write, batch and read instances, the database layer (Fineract's README recommends PostgreSQL), the tenants database and the event broker if one is used, along with the integrations to payments, general ledger and reporting. Agreeing these boundaries early matters for DORA because the register of information and the exit plan both need an accurate list of what runs where and who operates each part.
On the evidence side, DeployOpen prepares the material a financial entity presents to its supervisor: documented exit and transition plans for the ICT services that support critical or important functions, contract and service-level records, backup and restore results, access control and change records, and the findings from security testing of applications, APIs, infrastructure and integrations. Exit plans are only credible if they are exercised, so the scope should include a restore test into a separate environment and a dry run of data return in a format the bank can read without the original vendor. Ask any provider, including DeployOpen, which of these items sit inside the fixed scope and which are retainer work.
DeployOpen does not issue audit reports, attestations or certifications. Independent auditors, the competent authority and, where applicable, the ECB or a threat-led penetration testing provider make those determinations, and DeployOpen's role is to prepare the systems, controls and evidence those parties review. Before signing, confirm with your own compliance team which findings and documents your supervisor expects, and whether your internal audit will test the Fineract environment as a critical ICT service in its own right.
How DeployOpen works on DORA exit strategy projects
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Mambu exit, that means turning DORA exit and transition requirements into a written scope, a tested Fineract deployment and evidence your team and your auditors can review.
How we scope
- Map the Mambu contracts, ICT services and critical or important functions that the exit plan must cover
- Agree in writing which Fineract products, integrations and data sets are in scope before work starts
- Define deliverables for the exit strategy, transition plan and register of information updates
- Confirm hosting location, data processing locations and advance-notice terms the contract must state
- Engagements are fixed-scope, with timelines and deliverables agreed in writing; a quote follows from that scope
How we build
- Deploy Apache Fineract in your cloud account, data center or air-gapped network, using PostgreSQL as the recommended database
- Configure tenants, products and business rules, then build the extraction and reconciliation routines for the Mambu data
- Run parallel reconciliation and document results so the transition plan rests on tested evidence
- Harden the platform and test it, including the security testing you choose to include in the written scope
- Document architecture, runbooks and the staged exit steps that your own team will need to run and repeat
How we hand over
- Deliver the exit strategy and transition plan as documents tied to the systems they describe
- Run a walkthrough of the exit test results so your board, risk and third-party teams can challenge the evidence
- Transfer administration, backup and upgrade procedures to your operations staff with written runbooks
- Prepare control evidence for your compliance team, noting that independent auditors issue any assessment outcome
- Agree the handover acceptance criteria in the written scope so both sides know when the work is complete
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build
- Plan Fineract upgrades around its quarterly release cycle and the end-of-life archiving policy
- Keep backups, restore tests and exit rehearsals on a schedule agreed with your risk function
- Review the exit plan when contracts, providers or DORA-related standards change, including the ongoing Digital Omnibus proposal
- Ask for a written quote and support terms that name the responsibilities your team keeps
