Loan management system RFP questions for open source lending partners
A lender or credit union choosing a self-hosted loan management system on Apache Fineract with Mifos X or Frappe Lending needs a partner who can configure, migrate, integrate and support it, and this section gives that buyer a neutral question set grouped by area, with what good answers contain and the red flags to watch for. The questions apply whichever platform you choose, because the partner's ability to deliver the product configuration, portfolio migration, front end, bureau and payment integrations, security controls and support terms matters more than the brand. The Apache Fineract platform documentation is a useful reference for checking whether a bidder understands the headless architecture, multi-tenancy and instance design they describe.
Fineract's README warns that a production deployment can be complex, costly and time-consuming, that the project does not provide a comprehensive production deployment guide, and that organizations may pay a vendor for deployment and maintenance. That warning is the reason vendor questions carry so much weight. Run the evaluation in three steps. First, collect written responses to the full question set, and ask each bidder to name the people who will do the work and the engagements they have delivered on comparable products. Second, hold a scripted demo on your own products, such as a loan product with your interest method, fee rules and repayment schedule, and ask the bidder to configure it live or in a sandbox. Third, run reference calls with former clients and ask about migration defects, upgrade effort and how the partner handled incidents. Score answers against the same rubric so that the decision rests on evidence you can defend.
Questions to ask by area: product configuration, migration, front end, integrations, security and support
How much hands-on experience does a partner have configuring Fineract loan products and interest methods?
Ask for named projects where the partner configured loan products, interest calculation methods, repayment schedules and business rules in Apache Fineract or Frappe Lending, and ask which parts were configuration and which needed code. A strong answer lists the product types covered (for example, declining balance, flat rate, grace periods, moratorium rules), explains how each was tested against expected schedules, and says who signed off the outputs. Ask how changes to products are versioned and approved after go-live. Fineract is configurable through its APIs and product settings, so ask the partner to show where configuration stops and custom development starts. Request a sample test pack of schedule calculations so you can judge the rigor yourself.
What does a portfolio migration plan need to cover before cutover?
A credible plan covers data mapping from the legacy system to the new loan, client and accounting structures, a reconciliation method that proves balances, schedules and arrears match at the record level, a defined cutover window, and a parallel run period. Ask how the partner maps legacy loan statuses, interest accruals and collateral fields, and who approves each mapping rule. Ask for the reconciliation report template and the criteria for a go or no-go decision. Ask how rollback works if a reconciliation difference appears after cutover. Migration effort depends on data quality, the number of legacy systems and how much history must be carried over, so ask the partner to list those drivers in its estimate rather than give a single figure.
Should we build a custom front end or use Mifos X with Fineract?
Fineract is a headless application with REST APIs and does not include its own user interface, so you must choose a front end. Mifos X is the web application the Fineract README uses in its Kubernetes example, and it suits staff workflows for loan officers and administrators. A custom front end suits borrower portals, embedded origination or a distinct user experience, but it adds design, build and security testing work that recurs with every change. Ask the partner which option it recommends for each user group, how it handles authentication and session security in both cases, and how it keeps UI code aligned with Fineract API upgrades. Ask for a list of screens in scope and the effort split between configuration and development.
How do credit bureau and payment connectors get built, and who maintains them?
Ask whether each bureau and payment connector is built new, customized from an existing module, or provided by a vendor, and who owns the code after handover. A good answer names each provider, the data elements exchanged, how requests and responses are logged, and how webhooks are verified, retried and reconciled against ledger postings. Ask how the partner handles bureau consent records, payment failures, duplicate webhook delivery and reversals. Confirm which vendor APIs the partner has used before and whether it has test or sandbox access for each provider. Request the connector maintenance plan, because provider API changes are a recurring cost that the quote should show separately.
Which security controls will the partner implement and evidence for a lender?
A lender that is covered by the FTC Safeguards Rule (16 CFR 314.4) should expect the partner to address encryption in transit over external networks and at rest, multi-factor authentication for anyone accessing an information system, documented change management, and logging of authorized user activity. Ask how each control is configured in your Fineract or Frappe Lending environment, where the logs are stored, how long they are kept, and who reviews them. Ask about penetration testing and vulnerability assessment cadence, since 16 CFR 314.4(d)(2) requires annual penetration testing and vulnerability assessments at least every six months unless continuous monitoring is in place. Ask the partner to show the evidence it would deliver, not just the controls it intends to use. DeployOpen prepares controls and evidence for assessments but does not issue audit reports or certifications.
Does the lending system need records retention beyond the standard schedule?
Records retention only follows SEC Rule 17a-4(b) where the business is a broker-dealer or otherwise falls in that scope, and a loan platform usually is not. For broker-dealer scope, the rule requires 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. Ask the partner to confirm whether the rule applies to your entities, which records the system must hold and in what format, and how retention periods and deletion are configured. For a non-broker lender, ask instead for the retention schedule that your counsel and compliance team set, and how the partner would enforce it in the database, backups and archives.
How will the partner handle Fineract upgrades against quarterly releases?
Fineract publishes official releases quarterly, at the end of each quarter, under the ASF release policy, and it archives end-of-life releases. Ask the partner how it tracks releases, tests each upgrade in a non-production environment, and handles database migrations, since Liquibase migrations run only on write instances. Ask what happens when your running version reaches end of life, and who decides when to upgrade. Ask whether upgrades are included in a fixed-scope engagement or sit in a retainer, and what support hours and response targets apply. Confirm every SLA in writing, because the partner should commit to response and restoration times in the contract, not in a sales deck. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and agrees scope and deliverables in writing before work starts.
How the answers differ for microfinance, fintech and Safeguards-covered lenders
Microfinance institutions and credit unions usually run group lending, field officer visits and savings linked to loans. Apache Fineract provides the core ledger and product engine, and Mifos X is the web application most often paired with it for these workflows. The RFP should therefore test whether a partner has configured group products, meeting-based collections and savings-to-loan links in a live deployment, not only in a demo. Small IT teams also need to know who patches, backs up and upgrades the stack after go-live.
- Group and product configuration: Ask for examples of group loan products with joint liability, repayment schedules and interest methods configured in a production-like tenant, and how changes are tested before release.
- Field officer workflows: Ask how officers capture repayments offline or in low connectivity areas, how collections are reconciled to the core, and which Mifos X screens they use.
- Savings linked to loans: Request the configuration for compulsory and voluntary savings, and how withdrawals interact with outstanding loan balances.
- Hosting for small teams: Ask for the operating model for a small IT group, including the runbook, backup restore tests and who holds on-call duty.
Request a sample configuration export, a restore test record and a reference from a comparable tenant that the bidder can describe without naming clients you cannot verify. Confirm each claim against your own product list before scoring.
Fintech lenders typically build origination in their own application and call Fineract or Frappe Lending through APIs, with decisioning kept outside the core. Their RFP questions focus on integration design, payment collection through external providers and how the system scales. Fineract is headless with REST APIs, and its documentation describes read, write and batch instance types set by environment variables, with one write instance, one batch instance and multiple read instances on database read replicas recommended for high load. Bidders should explain how they size and test that topology.
- API-first origination: Ask how the partner maps your application flow to Fineract endpoints, handles retries and idempotency, and keeps decisioning logic outside the core.
- Payment collection: Ask which payment providers have been connected, how repayment webhooks are validated and reconciled to the ledger, and how failed collections are reported. An orchestration layer such as Hyperswitch can be evaluated here if you use one.
- Read and write instance scaling: Ask how Liquibase migrations are scheduled, given that they run only on write instances, and whether the bidder uses the liquibase-only Spring profile on Kubernetes.
- Tenant and data isolation: Confirm how the Fineract-Platform-TenantId header is handled for each product line or partner.
Request load test results with the stated instance layout, a migration runbook and a sample integration test suite. Ask for the observed behavior during a failed write instance, and treat any answer without evidence as unverified.
Non-bank lenders covered by the FTC Safeguards Rule must meet specific controls under 16 CFR 314.4. The rule requires encryption of customer information in transit over external networks and at rest, multi-factor authentication for any individual accessing any information system, change management procedures and logging of authorized user activity. Where continuous monitoring is not in place, it also requires annual penetration testing and vulnerability assessments at least every six months. The RFP should ask bidders to show how each control is implemented and evidenced in the self-hosted stack, not only described in a proposal.
- Encryption: Ask for the TLS configuration for external traffic, the database encryption method at rest, and where keys are stored and rotated.
- MFA and access: Request the MFA design for staff, administrators and service accounts, and how privileged access is granted and removed.
- Logging and change management: Ask which user activity is logged, where logs are retained, and how each production change is approved, tested and recorded.
- Testing cadence: Ask whether the bidder proposes continuous monitoring or the six-month penetration test and vulnerability assessment cycle, and who performs each test.
Request a sample control matrix mapped to the rule, a recent test report summary with remediation status, and a log extract showing user activity. Confirm with your own counsel how the rule applies to your entity before scoring these answers.
Vendor answers that should worry you
A partner bid for a self-hosted lending platform is only as good as the specifics behind it. The answers below sound plausible in a proposal but usually hide missing experience, untested integrations or terms nobody has committed to in writing. Use them to press for evidence before scoring.
No named interest and schedule work
If a bidder cannot name a project where they configured interest methods, amortization schedules, grace periods and fee rules on Apache Fineract or Frappe Lending, the product is untested for your books. Ask for the product types they have configured, who built the repayment schedule logic, and how they checked schedules against a sample of hand-calculated loans. Requests for a named reference are reasonable, and so is a written test plan.
Migration plan without reconciliation
A plan that moves loans, balances and schedules into the new system but never says how each balance is proven is a plan for finding errors after go-live. Ask who signs off the opening balances, which totals are compared between the legacy and new systems, and how payments received during cutover are handled. The reconciliation step should be in the plan with an owner, a tolerance and a rollback point.
Front end included without a name
Fineract is headless and ships with REST APIs but no user interface of its own, so a claim that the front end is included needs a product name, a version and a licence. Ask which web application the bid means, whether it is Mifos X or a custom build, who maintains it after handover, and which staff roles and borrower channels it covers. Vague wording here often hides a custom build the bid has not priced.
Integrations called standard
Credit bureau, payment, KYC and general ledger connections differ in their message formats, authentication and error handling, so calling them standard without evidence is a warning sign. Ask for a test log from a sandbox or a recorded run against each provider, the error and retry behavior they tested, and who holds the provider credentials. A bidder who has done this work can show the test cases.
Security deferred to the client
Encryption at rest and in transit, multi-factor authentication for staff and admins, activity logging and change management are controls the FTC Safeguards Rule expects a covered institution to have in place. A bid that answers each one with "the client decides" has not designed the system. Ask which controls the bidder implements, which they document for you, and which they only advise on, and request the penetration testing plan with its cadence.
Support terms not stated in writing
Response times, severity levels, upgrade handling, backup responsibility and who is on call after go-live must appear in the contract, not in a sales call. Ask for written support terms with named hours, escalation paths, and what happens when a Fineract quarterly release or a security patch arrives. Fixed-scope work that ends at handover should say what the retainer covers once it does.
How to score partner responses
This table lists six weighted criteria for judging written partner answers on a Fineract or Frappe Lending bid, with what a high, medium and low answer looks like. Score the written responses before any demo, so presentation polish does not outweigh evidence, and treat the weights as a starting point to adjust to your own risk profile.
| Criterion | High score looks like | Medium score looks like | Low score looks like |
|---|---|---|---|
| Configuration depth (weight: high) | Names live Fineract or Frappe Lending deployments, describes how loan products, interest methods and fees were configured, and explains which rules were changed in code versus in configuration | Describes product setup in general terms, cites one or two projects without detail, and does not separate configuration from customization | Relies on the platform's marketing description, cannot name an interest method or product type it has configured, or promises custom work without a scope |
| Migration method (weight: high) | Explains how existing loan balances, schedules, collateral and client records are mapped, reconciled to the legacy ledger and signed off, with a dry-run and cutover plan | Describes a migration approach but leaves reconciliation, cutover timing or rollback vague | Offers to 'import the data' without a mapping approach, reconciliation step or rollback plan |
| Integration evidence (weight: medium) | Shows working credit bureau, payment and accounting integrations, with interface specifications, error handling and test results the client can review | Lists integrations as available but supplies limited technical detail or sample interface documents | Lists integrations without naming the systems, or defers all integration design until after contract signature |
| Security controls (weight: high) | Maps encryption in transit and at rest, MFA for staff and admins, audit logging and change management to the client's controls, and offers to support the testing the client's regulator expects | Covers some controls and states others will be handled later, with limited evidence of how they are verified | Answers security questions with general assurances and no control mapping, logging design or testing approach |
| Support terms (weight: medium) | States in writing the scope of support, upgrade and patch responsibilities, response expectations and the handover of documentation, all tied to the agreed scope | Describes support in general terms and leaves response expectations or upgrade responsibility to later discussion | Offers support without written terms, or does not say who applies upstream releases and security fixes |
| References (weight: medium) | Provides named or anonymized references for comparable lending deployments that the client can verify through a reference call | Provides references for adjacent work, such as ERP or general infrastructure, with limited lending overlap | Declines to provide references or offers only unverifiable testimonials |
What to confirm with the partner before signing
Before signing, get the partner to state in writing which Apache Fineract release line they will deliver and why. Fineract 1.15.0 is the current stable release as of the supplied facts, and the project publishes official releases quarterly, at the end of each quarter, with end-of-life releases archived. Ask how the partner will move you from one quarterly release to the next, how long they will support a given line, and who applies the upgrade, test and rollback work. Confirm the database as well. The Fineract README recommends PostgreSQL and deprecates MariaDB and MySQL under FSIP-9, so a proposal that uses MySQL or MariaDB needs a written justification and a clear owner for the deviation.
Ask for a license and connector register that lists every component in the proposed stack with its license and source. Fineract is licensed under Apache-2.0, but the front end, the reporting tools, the payment connectors and any bureau or KYC adapters may carry different terms, and some vendors offer commercial editions with separate features. Require the partner to name each third-party connector, the version it targets, who maintains it, and whether it is custom code the partner will support after handover. Confirm which items are excluded from the fixed price, such as paid connector licenses or vendor API fees, so they do not appear later as surprise costs.
Write every answer into the statement of work. DeployOpen engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so a verbal assurance about release lines, database choice or connector support has no contractual weight. Attach the release line, database, upgrade policy, connector list and support responsibilities as named deliverables, and state which party is responsible for each. Where a question cannot be answered yet, record it as an open item with an owner and a decision date rather than leaving it implied. Ask for the same confirmations again at the point of signature, since the release line in a proposal can move before work begins.
How to run the evaluation from RFP to contract
This sequence turns a list of written questions into a signed agreement that a lending team can hold a partner to. Each step produces a record the evaluation committee can compare across bidders, so the final choice rests on evidence rather than presentations.
Issue the written questions with requirements attached
The evaluation lead, usually a head of lending operations or the CTO's delegate, sends the RFP questions to each shortlisted partner together with your requirements document. That document should list the products and interest methods, repayment and collections rules, accounting needs, reporting obligations and the integrations you expect, such as credit bureau and payment connections. Ask each bidder to answer in writing against the same numbered list. The step is done when every bidder has acknowledged receipt and the question set is version-controlled so later answers can be traced to the exact wording they responded to.
Collect and score written responses
Bidders return written answers, and your evaluation panel scores each answer against a common rubric covering product configuration experience, portfolio migration method, front end choice, security controls and support terms. Security, compliance and lending operations should each score their own sections so no single reviewer carries the whole evaluation. Ask for named examples of comparable lending deployments and for the Fineract or Frappe Lending version each bidder proposes to build on. The step closes when each bidder has a written score sheet and the panel has listed the gaps that a demo or reference call must resolve.
Run a scripted demo on a sample loan product
Give each shortlisted partner the same sample loan product, written as an illustrative case with a fixed interest method, fee schedule, repayment frequency and one delinquency scenario. The partner configures or demonstrates the product in a test environment while your team follows a script that covers origination, disbursement, a repayment schedule, a missed payment and the resulting accounting entries. Record which steps are configured, which need custom work and which the partner could not show. The step is done when the panel holds a dated log of demonstrated behaviour, with any unproven item carried into the contract as a deliverable to confirm.
Check two or three lending references
Ask each remaining partner for two or three references from lending clients that run a self-hosted open source loan system, and confirm that at least one reference covers a production migration and one covers ongoing support. Your panel should prepare the same questions for each call, covering how long go-live took against the agreed plan, how change requests were handled, how incidents were reported and how the partner handled data migration defects. Ask the reference whether they would hire the partner again for the same scope. The step is done when the panel has written notes from each call and has checked whether the reference's environment resembles yours.
Negotiate scope, deliverables and support into a written agreement
Legal, procurement and the evaluation lead convert the winning response into a fixed-scope agreement. The document should define the products in scope, the migration deliverables and acceptance tests, the security controls and evidence the partner will provide, the change control process, the support hours and escalation path, and the handover of documentation and backups. Confirm in writing who pays for third-party licenses, hosting and any retained support after go-live. The step is complete when both parties have signed a statement of work that maps every open item from the demo and reference checks to a named deliverable or a documented exclusion.
What buyers ask before hiring outside help for a lending implementation
The first question most buyers ask is whether their own team can run a self-hosted lending platform without outside help. The honest answer depends on whether they already operate PostgreSQL, Kubernetes or equivalent container platforms, and whether they have someone who can read the Fineract REST API and its configurable products and business rules. Apache Fineract is headless and does not ship its own user interface, and the project's 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. Buyers should map their in-house skills against those gaps before comparing partner quotes, and ask each bidder which parts of the work they would hand back to the client's staff.
Partner labor is usually the largest one-time cost, and it moves with the number of loan products, repayment schedules, integrations, data migration sources and compliance deliverables in the written scope. Infrastructure, backups and monitoring recur every month, and their size depends on the number of read and write instances and the database layout the buyer chooses. Compliance evidence, such as access reviews, change records and penetration test reports, is priced separately by most providers and recurs each cycle. Support and upgrades are typically a retainer. Ask each bidder to split the quote into one-time and recurring lines, name the assumptions behind each line, and state which items depend on the buyer's own environment.
Timing follows scope more than platform choice. A narrow pilot with one product line, one funding source and a single accounting export can be planned in a much shorter window than a full origination, servicing and collections rollout with credit bureau, payment and general ledger integrations. The buyer's team sets the pace: product owners must sign off on interest methods and fee rules, data owners must validate the portfolio extract, and security reviewers must approve role design and logging before go-live. Illustrative example: a lender that delays sign-off on fee rules for three weeks will push back the migration test cycle by the same amount, even if the partner's own work is on schedule. Ask bidders for a milestone plan that names the client decisions each milestone depends on.
How DeployOpen scopes, delivers and supports lending implementations
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a lending RFP, we turn the questions in this guide into a written scope that names the platform, products, integrations and evidence before any work starts.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists loan products, interest methods, integrations and migration sources named in your RFP answers.
- We confirm which platform version, database and front end the scope covers, so bidders compare the same baseline.
How we build
- We configure loan products and business rules on the agreed platform, then test them against your signed-off test cases.
- Portfolio migration is run in trial loads that reconcile balances, schedules and client records before cutover.
- Payment, bureau and identity integrations are built in your environment, with credentials held in your own secrets store.
How we hand over
- Handover includes architecture, configuration, runbooks and the test evidence your auditors and examiners will request.
- Security controls are documented against the control areas in your scope, including encryption, MFA, logging and change management.
- Your staff are trained on administration, reporting and incident steps so the team can operate the system after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Retainers can cover platform upgrades, backup and restore checks, and periodic penetration testing and vulnerability assessments.
- Ask bidders to confirm response times, escalation paths and who holds the support contract, and put those terms in writing.
