Core banking RFP questions to ask before you choose an implementation partner
The questions that matter most are about production experience, not the software. Apache Fineract is licensed under the Apache License 2.0, so the license costs nothing, but the work of running it in production is paid for in configuration, integration, testing and support. Ask each shortlisted partner which Fineract deployments they run in production today, how they configure loan and savings products and the accounting rules behind them, which front end they pair with the headless REST APIs, how they integrate payments and KYC providers, how they size read, write and batch instances, and how they adopt the quarterly releases. Those answers separate a partner who has operated a core from one who has only installed it.
Run the evaluation with one written question set sent to every shortlisted partner, and require evidence for each answer: named production deployments that can be discussed under NDA, sample product and accounting configuration, and the runbooks for backup, restoration, batch scheduling and upgrades. Score every response against the same criteria and record why a score was given, so the decision can be defended to your board and auditors. The Fineract README states that a production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide, so partner capability is the main variable in your outcome. Confirm each claim with references and written deliverables, not with the sales presentation. DeployOpen is a Chainscore Labs company. The questions here are neutral and apply to any implementation partner you evaluate.
Which Fineract deployments have you run in production?
How many live Apache Fineract cores have you put into production?
Ask for a count of live Fineract cores, not demos or pilots, and for each one the institution type, the Fineract version it runs today, the date it went live and the number of tenants. A credible answer gives these as a short table with anonymized scale, such as client counts band and loan portfolio size band, and notes which deployments remain under NDA. Ask the partner to state how many of those cores they led from design through cutover and how many they supported after another team built them. If the count of live cores is zero or the examples are described only as proofs of concept, treat that as a material gap for a production core banking decision.
Which Fineract version is each production deployment running today?
Each deployment should name its current Fineract version and the date of its last upgrade. Fineract publishes official releases quarterly at the end of each quarter, and the current stable release listed on the project website is 1.15.0, so ask how quickly the partner moved previous deployments onto new quarterly releases and whether any run an end-of-life release. Ask for the upgrade history, the Liquibase migration approach used on write instances, and the test evidence from each upgrade. A partner that cannot show upgrade records across more than one release is unlikely to have operated Fineract through its lifecycle.
What types of institutions run your Fineract deployments?
List the institution types behind each live core, such as a microfinance lender, a credit union, a digital lender, a fintech with a bank partner or a regulated bank, and state the jurisdiction for each. The type matters because licensing, reporting and data residency rules differ, and a deployment for a non-bank lender does not prove readiness for deposit-taking. Ask which of those institutions were subject to a prudential regulator and whether the partner supported any regulatory reporting or audit requests from them. Where the partner cannot share the type, ask for a reference call under a mutual NDA.
Who ran day-to-day operations on each production Fineract deployment?
The answer should separate three roles for each deployment: who built it, who operated it and who held on-call and change responsibility. Ask whether the partner ran the batch jobs for end-of-day processing, managed database backups and restores, and approved production changes, or whether the client's own team did. Reluctance to say which party ran operations is a red flag, because it determines who answers for an outage or a failed end-of-day run. Request the operating model in writing, including the support hours and escalation path agreed for each live deployment, and the RACI matrix used in the most recent engagement.
How many tenants does each production Fineract deployment serve?
Fineract is multi-tenant, with API requests carrying a tenant identifier header and connections configured from a tenants database, so a single deployment can serve several institutions or product lines. Ask how many tenants each live deployment runs, whether tenants share one database server or are isolated, and how tenant onboarding and offboarding were handled. Also ask how the partner tested tenant isolation and what happened when a tenant needed a separate release window. A high tenant count with no isolation evidence is a weaker answer than a smaller count with documented separation.
What scale did your largest Fineract deployment reach in production?
Ask for anonymized scale figures for the largest live deployment: active client count band, active loan and savings account band, peak daily transaction volume and the number of read instances used. Also ask how the sizing was validated, including load tests and the observed behavior of the single write instance, the batch instance and the read replicas. The Fineract documentation recommends one write instance, one batch instance and multiple read instances on database read replicas for high load, so the partner should explain how they arrived at their counts. Be cautious of scale claims with no load test method behind them.
Can you give a reference for a production Fineract deployment under NDA?
Ask for at least one reference call with a client running a live Fineract deployment, held under a mutual NDA, and ask the partner to describe the reference's role in the engagement before you speak. Ask the client to confirm the Fineract version, the scope the partner delivered, the operating model and how the first production incident was handled. The reference should be able to speak to the post-go-live period, not just the project. If the partner refuses any reference, or can offer only internal demonstrations, weigh that heavily against the other answers.
How long has each production Fineract deployment been live?
Ask for the go-live date and months in production for each live deployment, because a core that has been running for a single quarter has not yet been through a year-end, a regulatory reporting cycle or a full set of quarterly upgrades. Ask which deployments have completed an external audit or examination with the Fineract core in scope, and what the partner prepared for it. Note that evidence prepared for an audit comes from the institution and its assessors, since DeployOpen prepares systems and controls for assessments but does not issue audit reports. The answer should make the age and maturity of each deployment clear without requiring a follow-up.
Which front end do you use, and how do channels connect?
Apache Fineract is a headless application. It exposes REST APIs and does not provide its own user interface, so every screen your tellers, loan officers, credit analysts and finance staff use must come from a separate front end or a custom build. The Fineract README points to the Mifos X web application as the front end used in its Kubernetes example, which is a useful reference but not a product guarantee for your operations. Ask the partner which front end they recommend for staff work and why, and how that choice affects day-to-day tasks such as client onboarding, loan approvals, cash handling and end-of-day checks.
- Recommended front end: a named product or custom build, with the reasons tied to your product mix and staff roles.
- Role-based screens: how teller, approver and accountant views map to Fineract permissions.
- Maker-checker flows: how approvals are enforced in the interface and in the API, not only on screen.
- Support path: who fixes front end defects and who patches the Mifos X or custom code after each quarterly Fineract release.
- Session and access logging: how staff sessions are timed out and how user actions are logged for audit.
Check whether the partner can show a working staff screen for your own product types, not only a demonstration environment.
Customer-facing channels such as web banking and mobile apps call the same Fineract REST APIs, but they should never call them directly with a broad service credential. A channel layer, usually built in your own code with an API gateway in front, handles customer login, multi-factor authentication, device checks and rate limits, then passes only narrowly scoped requests to Fineract. Tenant context also matters, because Fineract is multi-tenant and API requests carry a Fineract-Platform-TenantId header, so the channel layer must set that header from a verified session and never from client input.
- Customer authentication: how customers sign in, which factors apply, and where credentials are stored.
- Authorization per request: how each API call is limited to the customer's own clients, accounts and loans.
- Tenant header control: where the Fineract-Platform-TenantId header is set and how a customer is blocked from changing it.
- Gateway and rate limits: which gateway or web application firewall sits in front of the APIs and how abuse is detected.
- Encryption and secrets: TLS on all external paths and how service credentials are stored and rotated.
Ask for the written channel security design and its threat model, and confirm that penetration testing covers the customer channel and the API layer.
Partners, fintechs and embedded finance products often need their own branded front ends on top of a shared Fineract instance. In this model, each partner usually maps to a separate tenant, and the partner's application authenticates its own users while calling Fineract through a controlled integration layer. The partner front end is then a product in its own right, with its own release cycle, its own defects and its own security exposure. Ask whether the partner has built or integrated custom front ends for third parties, and how the boundary between the partner's code and the core is defined in writing.
- Custom front end experience: examples of partner-facing applications built on Fineract APIs, described without client names unless you can verify them.
- Integration pattern: whether the partner calls Fineract directly, through a middleware layer, or through an event stream.
- Tenant isolation: how one partner's users are kept from reaching another partner's data.
- Partner security obligations: what the partner must own for authentication, audit logging and incident response.
- Change coordination: how front end releases are sequenced with quarterly Fineract releases.
Confirm who owns each layer of the stack and who answers for a customer-facing incident.
How do you integrate payments and KYC without weakening controls?
Ask the partner to describe, for each payment rail, card program and identity verification provider, where the integration sits and who owns its data. Fineract covers client data and KYC documents, and its loan and savings portfolio management and accounting are part of the core. Payment rails, card processing and identity verification providers typically sit outside the core, so they need their own design, testing and data protection. A strong answer names the integration pattern for each (for example, an API gateway, a message queue or a payment orchestration layer), the data flows between the core, the provider and the general ledger, and the test evidence for each interface. Ask which fields cross each boundary and whether any card data passes through the core at all.
Ask where KYC documents are stored, who can read them and how long they are kept. The partner should name the storage location, the encryption method in transit and at rest, and the key management owner. Where the institution is covered by the FTC Safeguards Rule at 16 CFR 314.4, that rule requires encryption of customer information in transit over external networks and at rest, multi-factor authentication for any individual accessing any information system, and logging of authorized user activity. Ask the partner to map each of these requirements to a specific setting, such as the TLS configuration on the Fineract and provider endpoints, the identity provider policy for staff and vendor accounts, and the audit log retention for document access. Confirm the exact obligations with counsel, since coverage depends on the institution's status.
Treat three answers as red flags. The first is raw card data stored in the core database, which widens the scope of every control in this section. The second is unclear ownership of KYC documents between the bank, the implementation partner and the identity verification vendor. The third is no plan for vendor access logs, meaning the partner cannot show who connected to production, which records they viewed and how those logs reach the institution's security team. Ask for the written access procedure, the privileged account inventory and a sample log export before contract signature. Responses should also address change management for each integration, because the FTC rule requires change management procedures for information systems.
How do you size read, write and batch instances?
Fineract separates work across write, batch and read instances, all backed by PostgreSQL and tenant connections. Each component below is a point where a partner's design either matches your load profile or leaves a gap you will pay for later.
Write instance and environment variables
The write instance handles transactional changes such as loan disbursements, repayments and account postings. Ask which environment variables the partner sets to make an instance a write instance, how they document those settings per environment, and how they prevent a second instance from accidentally taking the write role. Request the exact configuration for development, test and production.
Batch instance for end-of-day work
Batch processing runs end-of-day jobs such as interest accrual, scheduled repayments and reporting extracts, and it should run on its own instance so it does not compete with customer traffic. Ask how the partner plans the batch window, how long each job is expected to run against your largest portfolio, what happens when a job overruns, and how failed jobs are restarted without double-posting.
Read replicas and proposed count
Read instances serve reporting, portal and channel queries against PostgreSQL read replicas, which keeps heavy queries away from the write path. The Fineract documentation recommends one write instance, one batch instance and multiple read instances for high load. Ask how many read instances the partner proposes, the reasoning behind that number, how replication lag is measured, and which screens or reports are allowed to read stale data.
PostgreSQL and the database choice
PostgreSQL is the recommended database for Fineract, and MariaDB and MySQL are deprecated under FSIP-9. Treat any proposal for MariaDB or MySQL as a question that needs a written reason, a support position from the Fineract project and a test plan. Ask which PostgreSQL version and replication setup the partner uses, and how backups and point-in-time recovery are tested.
Tenant connections and Liquibase migrations
Fineract is multi-tenant, with API requests carrying a Fineract-Platform-TenantId header and tenant connections configured from a tenants database. Liquibase schema migrations run only on write instances, and on Kubernetes they can run separately with the liquibase-only Spring profile. Ask how the partner orders migrations during upgrades, how they confirm each tenant's schema version, and how they stop a read or batch instance from attempting a migration.
Load test evidence and sizing basis
Ask for load test results from a comparable deployment, including the transaction mix, concurrency, batch duration and database metrics that produced the sizing. A single instance serving all load, or sizing without test evidence, is a red flag. Request the sizing worksheet and the test scripts so your team can rerun the tests against your own volumes before go-live.
How do you adopt quarterly Fineract releases?
How do you track quarterly Apache Fineract releases?
We track official releases from the Apache Fineract project, which the README says are created quarterly at the end of each quarter under the ASF release policy. The current stable release is 1.15.0, published on July 14, 2026. Ask the partner how they monitor the project's release announcements and repository tags, who reviews each release against your environment, and how they record which version runs in each environment. A credible answer names a person or role for this watch and a written cadence for triage, not an informal habit.
How do you test a Fineract upgrade before production?
The partner should first apply the new version to a non-production environment that holds a copy of your tenant configuration, products and accounting setup, then run the same regression suite used for production sign-off. Ask whether they test in separate non-production tenants, how they refresh test data without exposing customer records, and who approves the test results. Upgrades should be rehearsed at least once against a recent copy of production data in a segregated environment before any production change is scheduled.
What regression testing covers loan products and accounting?
Regression testing should cover each configured product, including loan and savings product rules, interest and fee calculations, and the postings they generate to the general ledger. It should also check end-of-day batch runs, reporting outputs and the integrations with payments, KYC and channels. Ask for the test catalogue, which tests are automated, which are manual, and how opening balances and trial balances are reconciled after each upgrade. A partner who cannot show this catalogue has not tested your product configuration in a repeatable way.
What is the upgrade runbook and rollback plan?
A versioned upgrade runbook should list each step in order: backups, database migration, configuration changes, deployment of the write, batch and read instances, verification and sign-off. The rollback plan should state the restore point, the decision owner, and the time window in which rollback remains possible. Ask whether database migrations are reviewed before execution, since the Fineract documentation says Liquibase migrations run only on write instances, and how the partner confirms a restored backup works. Request the runbook template and the most recent rehearsal record.
How do you handle end-of-life or archived Fineract releases?
The Fineract README states that end-of-life releases are archived, so an archived version will no longer receive project updates. Ask the partner how they identify when your running version reaches that status, how long they plan to move you to a supported release, and whether they will maintain a patched build for a period if an upgrade is delayed. Your own change calendar should set the target version, and the partner should document any interim compensating controls for a version that no longer receives project fixes.
Who approves Fineract changes and security patches?
Change approval should sit with named roles on your side and the partner's side, with separate approval for functional changes, database changes and security patches. Ask who is accountable for each patch, what the response process is for a critical vulnerability in Fineract or its dependencies, and how emergency changes are recorded and reviewed afterward. The Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to adopt change management procedures, so the approval record should be retained as evidence.
What are the red flags in a Fineract upgrade plan?
The main red flags are a frozen version with no defined upgrade path, no owner for security patches, and no rehearsal in a non-production tenant. Be wary of plans that upgrade production directly, rely on memory instead of a runbook, or cannot show a tested rollback. Also question any partner who cannot say which Fineract release runs in each environment today. A plan that names a release, a rehearsal and a rollback point, with an owner for each, is the baseline to expect.
Does DeployOpen handle Fineract upgrades and patching?
DeployOpen plans, implements, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and ongoing upgrades are available as a retainer. Scope, deliverables and timelines for an upgrade are agreed in writing before work starts. Ask for the written scope to name the Fineract version, the non-production environments used for rehearsal, the regression catalogue, the rollback plan and who is accountable for each security patch. Your team keeps the approval decisions on your side.
How to run the partner evaluation step by step
This sequence turns a set of vendor answers into a comparable, evidence-backed shortlist and ends with a written scope that both sides can hold to. Each step produces a artifact you can file with the procurement record.
Send one written question set to every partner
Issue the same written questions to each candidate partner at the same time, covering Fineract production deployments, product and accounting configuration, front-end choice, payment and KYC integration, read, write and batch sizing, and how quarterly releases are adopted. The procurement lead owns the set, and every answer is logged against its question number. You know this step is done when every candidate has answered every question in writing, and any gaps are listed as open items.
Request sample configuration and runbooks under NDA
Ask each partner for sample product configuration, accounting mapping, batch schedules and operational runbooks, shared under a non-disclosure agreement. Your architect reviews whether the samples show the same instance layout the partner described, including separate write, batch and read instances and where database migrations run. The step closes when you have a written note for each partner stating which claims the documents support and which remain unverified.
Run a scripted demo in a test environment
Ask each partner to run the same script in a test environment you can observe: create a loan product, set its accounting rules, post a set of transactions, then run a batch cycle such as end-of-day processing. Your team records timings, errors and the steps that needed manual intervention. The step is done when each partner's run is recorded in the same template, so results can be compared side by side.
Check references for production scope
Speak with the references each partner names and confirm what was delivered in production, not only that a project existed. Ask which Fineract version they run, how many tenants and instances were set up, how batch jobs are scheduled, and how upgrades were handled. Compare these answers with the written responses and the demo results. The step is complete when each reference confirms or corrects the scope the partner described.
Score answers against agreed criteria
Before scoring, the evaluation panel agrees weighted criteria covering production experience, configuration depth, integration approach, operating model and security controls. Each panel member scores every partner independently, and the scores are then reconciled with notes on disagreements. The output is a single scoring sheet that shows the evidence behind each score, so the decision can be explained to auditors and to the board.
Confirm written scope and fixed deliverables
For the preferred partner, convert the evaluation findings into a written scope with named deliverables, acceptance criteria, responsibilities for infrastructure, testing and documentation, and the support arrangement after go-live. Legal and the security team review the document before signature. Work starts only after both parties sign the scope, which is the point at which the partner's quote becomes a commitment.
Answers that should worry you
A partner's answers to the questions on this page show how they will run a Fineract core in production. The red flags below are the answers that signal a gap in experience, cost planning or evidence. Each one is a question you can put back to the bidder in writing.
No live production Fineract cores
A partner that cannot name a Fineract deployment running in production has likely learned the platform on your project. Ask for the number of live cores, the tenant count, the release each one runs, and the date of the last upgrade. Ask whether they can arrange a reference call with a client that has agreed to it. A demo environment does not show how the system behaves at end of day with real loan and savings volumes.
A free license quoted as total cost
Apache Fineract carries no license fee, and the project's own README warns that production deployment can be complex, costly and time-consuming. A bid that presents zero license cost as the total price has left out product configuration, front-end build, integration, infrastructure, testing and ongoing support. Ask for a cost breakdown by component, separating one-time work from recurring items, and state who is paid for each.
No reconciliation to the general ledger
Fineract provides real-time integrated accounting, but the mapping from products to ledger accounts still has to be designed, tested and reconciled. A partner who cannot describe how loan and savings balances tie to general ledger totals at each period end, or how breaks are investigated, will leave your finance team with manual journals. Ask for the reconciliation reports and the owner of each control.
MariaDB or MySQL without justification
PostgreSQL is the database the Fineract README recommends, and MariaDB and MySQL are deprecated under FSIP-9. A partner who proposes either without a documented reason is either unfamiliar with the project's current direction or has accepted support risk without telling you. Ask which database they propose, the reason in writing, and how they will handle the upgrade path if the project's guidance changes.
No plan for read and batch sizing
The Fineract documentation describes one write instance, one batch instance and multiple read instances on database read replicas for high load. A bid that does not size these roles against your account volumes, end-of-day window and reporting load is guessing at capacity. Ask how Liquibase migrations are scheduled so they run only on write instances, and what load test results support the sizing.
No compliance evidence such as access logs
Rules such as the FTC Safeguards Rule require covered institutions to log the activity of authorized users and to run penetration tests and vulnerability assessments on a set cycle. A partner who does not plan for retained access logs, change records and test reports has not designed the evidence your examiners will ask for. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certifications. Question any partner who promises an audit outcome, and ask which independent auditor they expect you to use.
How to score partner responses
This table sets out eight criteria for scoring implementation partner answers to a Fineract RFP, with what a full-marks answer contains and what a failing answer looks like. Weights are left to the buyer, so assign them before reviewing responses. Use the failing column to spot answers that sound confident but offer no named deployments, documents or written scope.
| Criterion | What full marks look like | What a failing answer looks like |
|---|---|---|
| Production experience | Names specific Fineract deployments in production, the scale and tenancy model of each, and references you can verify under confidentiality terms | Describes Fineract in general terms, relies on demo environments or cites unnamed projects |
| Product and accounting method | Explains how loan and savings products are configured, how accounting rules map to the general ledger, and how changes are tested before go-live | Promises to customize everything without showing a product configuration, a chart of accounts mapping or a test approach |
| Front end and channels | States which front end is proposed (for example, Mifos X or a custom build against the REST APIs), who builds and supports it, and how channels authenticate | Assumes Fineract includes a user interface, or leaves the front end and channel integration unpriced and unscoped |
| Payments and KYC design | Describes how payment rails and KYC providers connect, where customer and KYC documents are stored, and how data flows are logged and reconciled | Offers a vendor list without data flow diagrams, storage location or reconciliation design |
| Instance sizing and testing | Explains how read, write and batch instances are sized, how read replicas are used, how batch windows are scheduled and how load tests are run | Gives one generic server specification with no link to transaction volumes, batch timing or peak load |
| Release adoption | Describes how the quarterly Fineract releases are assessed, tested in a staging environment, and rolled out, with a clear rule for end-of-life versions | Says upgrades will be handled when needed, with no test cycle, rollback path or version policy |
| Security and evidence | Maps controls to the buyer's obligations, names the logs, access records and penetration test reports produced, and states who holds the evidence | Lists security features without evidence, or treats compliance as the buyer's responsibility without offering help |
| Commercial clarity in a written fixed scope | Provides a written scope with deliverables, assumptions, exclusions, acceptance criteria and a clear list of ongoing support items | Quotes time and materials with open-ended scope, or leaves exclusions and ownership of the production system undefined |
What buyers ask before hiring outside help for Fineract
The license fee is not the cost driver. Apache Fineract is licensed under the Apache License 2.0, so the cost of a self-hosted core sits in work and running services. Ask a partner to price product configuration (loan, savings and deposit products, accounting rules and fee schedules), front-end and integration build (channels, payment and card connections, KYC data flows, regulator reporting), the infrastructure in your own environment, test cycles and migration rehearsals, and ongoing support and upgrades. Ask which items are one-time and which recur, and whether each is fixed-scope or time-and-materials. The Fineract README warns that a production deployment can be complex, costly and time-consuming, so a quote without these lines is incomplete. Request a written scope before any estimate of duration.
Duration depends on scope: how many products you launch, whether you migrate existing portfolios, how many integrations sit on the critical path, and how many tenants you configure. Ask the partner to show which of these drivers their estimate assumes and what changes if one of them grows. Your own inputs will move the schedule as much as the build. Business owners must approve product rules, accounting sign-off must confirm the general ledger mapping, test data must be representative of real clients and loans, and change approvals must be scheduled before test and cutover windows. Ask the partner to name who on your side signs each of these, and how many days each sign-off is expected to take.
Whether your team can do this alone is a question of skills and capacity, not of licensing. Skilled engineers can run a Fineract project in-house, but the Fineract README states that the project does not provide a comprehensive production deployment guide and that organizations may pay a vendor for deployment and maintenance. Confirm that your staff have covered database operations on PostgreSQL, Kubernetes or your chosen hosting, batch scheduling, backup and restoration, and accounting configuration, and that they can staff the work through testing and cutover. If any of these gaps exist, ask the partner to price the training or pair-working that closes them and to state which parts of the build they would hand back to you.
How DeployOpen scopes, delivers and supports Fineract evaluations
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For core banking RFP questions, we start from a written scope covering Fineract configuration, integrations and operating model, so that bidders and evaluators compare answers against the same deliverables.
How we scope
- Written scope agreed before work starts, covering products, tenants, channels and accounting rules
- Confirmation of the production Fineract deployments and operating model we would reference in our answers
- Defined list of payment, KYC and reporting integrations, with owners and data flows documented
How we build
- Product and accounting configuration built against your general ledger mapping and tested with sample loan and savings accounts
- Read, write and batch instance layout designed in your environment, with PostgreSQL as the database platform
- Security testing of APIs and integrations, with results tracked against the agreed scope
How we hand over
- Architecture, configuration and runbook documentation delivered for your internal teams and auditors
- Evidence packs for change approval, access control and backup tests prepared for compliance assessments
- Knowledge transfer sessions covering quarterly Fineract release adoption and batch job operations
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Quarterly Fineract release reviews scoped in writing, including regression testing against your configuration
- Support scope, response expectations and service levels agreed in the retainer, not assumed from this page
