Open source core banking for DORA

Supervisors look for dated, retrievable records that show the bank runs its ICT risk management as written. For a self-hosted Apache Fineract core, the main sets are monitoring logs, the information security policy, backup policies and test records, restoration reports, change tickets, patch records, third-party register entries and exit plans. DORA sets no certification scheme, so no certificate is issued for any of this. Competent authorities review the evidence under their supervisory powers, which is why the bank should be able to produce each record on request, not only at audit time.

Article 9 expects the bank to continuously monitor the security and functioning of its ICT systems, so the evidence is the logs and alerts that show this happening. For a Fineract deployment, these typically come from the application server, the PostgreSQL database, the reverse proxy and the identity layer, collected into a central log store with retention set by the bank. Keep records of who accessed the tenants database, administrative actions on write and batch instances, and alert handling with timestamps and owners. Confirm with your monitoring team which sources are in scope and how long they are kept.

Article 9(4)(a) requires a documented information security policy, and an examiner will check that it covers the core and its supporting components. The document should name the owner, define access limits for legitimate approved activities, and describe how network and infrastructure are managed, including any automated isolation of affected assets. It should be approved by the management body and reviewed on a set cycle, with the review record kept. Your own policy, not a vendor template, is what supervisors read first, so check that it names the Fineract environments explicitly.

Article 12 requires a documented backup policy that sets the data in scope and the minimum backup frequency based on criticality and confidentiality, plus restoration and recovery procedures. The evidence is the policy itself, backup job logs, and records of periodic tests of both backup and restoration. For a self-hosted core, add the segregated copy: Article 12(3) requires restored systems to be physically and logically separated from the source and protected from unauthorized access or corruption. Keep the restoration report for each test, including the data restored, time taken, issues found and the sign-off.

Article 9(4)(f) requires documented, risk-based change management so every change is recorded, tested, assessed, approved, implemented and verified. Evidence is a change ticket for each modification, with the risk assessment, the approver, test results from a non-production environment, the implementation record and post-change verification. For Fineract, this covers product configuration, accounting rules, database migrations run by Liquibase on write instances, and infrastructure updates. Auditors often sample tickets, so check that emergency changes also carry approval and a later review record.

Article 9(4)(f) also requires documented patch and update policies, so the examiner will expect a record of what was patched, when, and why. Useful evidence includes the quarterly Fineract release adoption record, the vulnerability scan output, the patch approval, the test result and the deployment record for each component, including the Java runtime, the database and the operating system. Fineract publishes official releases quarterly, so the bank needs a documented decision on when to adopt each one and a plan for end-of-life versions. Ask your implementation partner to show how they track these items before go-live.

Article 28 requires ICT third-party risk to sit inside the ICT risk framework, with a register of ICT service arrangements and a strategy on services supporting critical or important functions. When the bank hosts Fineract itself and no vendor runs the core, the register still lists the software provider, the implementation partner, the cloud or data center provider, and any support or retainer contract, each with its role and the functions it supports. The exit plan should describe how the bank would move data and operations if a partner stopped providing services. Confirm with your legal and third-party risk teams how each entry is classified.

DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so it can prepare runbooks, configuration baselines, backup and restoration procedures, and documentation for the change and patch processes. It can also prepare the systems and controls for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent assessors and supervisors decide the outcome. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. Ask for a sample evidence pack and the list of records that will be handed over at the end of the engagement.

The cost is driven by services and internal staff time, not by a license fee, because Apache Fineract is licensed under Apache-2.0. The Fineract README warns that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. The main cost components are product configuration, accounting setup, front-end and channel integration, payment and KYC integration, infrastructure, testing, backup and restoration design, documentation and ongoing support. Each of these scales with the number of products, tenants, integrations and regulatory reports in scope. Ask any partner to split the quote by these components so you can see who is paid for what.

One-time work usually includes scoping, product and accounting configuration, integration build, initial hardening, migration, restoration testing and the first set of DORA evidence such as the ICT risk framework documentation and the backup test records. Recurring costs include infrastructure, licenses for any third-party components you add, security testing, patching, quarterly release adoption (Fineract publishes official releases quarterly, and the current stable release is 1.15.0), periodic backup and restoration tests, and the staff who run the platform. DORA also requires that the ICT risk framework is reviewed and maintained, so budget for that work continuously rather than as a project phase.

No reliable duration can be stated from the researched material, so treat any timeline in a proposal as an estimate that must be justified by scope. The timeline depends on how many loan and savings products exist, how much accounting logic must be reproduced, how many channels and payment or KYC integrations are required, whether data migration is involved, and how many environments and tests the bank's change management process demands. Ask the partner to show a plan with milestones tied to the written scope, and ask which items are fixed and which are assumptions.

The bank must own decisions that DORA makes the financial entity responsible for. These include the ICT risk management framework, the classification of critical or important functions, the backup scope and minimum frequency for each data set, the recovery objectives agreed with business owners, the ICT third-party risk register and exit planning, access approvals for privileged roles, and change approval. Business owners must confirm product rules and accounting treatment, and the security team must confirm controls such as strong authentication and cryptographic key handling. Article 28(1) keeps the financial entity fully responsible for compliance at all times, so these inputs cannot be delegated to an implementation partner.

Yes, it is possible for a team with strong platform, database and security skills, since Fineract is open source and self-hosted. The Fineract documentation describes read, write and batch instance types and notes that Liquibase migrations run only on write instances, so the team must understand that architecture before going live. The honest question is capacity: the team must cover build, hardening, backup and segregated restoration, testing, upgrades every quarter and day-to-day operations for a core system. Many banks split the work, keeping ownership and operations in-house while buying specific services such as architecture review, penetration testing or migration support. Confirm your internal skills and staffing before deciding.

DORA has applied since 17 January 2025, and it is a regulation, so it applies directly in member states without national transposition. Your ICT risk management must cover protection and prevention, detection, backup and restoration, and the management of ICT third-party risk, including the register of third-party arrangements. Because the bank hosts the core itself, the third-party position depends on which services it still buys, such as cloud infrastructure, hosting, support or integrators. Your national competent authority supervises compliance, so confirm with your supervisor and legal counsel how the rules apply to your entity type and whether NIS2 or other rules also apply.

No. DORA sets no certification scheme, and competent authorities supervise compliance using their powers under Article 50. The only authority-issued attestation the Regulation provides for concerns whether a threat-led penetration test met the requirements under Article 26(7). DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ask any partner that offers a DORA certificate to show which body issued it and under what scheme, because the Regulation does not provide one.

Ask for a fixed-scope proposal with a written list of deliverables, assumptions, exclusions and acceptance criteria before work starts. The quote should separate one-time work from recurring support, state which DORA evidence the partner will prepare, such as configuration records, backup and restoration test results, change records and penetration test reports, and say what the bank must provide. Ask how the partner handles quarterly Fineract releases, which environments are included, who holds privileged access, and how exit or handover will work. DeployOpen does not publish a price list, and a quote follows from the written scope.