Self-hosted open source core banking with Apache Fineract

Open source core banking: when Apache Fineract fits and what to decide first

If your legacy core is expensive to change, or you are launching a new lender or institution and need loan and deposit accounts from day one, Apache Fineract is the primary open-source core banking option for loan and account management. Whether it fits depends less on the platform than on three decisions you make first: the product scope you must support, the integration pattern with your channels and payment rails, and the audit and retention evidence your regulator expects. Fineract is licensed under Apache-2.0, and the current release you should evaluate against is Fineract 1.15.0, published on July 14, 2026. Confirm that version and its upgrade path with the project before you commit to a baseline.

Before you select a core, list the products you must run on day one: loan types, savings and deposit products, fee and interest rules, and the accounting treatment for each. Fineract models these as configurable products, so a product that needs logic outside standard configuration will mean custom development that you must test, document and maintain. Map every product against your current core's behavior, including end-of-day processing and delinquency handling, and record which behaviors are configuration and which are code. That list drives the scope, the team and the cost of the project more than any licensing decision.

Fineract is the core, not the whole stack. Most institutions still need a general ledger or ERP, a CRM for relationship staff, a payment orchestrator, and a subscription or billing engine where recurring charges apply. Open-source options exist around these needs, including Apache OFBiz for ERP-style business applications, Hyperswitch for composable payments and Kill Bill for subscription billing, so the core decision should be made together with the adjacent systems it must feed. Confirm which system owns customer identity, transaction posting and reconciliation before you design interfaces. Ask any implementation partner to show you a data ownership map and the API contracts that connect Fineract to each system.

What to agree before choosing a core banking platform

Core banking selection goes wrong when the institution has not settled its own rules first. The six decisions below set the product model, reporting obligations, onboarding data, channel access, daily processing and record keeping that any Fineract deployment must satisfy, and each one has to be owned internally before a partner scopes the work.

Product catalog scope

Decide which loan, savings and deposit products the core must run on day one, and which ones can wait. Each product carries its own interest accrual, fee, collateral and maturity rules, so the catalog drives configuration effort more than any other choice. Ask each product owner to write down the calculation method, the penalty rules and the events that change account status. Products that exist only in spreadsheets today usually surface as the largest gaps in configuration.

Regulatory reporting obligations

Settle which returns, prudential reports and internal management reports the core must produce, and who signs off on each. Reporting logic often lives in the legacy core or in side systems, so the institution must decide whether the new platform generates the data, a data warehouse does, or a combination does. Confirm the reporting calendar and the source of truth for each field with your regulator's current requirements.

Customer onboarding and KYC data

Define which identity attributes, beneficial ownership records and risk ratings the core stores, and which stay in a separate KYC or case management system. Decide how verification results are linked to customer records and how refreshed information is pushed back to the core. Mismatched customer identifiers between onboarding and the ledger are a common source of reconciliation breaks and audit findings.

Channel access and integration

List every channel that reads or writes core data, including online banking, mobile, branch tellers, card processors and partner lenders. Decide which channels call the core directly through its APIs and which go through an integration layer or API gateway. Each channel adds authentication flows, rate limits and transaction types that must be tested against the core before launch.

Batch processing and end of day

Agree the end-of-day sequence: interest accrual, fee posting, delinquency aging, statement generation and the general ledger feed. Decide the cut-off times, who can restart a failed batch and how partial runs are reconciled before the next business day opens. Confirm the batch window against the volume of accounts and transactions the institution expects, since this window governs operational risk more than raw hardware size.

Data residency and audit records

Decide where customer data, backups and logs may be stored, which jurisdictions can access them and how long each record class must be kept. Map the audit trail the regulator expects, including who changed a product rule, who approved a transaction and when a configuration changed. The FTC Safeguards Rule requires covered institutions to log the activity of authorized users, and an SEC broker-dealer rule sets a three-year minimum retention for certain business records, so retention and log design should be confirmed against the institution's own regulator before hosting is chosen. Confirm the retention periods that apply to your licence type with counsel and your regulator.

Which open-source core and adjacent platforms fit which need

This table compares Apache Fineract as the core ledger and loan engine with adjacent open-source components for billing, payments and CRM, plus general ERP options that are not banking cores. Read each row for the job it covers, the license that governs it, and the operating effort it adds, then decide which components sit in the core path and which sit beside it.

Component	When it fits	License	Operating effort
Apache Fineract	Core ledger, deposits and loan engine for institutions that need a purpose-built banking core and an API-first design	Apache-2.0	High: product configuration, accounting setup, integrations, security hardening, and upgrades all sit with the institution or its partner
Kill Bill	Subscription billing and recurring payment schedules that sit beside the core and feed invoices or charges into it	Apache-2.0	Medium: catalog modeling, payment plugin setup, and reconciliation with the ledger must be designed and tested
Hyperswitch	Routing card and account payments across several processors, with tokenization and retries in front of the core	Apache-2.0	Medium to high: connector onboarding, PCI scope analysis, and reconciliation are the main ongoing tasks
SuiteCRM	Relationship management for relationship managers and servicing teams, with data kept in the institution's own environment	AGPL-3.0	Medium: customer data model, identity integration, and mapping to core customer records need design work
EspoCRM	Lighter CRM for teams that want a smaller footprint for lead and servicing workflows	AGPL-3.0	Low to medium: fewer components to run, but customer data still needs a defined sync with the core
Odoo Community and Enterprise	General ERP for finance operations, procurement and HR beside the bank, not a banking core	LGPL-3.0 (Community core)	Medium to high: a separate system with its own upgrade cycle and customization limits
ERPNext	General ERP for accounting and operations at smaller organizations, not a loan or deposit engine	GPL-3.0	Medium: a separate system to integrate, with its own upgrade and customization path
Apache OFBiz	General ERP and commerce framework with broad business applications, judged as ERP rather than banking core	Apache-2.0	High: a framework that needs substantial internal development and skills to run

Reference architecture components and how they connect

A core banking deployment on Apache Fineract is a set of components with clear owners: the ledger, the access layer, the channels, the money movement services, the reporting store and the audit trail. The integration pattern between them determines how easily you can change one without destabilizing the others. The topology below is a starting point, and the exact deployment must be confirmed in your environment.

Fineract core services and database

Fineract holds the customer, account, loan product, savings and general ledger records, and its relational database is the system of record for balances and schedules. Treat the database as the most sensitive component: plan its backup, point-in-time recovery and replication before configuring products. Confirm which database engine and version your Fineract release supports, and whether your team will manage it directly or through a managed service inside your cloud account.

API gateway and identity layer

All channels and internal services should reach Fineract through a gateway that enforces authentication, rate limits, and request logging. Pair it with an identity provider that issues tenant-scoped tokens and supports multi-factor authentication for every staff user, as the FTC Safeguards Rule expects for any individual accessing customer information. Confirm how Fineract's tenant and role model maps to your existing directory groups before go-live.

Channel applications

Mobile, web, branch and partner applications should consume Fineract only through documented APIs, never through direct database access. Each channel needs its own client credentials, consent handling and session rules, and its own test suite that runs against a non-production tenant. Confirm which channel applications are built in house, which come from a vendor, and who owns the API versioning contract between them and the core.

Payment and billing layer

Payment rails, card processing, and recurring billing sit outside the ledger and post results back into Fineract through an integration queue. Keeping the boundary explicit makes reconciliation and PCI scope easier to reason about. Options include a payment orchestrator such as Hyperswitch and a subscription billing platform such as Kill Bill, but confirm each connector, settlement file format, and retry behavior with the processor before choosing.

Reporting and data warehouse

Regulatory reporting, risk dashboards, and finance close should read from a separate reporting store fed by change data capture or scheduled extracts, not from the production database. This protects core performance and gives analysts a stable schema. Confirm the refresh latency your regulators and finance team require, and who signs off on report logic changes, because a reporting change is still a control change.

Logging and audit store

Every authorized user action, configuration change, and approval must land in an append-only audit store that is separate from application administrators' reach. The FTC Safeguards Rule requires logging of authorized user activity, and SEC Rule 17a-4(b) sets a minimum three-year retention period for certain broker-dealer records, so confirm which retention applies to your institution. Test that logs survive a core restore and can be exported for examiners.

How product configuration and APIs shape the build

Product and credit teams define what the institution offers: loan products, savings products, fee structures, interest rules, repayment schedules, and the accounting mappings that post each event to the general ledger. In Fineract, much of this is set through the administrative configuration rather than code, so the people who own the product rules can change them with controlled access and without a developer writing a new service. The risk sits in the details of each product. A small change to an interest calculation, a grace period or a fee trigger can alter balances for every open account, so the product owner needs a clear record of what changed and why.

Product definitions: Confirm which parameters are set per product (principal limits, interest methods, term units, fee events) and which require a formal change request.
Accounting mappings: Check that each product event posts to the correct ledger accounts, and that the chart of accounts is agreed with finance before go-live.
Maker and checker control: Confirm that the platform separates the person who configures a product from the person who approves it, and that approvals are logged.
Versioning and effective dates: Ask how changes apply to existing accounts and whether a new rule can be scheduled for a future date.
Test scripts per change: Require a regression set that runs sample loans through disbursement, repayment, arrears and closure for each changed product.

Before any product change reaches production, ask your implementation partner to show the test evidence for that specific product, including expected balances and ledger postings.

What the security and audit requirements demand from a core banking deployment

The FTC Safeguards Rule at 16 CFR 314.4 sets the baseline for covered financial institutions, and a Fineract deployment has to meet it in the infrastructure around the core as well as in the application itself. The rule requires encryption of customer information in transit over external networks and at rest, so the team needs to confirm TLS termination points for the Fineract REST APIs and channel gateways, and encryption settings for the PostgreSQL or MySQL databases, object storage for documents, and backups. It also requires multi-factor authentication for any individual accessing any information system, which covers Fineract administrators, branch staff, operations users, database administrators and the vendor or DeployOpen engineers who support the platform. Change management procedures and logging of authorized user activity are required too, so every product configuration change, role assignment and manual journal entry needs an approved ticket and an audit trail that cannot be silently edited. Confirm with your compliance team how long these logs are kept and where they are forwarded.

Under 16 CFR 314.4(d)(2), an institution that does not run effective continuous monitoring must perform annual penetration testing and vulnerability assessments at least every six months. Many teams treat that as a one-time launch task, but it recurs for the life of the platform, and it applies to the Fineract stack, its integration middleware, the channel applications and the hosting environment. DeployOpen runs security testing of applications, APIs, cloud and infrastructure, but it does not issue audit reports, attestations or certifications. The institution still needs its own assessor or auditor to evaluate the evidence, so ask your auditor early which artifacts they expect: test scopes, findings, remediation records and retest results.

If the institution or an affiliate is a broker-dealer, SEC Rule 17a-4(b) adds a records retention requirement. It calls for preserving certain records, including bills receivable or payable, bank statements and originals of business communications, for not less than three years, with the first two in an easily accessible place. Whether this applies to a lending or deposit platform depends on the institution's registrations and activities, so confirm the regulatory perimeter with legal counsel before setting retention and archive design. Also confirm which other rules apply, including state licensing, prudential regulator guidance and any data protection obligations in the jurisdictions where customers are located. Those answers decide which controls the requirements matrix must map to.

How a phased migration from a legacy core runs

The sequence moves a financial institution from a legacy core to Apache Fineract in controlled stages, with each phase closing on a written artifact that the institution can review and sign. Parallel running and reconciliation are what give the bank evidence that balances, postings and customer records match before any customer depends on the new core.

Confirm scope and map legacy data
DeployOpen works with the institution's product, finance and operations owners to list the products, customer segments, GL structure, channels and reporting obligations in scope. The team then maps legacy tables, account types, balances, schedules and history to the Fineract data model, flagging fields that have no equivalent and need a decision. The phase closes with a signed-off scope document and a data mapping specification that names every source field, its target, its transformation rule and its owner. Schedule and effort come from that written scope and from the institution's size and number of products.
Design and configure products and accounting
Working from the signed scope, the team configures Fineract loan and savings products, interest and fee rules, repayment schedules, charge structures and the chart of accounts mapping. Each product is documented with its business rules, the legacy behavior it replaces and any deliberate difference the institution has approved. Compliance and finance reviewers sign off on accounting entries and product terms before configuration is treated as final. The output is a product catalog with approved configuration records and an accounting mapping document.
Build integrations and execute test evidence
The team builds the interfaces the core needs, including channel APIs, payment and card connections, general ledger export, credit bureau and regulatory reporting feeds, and identity and access controls for staff users. Each interface is tested with scripted cases covering normal flows, rejected transactions, reversals and end-of-day processing. Test results are recorded against the scope so that every requirement has a traceable result. The phase closes with a test evidence pack that lists executed cases, defects found, how each was resolved and who accepted the residual risk.
Migrate data in trial loads
Legacy data is extracted and loaded into a non-production Fineract environment several times, each time with a reconciliation of record counts, balances and totals against the source. Exceptions, such as accounts with inconsistent schedules or unmapped statuses, are logged and resolved in the mapping specification rather than patched by hand in the target. The institution's data owners confirm each trial result. The output is a trial migration log that shows how each load moved and what was corrected between runs.
Run in parallel and reconcile daily
The legacy core and Fineract process the same business activity for an agreed period, and the team compares balances, postings, interest accruals, fees and customer-facing outputs between them. Differences are classified, assigned an owner and closed before the next cycle. Operations and finance leaders decide the exit criteria for parallel running in advance and record them in the cutover plan. The output is a reconciliation report for each cycle and a summary of open and closed differences that the institution's leadership reviews before approving cutover.
Execute cutover from a signed runbook
The cutover runbook sets out the freeze window, the final data extract and load, validation checks, rollback triggers and the people authorized to make each decision. DeployOpen runs the steps under the institution's change management procedures, with logging of privileged actions and multi-factor authentication for every administrator. Each step records who performed it, when, and the result. The phase closes when the institution confirms the new core as system of record and the cutover record is filed with the change tickets.
Provide hypercare and hand over operations
After go-live, the team monitors transaction processing, reconciliations, interface errors and support tickets closely, and resolves defects under the agreed severity process. Operational runbooks, backup and restore procedures, access reviews and monitoring dashboards are handed to the institution's operations team and documented. The hypercare period ends when the exit criteria agreed in the written scope are met and the institution accepts the handover. Ongoing support, upgrades and testing can then continue under a separate retainer if the institution chooses.

Systems the core must connect to and what each integration involves

A core banking platform rarely runs alone. The general ledger, payment rails, card orchestration, identity and credit data, digital channels and regulatory reporting all exchange records with the core, and each exchange has its own direction, timing and failure mode. Plan each interface with its owner, its reconciliation method and its replay behavior before the first production posting.

General ledger posting

The core produces journal entries for interest accrual, fees, disbursements and repayments, and the general ledger must receive them exactly once. Typical methods are scheduled batch files or event-driven posting through an integration layer, with account and product codes mapped in advance. The main risk is duplicate postings after a retry or a partial batch failure, so confirm idempotency keys, batch control totals and a daily tie-out between sub-ledger and ledger balances.

Payment rails and processors

Inbound and outbound transfers move between the core and clearing networks, instant payment schemes and correspondent banks. Most integrations use message files or API calls with acknowledgments that arrive asynchronously, so a payment can be sent but not yet confirmed. The main risk is reconciliation mismatches between the core's posted status and the rail's settlement file, so confirm the cut-off times and the exception queue for returns and rejects.

Card and payment orchestration

Card authorizations, clearing files and payment routing usually pass through an orchestration layer before reaching the core as holds, debits or credits. The core must accept authorization holds that later expire or are reversed, which many loan and deposit products were not designed for. The main risk is double debits when an authorization is captured twice or a reversal arrives after a settlement, so confirm the hold lifecycle and reversal rules with the card program owner.

KYC and credit bureau data

Identity verification providers and credit bureaus supply customer identity results, sanctions screening outcomes and credit reports used for onboarding and underwriting. These are usually request and response calls with stored results, and the core should keep the evidence reference rather than the full bureau file where policy allows. The main risk is using stale or mismatched records, so confirm data retention rules, consent capture and how re-screening events update an existing customer.

Digital channels and identity

Mobile apps, internet banking, partner portals and staff consoles call the core through its APIs, with authentication handled by a separate identity provider. Each channel needs scoped tokens, rate limits and consistent error codes so that a retried request does not create a second loan disbursement. The main risk is a channel bypassing business rules that the core enforces for branch staff, so confirm which checks run in the core rather than in the front end.

Regulatory and data warehouse reporting

Regulatory returns, risk reports and the analytics warehouse read account, loan and transaction data on a schedule, often through extracts or change data capture. Reporting extracts are one-way, but they must reflect the same cut-off and business date as the ledger. The main risk is a report that differs from the ledger after a backdated transaction, so confirm which business date each report uses and how restatements are logged.

Compliance evidence a Fineract deployment helps produce

This table maps the evidence a self-hosted Fineract deployment can produce to the 16 CFR 314.4 Safeguards Rule elements and, where applicable, the 17 CFR 240.17a-4 record preservation rule. Read each row as the artifact an assessor will ask for, not as proof that the control exists. Auditors and certification bodies assess compliance, not DeployOpen.

Requirement	Evidence artifact	Where it usually fails
Encryption in transit and at rest (16 CFR 314.4)	TLS configuration reports, database and volume encryption settings, key management records	Internal service traffic left unencrypted, backups or reporting replicas outside the encryption scope
Multi-factor authentication (16 CFR 314.4)	Identity provider MFA policy export, admin and staff access listings, exception approvals	Service accounts, API clients or database admin paths that bypass MFA
Change management (16 CFR 314.4)	Change tickets, approval records, configuration-as-code history, product configuration change logs	Product or fee configuration changed directly in production without review
Activity logging of authorized users (16 CFR 314.4)	Fineract audit trail extracts, centralized log retention settings, access review records	Audit tables not forwarded to a central store, or logs kept without a retention rule
Penetration testing and vulnerability assessment (16 CFR 314.4(d)(2))	Annual penetration test report, vulnerability scan reports at least every six months, remediation tracking	Testing scoped only to the web front end, leaving APIs and integration endpoints untested
Record preservation for broker-dealer records (17 CFR 240.17a-4)	Retention policy, archive configuration, retrieval tests showing records are accessible in the first two years	Fineract is not the system of record for securities activity, so the rule may not apply; confirm scope with counsel
Assessment responsibility	Auditor or certification body reports; DeployOpen supplies configuration, runbooks and evidence packs only	Teams assuming the implementation partner's documents count as an audit opinion

What drives the total cost of a self-hosted core

The cost of a self-hosted core is mostly people and migration work, not the software. Apache Fineract is licensed under Apache-2.0, so there is no license fee to budget for. What you pay for is the work around it: discovery, data migration from the legacy core, product configuration, integration with channels and payment rails, security testing, infrastructure in your own cloud account or data center, staff to operate the platform, and upgrades. Some of these costs are one-time (discovery, migration, initial integration and the first round of penetration testing). Others recur every year (infrastructure, operations staffing, patching, upgrades, regression testing and support). Separate the two in every budget, because a low first-year figure can hide a recurring run cost that continues for the life of the core.

Several factors move these costs up or down. The number of loan and deposit products, fee schedules and interest rules multiplies configuration and test effort. The number of integrations (card processors, general ledger, credit bureaus, identity providers, document stores) drives interface build and ongoing maintenance. Data quality in the legacy core often matters more than any other variable: duplicate customers, inconsistent account states and undocumented balances extend migration cycles. Whether you already have engineers who know Java, PostgreSQL and Kubernetes or Docker-based operations, or must hire or contract them, changes the staffing line more than almost anything else. Ask whether your team will own day-to-day operations, or whether a support retainer covers them.

When you request a quote, insist on an itemized statement of work with each deliverable priced or estimated separately, and written assumptions about data volumes, number of products, integrations, environments and test cycles. List explicit exclusions, such as licensing of third-party services, hardware, regulator-facing documentation you prepare yourself, and any work that depends on decisions you have not yet made. Confirm the support model in writing: response expectations, who is on call, what upgrades are included, how often they occur, and what happens when a change request falls outside scope. Fixed-scope engagements are agreed before work starts, so any open assumption should be resolved before signing, not during delivery.

Questions buyers ask before hiring help on a core banking build

Can an in-house team run Apache Fineract without outside help?

Yes, some institutions run Fineract with in-house staff, but it depends on whether the team already has Java, Spring, database, container and integration skills, plus people who understand banking products and accounting. Fineract is an open source core banking platform licensed under Apache-2.0, so the license cost is zero, but the work of configuring products, building channel APIs, hardening the platform, running backups and handling upgrades falls to your team. Ask yourself whether you can staff those roles for the life of the system, not only through go-live. A partner can fill gaps for a fixed scope, while a retainer covers ongoing upgrades and support. Confirm your skills gap in writing before you decide.

What does a Fineract core banking implementation cost?

The cost depends on scope, not on the software license, because Fineract is licensed under Apache-2.0. The main components are the people who configure loan and savings products, build integrations with your channels, payment rails and general ledger, perform security testing, prepare audit evidence and run data migration. Infrastructure in your own cloud or data center, monitoring, backup storage and the time your staff spend on product rules are recurring or ongoing costs. Costs rise with the number of product types, custom integrations, data volume and the number of legacy systems being retired. Ask any provider for a written scope with deliverables, assumptions and exclusions before comparing quotes.

How long does a migration from a legacy core take, and what sets the time?

The timeline is set by the number of product types to rebuild, the quality of legacy data, the number of integrations, and how many cutover rehearsals your risk team requires. Migration usually runs in phases: product design, a build and test cycle, parallel runs, and a staged cutover. Each phase waits on decisions from your business owners, so delays often come from approvals rather than from technology. Ask for a phased plan that names the exit criteria for each phase and the dates your sign-off owners have agreed to. Treat any duration you are given without a documented scope as a starting assumption, not a commitment.

What does our institution have to supply for the project?

You must supply the product rules, a named set of decision owners, the data needed for migration, test users and the time your staff spend in workshops and testing. Product rules include interest methods, fee schedules, collateral and delinquency policies, and accounting mappings to your general ledger. Data work requires access to legacy extracts, data owners who can explain odd records, and a decision on which closed or dormant accounts to migrate. Name one accountable owner per area, such as credit, deposits, finance, risk and compliance, and agree on who can approve each release. Projects stall when these people are not available, so put their time into the written scope.

How are Fineract upgrades and security patches handled after launch?

Upgrades and patches are an ongoing operating task that you own, whether your team or a partner performs them. Fineract is developed as an open source project with its own release cycle, so you need a process to track releases, test your customizations against each new version, schedule maintenance windows, and roll back if something breaks. Your customizations, integrations and product configurations are the parts most likely to need rework. Confirm who monitors vulnerability notices, who approves production changes and how the change management records are kept. A support retainer can cover this work, but ask the provider to state what is included and how urgent security fixes are handled.

Does Fineract meet our regulatory requirements by itself?

No. Fineract is a software platform, and regulatory compliance depends on how your institution configures, secures, operates and documents it. Frameworks such as the FTC Safeguards Rule at 16 CFR 314.4 require encryption, multi-factor authentication, change management, activity logging and periodic penetration testing and vulnerability assessments, and your institution must put those controls in place and keep evidence. Record retention rules, such as SEC Rule 17a-4(b) for broker-dealers, apply to the records your system keeps, so confirm your retention design with counsel. Independent auditors and certification bodies issue any opinion on your compliance, not the implementation partner. Ask your partner which controls they will implement and which evidence they will prepare.

How do we avoid posting errors during a legacy cutover?

Posting errors are avoided through reconciliation, rehearsal and controlled cutover, not by trusting a single migration run. Before cutover, migrate data more than once, compare balances, interest accruals and open items between the legacy system and the new core, and resolve every difference with a named owner. Run parallel processing for a period where feasible, and confirm the general ledger mapping with finance before go-live. Define a rollback plan with clear triggers and a cutoff time, and keep the legacy system available in read-only mode for reference. Ask any partner to show its reconciliation reports and rehearsal results before production.

Questions to ask an implementation partner before signing

Start with the platform itself. Ask which Apache Fineract release the partner would deploy and what their upgrade approach is for the next release. Fineract 1.15.0 was published on July 14, 2026, so ask how they would move a live institution from an older release to a newer one, whether they maintain a patched fork, and who signs off on each upgrade. Ask how product configuration is tested: whether loan products, savings products, charge rules and accounting mappings are version controlled, which environment they are validated in, and what evidence the partner keeps that each product behaves as approved before it reaches production. Ask for an example of the test script for one loan product, including the repayment schedule and interest accrual checks, so you can judge its depth before you sign.

Next, pin down migration, security and evidence. Ask how the partner reconciles migrated balances against the legacy core: which record counts, balance totals and per-account checks are run at each cut-over rehearsal, who approves a variance, and whether reconciliation reports are delivered in writing. For security, ask for the scope and cadence of penetration testing and vulnerability assessment that will cover the Fineract API, the channel integrations and the administrative console. The FTC Safeguards Rule at 16 CFR 314.4 references annual penetration testing and vulnerability assessments at least every six months where continuous monitoring is not in effect, so ask how the partner would meet that requirement and who pays for it. Ask what audit evidence they deliver (change records, access logs, configuration baselines), which format it takes, and how long they retain it. Confirm that the partner prepares evidence for your assessors but does not issue audit reports.

Finally, cover hosting, support and ownership, then ask for the quote itself. Confirm the hosting location, the cloud account or data center that will hold personal and account data, the backup location and whether any support staff access production from outside your jurisdiction. Ask what post-go-live support is covered, what a retainer includes, and what response expectations are written into it. Ask who owns the customizations, configuration files, runbooks and documentation at handover, and whether you receive source code and the right to run it with another provider. Finally, ask the partner to show a fixed-scope quote that lists assumptions (for example, the number of legacy data sources and the state of their data quality), exclusions (for example, custom channel development or third-party licenses) and the change request process for anything that moves outside those lines.

How DeployOpen scopes, builds, hands over and supports a core banking platform

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a core banking deployment on Apache Fineract, that means the institution keeps the platform, the data and the evidence within its own cloud accounts, data centers or private networks, with the work agreed in a written scope before it begins.

How we scope

Written scope covering product catalog, loan and savings products, and the Fineract version to be deployed
Agreed list of channel integrations, payment rails and upstream systems that connect to the core
Defined security, audit and records requirements mapped to your regulator's expectations and internal policy

How we build

Configure products and accounting rules in a non-production environment, with each change traced to an approved requirement
Test API integrations for channels and general ledger, including security testing of exposed endpoints and authentication flows
Harden the deployment with encryption in transit and at rest, multi-factor access for administrators, and activity logging enabled

How we hand over

Deliver architecture, runbooks, configuration records and change procedures so your staff can operate the platform
Provide evidence packs that show controls in place, prepared for your independent auditors to assess
Walk your operations, security and compliance teams through the system before go-live and document the agreed exit criteria

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer after go-live
Plan Fineract version upgrades and patching against the written support agreement, with testing before each change
Confirm with us during scoping which support hours, response expectations and escalation paths apply to your environment