Open source loan management for fintech lenders: why an API-first build changes the work
A fintech lender that owns its borrower app and wants the lending core behind it can use Apache Fineract, which is headless, exposes REST APIs, is licensed under Apache-2.0, and had 1.15.0 as its current stable release. Frappe Lending is the other open source option to evaluate, and it fits the same pattern when the front end is yours. Because Fineract does not ship its own user interface, your product team builds the origination flow, applicant journeys and servicing screens in your own app and calls the core through its APIs. That choice moves much of the design work from configuring a vendor screen to deciding which system owns each step.
The lending core is not the whole system. Credit decisioning usually runs outside the core, in a rules engine or scoring service that returns a decision and reasons that the core records. Repayments are collected through payment providers, so your team must decide where card or bank account data lives and how payment events post back as loan transactions. Accounting entries, KYC documents and adverse action or disclosure records also sit around the core, and US and EU obligations such as the FTC Safeguards Rule and GDPR Article 28 contracts apply to every one of those components, not only to Fineract.
Before selecting a platform, confirm three things in writing: which system is the source of truth for each loan state, how each external service is authenticated and logged, and who operates the read and write instances. Fineract's documentation recommends one write instance, one batch instance and multiple read instances on database read replicas for high load, with Liquibase migrations running only on write instances. Ask your implementation partner to show how these instance types map to your traffic, and to document the evidence trail between your app, the decisioning service, the payment provider and the core.
Which requirements a self-hosted lending stack must meet and what each means for the build
This table maps the US and EU requirements that most often apply to a self-hosted lending stack to what each one asks the build to do. Read each row as a requirement, then the build consequence, then the evidence to prepare. Applicability depends on your licensing status, your customer footprint and whether your providers are in scope, so confirm those points with counsel before you scope the work.
| Requirement | What it means for the build | Evidence to prepare |
|---|---|---|
| FTC Safeguards Rule encryption, MFA, change management and activity logging (16 CFR 314.4) | Encrypt borrower data in transit over external networks and at rest, enforce MFA for every person who reaches Fineract or Frappe Lending admin, database or hosting consoles, and log activity of authorized users. | Encryption configuration for TLS and database storage, MFA enforcement settings, change records for product and rule changes, and log retention settings. |
| Penetration testing and vulnerability assessments (16 CFR 314.4(d)(2)) | Absent effective continuous monitoring, plan annual penetration tests and vulnerability assessments at least every six months across the lending APIs, the origination app and the hosting layer. | Dated test scopes, findings registers, remediation tickets and retest results covering the Fineract REST APIs and the front end you build. |
| GDPR Article 28(3) processor instructions and Article 32 security | Any hosting, support or deployment vendor that handles EU borrower data needs a contract limiting processing to documented instructions, including transfers, and requiring Article 32 security measures. | Signed processor terms, a sub-processor list, documented transfer locations and a description of technical measures for each vendor. |
| EU Data Act switching and on-premises exit (Articles 23, 25 and 50; no switching charges from 12 January 2027) | Where the Data Act applies to a data processing service you buy, keep loan, customer and accounting data exportable in standard formats so you can move to another provider or to on-premises infrastructure. | Documented export procedures for loan accounts, schedules, transactions and documents, a tested restore into a second environment, and contract clauses on notice and transitional periods. |
| NIS2 and Implementing Regulation (EU) 2024/2690 where the lender or its providers are in scope | Confirm whether your entity or its cloud, managed service or ICT providers fall within NIS2 scope. If they do, the Implementing Regulation sets the technical measures those providers must meet, which flows down into your hosting and support contracts. | A scope determination memo, a provider inventory with sector classification, and mapping of the Implementing Regulation measures to your hosting and operations controls. |
| Cyber Resilience Act for vendor-supplied software | Software you obtain from a vendor, including commercial add-ons, may need CRA conformity evidence and vulnerability handling from the supplier. Open-source components you modify or place on the market can shift obligations to you. | Supplier software bill of materials, vulnerability handling commitments, update and patch policy, and a record of which components you modified. |
How Fineract's read, write and batch instances shape a lending product
Fineract's documented model splits one deployment into instance roles, and each role changes what your lending product can safely do. The Fineract documentation describes read, write and batch instance types, set through environment variables. For high load, it recommends one write instance, one batch instance and multiple read instances pointed at database read replicas. Origination writes, disbursements, repayment postings and accounting entries belong on the write path. Balance inquiries, statements and portfolio views for your app or servicing staff can move to the read instances. Before you design the origination flow, confirm the instance layout your partner will deploy and which of your own endpoints call which instance.
Liquibase database migrations run only on write instances, so a rolling release that touches the schema depends on this rule. On Kubernetes, the liquibase-only Spring profile lets you run migrations as a separate step before the application pods start, which gives your change management process a discrete, reviewable migration job. Ask your partner to document the release order: migration job, write instance, batch instance, then read instances. Also confirm how lending products that run in batch, such as end-of-day accrual or delinquency aging, are scheduled against the single batch instance, since a slow batch run can delay the business day.
Fineract is multi-tenant. API requests carry a Fineract-Platform-TenantId header, and tenant connections come from a tenants database, according to the project README. For a fintech running several lending brands or regulated entities, this is the main isolation decision. Each tenant can hold its own products, offices and users, but shared instances and shared infrastructure still mean one upgrade cycle and one operational blast radius. Confirm with your compliance team whether separate entities need separate databases or separate deployments, and document how tenant selection is enforced at your gateway. Fineract's README recommends PostgreSQL as the database, and MariaDB and MySQL are deprecated under FSIP-9. Build your database standard, backup approach and read replica setup on PostgreSQL from the start.
Fineract or Frappe Lending: which platform fits which lending product
Apache Fineract and Frappe Lending solve different lending problems, and the adjacent components around them (payments, billing) are separate decisions with their own licenses and release cycles. The cards below set out what each option is for, what to verify before committing, and where to go next.
Apache Fineract for API-first portfolios
Fineract is a headless core banking platform licensed under Apache-2.0, with REST APIs and no user interface of its own. It fits lenders that build origination and borrower flows in their own application and need a multi-tenant back end for high-volume portfolios. The README warns that production deployment can be complex, costly and time-consuming, and the project does not provide a comprehensive production deployment guide. Budget for platform engineering skills and confirm that product configuration covers your interest methods and fee rules.
Mifos X as the front end
Fineract's own Kubernetes example uses Mifos X as the web application on top of the Fineract APIs, so it is the reference front end for staff workflows. Mifos X is a separate component with its own release cycle, so treat it as a design choice rather than a default. Confirm which screens your loan officers, collectors and administrators need, and whether your team will maintain customizations to Mifos X or build a custom front end against the APIs.
Frappe Lending for ERP-adjacent lenders
Frappe Lending is the choice for teams that already run, or plan to run, ERPNext and want lending records to sit next to accounting, customers and inventory. It is licensed under GPL-3.0 through the Frappe ecosystem. Co-lending and loan transfers are supported, which matters for partnership models where two institutions share a loan. Confirm the product configuration, repayment allocation and reporting you need in the current release, and read the co-lending topic before you scope a partner model.
Hyperswitch for payment routing
Hyperswitch is an Apache-2.0 composable payments platform that connects to multiple payment, payout, fraud, vault and tokenization providers, and it can be self-hosted. It sits outside the loan core and handles repayment collection, disbursement and payout routing. Your payment processors, PCI scope and data location decide whether it fits. Confirm which connectors your processors need and how repayment status returns to the loan record in Fineract or Frappe Lending.
Kill Bill for recurring billing
Kill Bill is an Apache-2.0 subscription billing and payments platform. It suits lenders with recurring fees, subscription products or usage-based charges that need a billing engine separate from the loan schedule. It does not replace amortization or loan accounting. Confirm how invoices and payment events are posted back to the loan ledger, and whether your fee model fits Kill Bill's catalog before you assign it a role in the stack.
Deployment patterns for write, read and batch instances in regulated hosting
Fineract separates work by instance type, and each choice about where those instances run affects performance, change control and evidence. The cards below cover the decisions a lender makes before go-live and the checks to confirm with the vendor and in the lender's own environment.
Separate write and batch from read traffic
Fineract's documentation describes read, write and batch instance types set through environment variables, and recommends one write instance, one batch instance and multiple read instances for high load. For a lender, this means origination and servicing postings go to the write path, while scheduled jobs such as interest accrual and delinquency runs go to batch. Confirm with your implementation partner how job scheduling is pinned to the batch instance so the two never compete for the same resources.
Place read replicas for reporting
Collections dashboards, portfolio reports and borrower statements can run on read instances connected to database read replicas, which keeps reporting queries away from loan postings. Confirm the replication lag your lending operations can tolerate, because a collector who sees a payment ten minutes late will make a different call than one who sees it instantly. Ask the partner which screens are served from replicas and which must read from the primary.
Run Liquibase migrations in a window
According to the Fineract documentation, Liquibase database migrations run only on write instances, and on Kubernetes they can run separately with the liquibase-only Spring profile. Treat each upgrade as a controlled change: take a verified database backup, run migrations as a separate step, and record who approved it. Confirm the rollback path for each release with the vendor before scheduling the window, since a failed schema change on a loan book is hard to reverse.
Keep tenant configuration in the tenants database
Fineract is multi-tenant, with API requests carrying a Fineract-Platform-TenantId header and tenant connections configured from a tenants database. If you run separate tenants for subsidiaries, brands or test copies, the tenants database becomes a control point for who can reach which loan book. Ask how access to that database is restricted, how tenant changes are logged, and whether production and non-production tenants are kept apart at the network level.
Place PostgreSQL in your chosen region
The Fineract README names PostgreSQL as the recommended database and states that MariaDB and MySQL are deprecated under FSIP-9. Where the database sits decides where customer identity, KYC documents and repayment history are stored, which matters for data residency commitments and for GDPR processor terms in the EU. Confirm the region, backup location and the staff who can access the database before any borrower data is loaded.
Wire events to payments and the ledger
Repayment collection, disbursement and accounting entries depend on events reaching the payment provider and the general ledger reliably. Define which events trigger payment requests, which trigger journal postings, and how a failed delivery is retried without creating duplicate money movements. Ask the partner to show reconciliation reports that match the Fineract accounting entries against provider settlement files, and confirm the delivery guarantees of each integration in writing.
How a fintech lender rolls out a self-hosted lending core in phases
The sequence moves a lender from agreed scope to a production Fineract or Frappe Lending core in controlled stages, with a documented output and sign-off at each gate. Timing for every phase is set in the written scope before work starts.
Define scope and loan product rules
The lender and DeployOpen agree the products, interest methods, repayment schedules, fee rules, origination channels and integrations that the core must support, along with the decisioning and collections boundaries. The lender's compliance and finance leads sign off the product catalog and the list of systems in scope. This phase ends with a written scope document that fixes deliverables, acceptance criteria and timing. Confirm with the platform vendor and your own counsel which product features each option supports before committing to a platform.
Build the environment and security baseline
DeployOpen provisions the environments in your own cloud account, data center or air-gapped network, and configures PostgreSQL, TLS for data in transit, encryption at rest, multi-factor authentication for every staff and administrator login, centralized logging of user activity, and a change management procedure with approvals. These controls map to the FTC Safeguards Rule at 16 CFR 314.4, which requires encryption, MFA, change management and activity logging for covered financial institutions. The phase is complete when the baseline is deployed, the controls are tested in a non-production environment, and the evidence for each control is stored where your auditors can retrieve it.
Integrate origination and decisioning through APIs
Because Fineract is headless with REST APIs and no built-in user interface, the lender's application, identity verification and credit decisioning services are connected to the core through documented API calls. Decisioning runs in an external service, and the core records the outcome, the reasons and the loan status. Tenant headers and API access are configured per environment. The phase closes when test applications move end to end from submission to an approved or declined state, with each API call and response logged and reconciled to the decision record.
Connect repayment collection and accounting entries
The lender connects a payment provider for disbursements and repayments, and the core posts the resulting transactions to the general ledger through its integrated accounting. Finance teams confirm the chart of accounts mapping, the posting rules for interest, fees and charge-offs, and the reconciliation process between the payment provider settlement files and the ledger. The phase is done when a set of test repayments, reversals and disbursements produces ledger entries that finance has reviewed and matched to provider reports.
Run in parallel and migrate the portfolio
Existing loans are migrated into the new core through scripted extracts, transformation rules and load files, and each batch is reconciled against the source system for balances, schedules, interest and payment history. The legacy system and the new core run side by side for a period agreed in the scope so that servicing and collections results can be compared. The phase ends when the balance and schedule reconciliation shows no unexplained differences and the finance and operations leads have signed the reconciliation report.
Load test and cut over to production
The team runs load tests against the write, batch and read instances before go-live, following the Fineract guidance of one write instance, one batch instance and multiple read instances on database read replicas for high load. Liquibase migrations run on the write instance only. Read instances are added only after the test results show that query load is handled within agreed response targets. The cutover runbook, rollback steps and on-call roles are rehearsed. The phase closes when production traffic runs on the new core, the rollback plan has been tested, and the post-cutover checks pass.
Test penetration and vulnerabilities on a recurring cadence
DeployOpen runs application, API and infrastructure penetration tests before cutover and then at the cadence required by 16 CFR 314.4(d)(2), which calls for annual penetration testing and vulnerability assessments at least every six months unless continuous monitoring is in effect. Findings are tracked into the change management process and retested. The phase is recurring: the lender receives a dated test report and remediation record for each cycle, which become part of the evidence set. Confirm with your regulator and counsel how the cadence applies to your institution.
Evidence examiners and auditors ask for, and which component produces it
This table maps each evidence type that examiners, auditors and partner due diligence teams typically request to the part of a self-hosted Fineract or Frappe Lending stack that produces it. Read each row as a question to answer before go-live: who owns the record, where it lives and whether it survives a platform upgrade. DeployOpen prepares these records and controls for assessment, but independent auditors and certification bodies issue any attestation or certification.
| Evidence | Component that produces it | What to confirm before go-live |
|---|---|---|
| Access control and MFA records | Identity provider and directory, with role assignments mapped to Fineract tenant and office permissions | Export of MFA enrollment, admin role grants and periodic access reviews, with reviewer sign-off |
| Encryption in transit and at rest | TLS termination at the ingress or proxy layer, PostgreSQL and backup storage encryption settings, key management service records | Configuration exports, certificate inventory and key rotation logs for every environment |
| Change management tickets and deployment logs | Ticketing system linked to CI/CD pipeline, Liquibase changelog history on write instances, release records for each Fineract version | Approved change tickets matched to deployments, plus the Liquibase history table showing which schema changes ran and when |
| User activity logs | Fineract audit records for loan and client actions, reverse proxy and API gateway access logs, central log platform | Log retention period agreed with compliance, tamper protection on log storage and a tested query for a single borrower's activity |
| Penetration test and vulnerability reports | Independent or internal testing against the Fineract APIs, front end and hosting, with remediation tracking | Test scope covering the lending workflow and integrations, dated reports and closed findings with retest evidence |
| SOC 2 Type 1 versus Type 2 scope | Control descriptions and system description for the lending platform, evidence collected over the chosen observation period | Whether partners need a Type 1 point-in-time view or a Type 2 period of operating effectiveness, and which criteria categories apply |
| ISO/IEC 27001:2022 Annex A control mapping | Internal mapping of the 93 Annex A controls to owned systems, policies and records | Only an accredited certification body can certify conformance; DeployOpen prepares the mapping and evidence but does not certify |
How US and EU rules change the lending stack differently
A non-bank lender in the US usually falls under the FTC Safeguards Rule, so the lending stack has to show security controls that a reviewer can test. The rule is written as a set of required safeguards for customer information, and the build should produce evidence for each one rather than a policy document alone.
- Encryption of customer information: Borrower data must be encrypted in transit over external networks and at rest, including database volumes, backups and reporting exports. The build should document TLS settings and storage encryption for every Fineract or Frappe Lending component.
- Multi-factor authentication for all users: The requirement covers any individual who accesses an information system, so staff, administrators, support engineers and database access need MFA, not only borrower logins. Connect the admin console and servers to your identity provider.
- Change management and activity logs: Product configuration changes, business rule edits and admin actions need approval records and logs of authorized user activity. Centralize these logs and set a retention period that matches your policy.
- Testing cadence: Unless you run effective continuous monitoring, 16 CFR 314.4(d)(2) requires annual penetration testing and vulnerability assessments at least every six months. Schedule both and keep the reports and remediation tickets.
- Records and disclosure only where they apply: If the entity is a broker-dealer, SEC Rule 17a-4(b) requires preserving certain records for at least three years, the first two in an easily accessible place. Public companies must also describe cybersecurity risk management under Regulation S-K Item 106. Build retention and disclosure evidence only for the entities that fall under these rules.
Confirm with counsel which Safeguards Rule obligations and retention periods apply to your entity type, and whether any affiliate changes your broker-dealer or listing status.
An EU lender faces a different mix of obligations. GDPR governs how borrower data is processed, the Data Act governs how the lender can move away from a hosting or software provider, and NIS2 and the Cyber Resilience Act reach the providers and products in the supply chain. Each one changes the design, the contracts and the exit plan.
- Processor contracts under GDPR Article 28(3): Any hosting, managed service or support vendor that processes borrower data must act only on documented instructions, including for transfers, and apply the security measures required by Article 32. Keep a processing register that matches the signed contracts.
- Exit rights under the Data Act: Providers of data processing services must let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, switching charges are not permitted. Build export runbooks for loan, customer and ledger data, and test a full export before you need one.
- NIS2 and Implementing Regulation 2024/2690: Cloud, data center, managed and managed security service providers fall within the high-criticality sectors of NIS2 Annex I. Whether the lender itself is in scope depends on its classification, so confirm this. If your hosting or managed provider is in scope, Implementing Regulation (EU) 2024/2690 sets the technical measures it must meet, and you should ask for evidence.
- Cyber Resilience Act for vendor software: The CRA applies to software products from 11 December 2027, and its Article 14 reporting obligations have applied since 11 September 2026. Most products follow self-assessment under module A. Require commercial vendors to state their CRA route and vulnerability handling process, and confirm whether your own modifications would make your organization a manufacturer.
- Evidence in one place: Keep processor contracts, export test results and vulnerability handling records together so that supervisors and auditors can trace each obligation to a control.
Have counsel confirm the GDPR and Data Act contract language, and map every vendor to its NIS2 and CRA position before the build starts.
What to ask an implementation partner before a lending build
Start with production experience, because a Fineract deployment is not a lightweight install. Ask the partner which live Fineract installations they have operated, how many tenants those ran, and who held the on-call duty for upgrades. The Fineract README warns that production deployments can be complex, costly and time-consuming and that the project does not provide a comprehensive production deployment guide, so the partner's runbooks are part of what you are buying. Ask for the instance topology they propose: how many write instances, one batch instance and read instances on database read replicas, and where Liquibase migrations run. Then ask how they would migrate your existing loan book, including reconciliation of balances, schedules and accruals before cutover, and who signs off the result.
Next, test the integration design. Ask how origination decisions get made outside the core, which system holds the decision record, and how a declined applicant's reasons are stored so they can be retrieved later. Ask how repayment collection flows through the payment provider, whether webhooks post back into the loan ledger, and how failed or disputed payments are reversed. Confirm the controls the partner will apply to these interfaces and the change management process for them. On contracts, request the processor terms you will sign: under GDPR Article 28(3), the processor must act only on documented instructions, including for transfers, and must meet the Article 32 security obligations. For a non-bank lender in scope of the FTC Safeguards Rule, ask how the partner's work supports encryption, MFA for administrators and activity logging.
Finally, settle evidence and exit before signing. Ask what evidence the partner delivers at each stage: configuration baselines, access reviews, penetration test reports and change records, and in what format your auditors can use them. Clarify that the partner prepares evidence but does not issue audit opinions. For exit, the EU Data Act (Regulation (EU) 2023/2854) requires data processing providers to support switching to another provider or to on-premises infrastructure, with a two-month maximum notice period and a 30-day transitional period. Ask the partner to define in writing the export formats for loans, schedules, transactions and documents, and whether switching charges apply, noting that from 12 January 2027 such charges are prohibited under Article 29. Confirm these terms with counsel before the scope is agreed.
How much work, time and staffing does a self-hosted lending core take?
What drives the cost of a self-hosted lending core?
The biggest cost drivers are the scope of the lending products, the number of loan and savings products with their own interest methods and fee rules, the number of integrations with credit bureaus, payment providers and accounting, the compliance evidence you must produce, and where and how the platform is hosted. Each one adds design, build, testing and operating work. The open-source core carries no license fee for Apache Fineract (Apache-2.0) or Frappe Lending, so most of the spend goes to people and infrastructure: an implementation partner or internal engineers, cloud or data center capacity, and staff who run the system afterward. Ask any partner for a quote that breaks these items out separately against a written scope.
What is one-time cost and what recurs after go-live?
One-time costs cover discovery, product configuration, data migration, integration build, security hardening, testing and the first compliance evidence pack. Recurring costs cover hosting, database backups and disaster recovery testing, monitoring, patching and version upgrades, on-call support, periodic penetration testing and vulnerability assessments, and the people who own the product rules. Fineract releases are quarterly, according to its README, so every upgrade cycle needs regression testing of your own products. Ask a partner which items sit in the fixed-scope price and which move into a retainer.
Can an in-house team run a self-hosted lending core without an outside partner?
Some teams can, but the project needs skills in Java or Spring, PostgreSQL administration, Kubernetes or container operations, lending domain knowledge and security engineering at the same time. The Fineract README warns that production deployment can be complex, costly and time-consuming, and that the project does not provide a comprehensive production deployment guide. Many lenders therefore pay a vendor for deployment and maintenance. Assess your team against those skills, then decide which parts to keep in-house (product ownership, daily operations) and which to buy (initial build, hardening, upgrades, compliance evidence).
What does the lender need to provide during the project?
The lender must supply product owners who can state interest methods, fee rules, delinquency buckets and write-off policy in writing, a security owner who approves access controls and logging, and a data owner who can explain the source systems for customer and loan data. Migration work also needs a named person who can reconcile balances and sign off each cutover. Without these people, scope changes arrive late and the timeline moves, so confirm named roles and time commitments before signing a written scope.
How is the timeline set for a lending core implementation?
The timeline comes from the written scope, not from a generic duration. Scope defines the products, integrations, migration sources, environments, compliance deliverables and the acceptance tests that close each phase. Timing depends on how many products need configuration, how clean the legacy data is, how many external systems must be connected and how many approval cycles your credit and compliance teams require. Ask a partner for a plan with milestones, dependencies and the client decisions each milestone needs, and check whether the plan includes parallel test cycles for the accounting and repayment flows.
Is Apache Fineract or Frappe Lending cheaper to run?
Neither is cheaper by default, because the running cost depends on your product mix, team skills and hosting model. Fineract is a headless core with REST APIs that needs a separate front end, such as Mifos X, and its documented high-load pattern uses separate write, batch and read instances. Frappe Lending runs on the Frappe framework and ERPNext ecosystem, which may suit teams that already operate that stack. Compare the two on the skills you already have, the front end and integration work you must build, the number of instances you need at your volume, and the upgrade effort for your customizations. A proof of concept against your real product rules is the most reliable way to compare them.
What would switching away from a self-hosted core cost under the EU Data Act?
Under the EU Data Act (Regulation (EU) 2023/2854), data processing service providers must let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, providers may not impose switching charges at all, and until then reduced charges may not exceed costs directly linked to switching. Self-hosting in your own infrastructure avoids most vendor-side switching fees, but your own export, migration and testing effort remains. Ask any SaaS or hosting provider for its written switching terms and the data export format, and ask a partner how it would keep the data model portable.
How do retainers differ from fixed-scope projects?
A fixed-scope project has written deliverables, a defined timeline and an agreed price for a defined piece of work, such as building the origination flow, migrating a loan book or preparing a compliance evidence pack. A retainer covers ongoing work with no single finish line, such as upgrades, patching, backup testing, support, continuous testing and changes to products and integrations. Most lenders need both: a fixed-scope build to go live, then a retainer to keep the system current. DeployOpen plans and supports self-hosted platforms in the client's own infrastructure and offers retainers for ongoing support and upgrades, with quotes following from written scope.
How DeployOpen scopes, builds and supports a self-hosted lending stack
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a lending stack, that means the Fineract or Frappe Lending core, the API gateway that fronts origination, the decisioning service, the payment provider connections and the read and write instances all run in the lender's environment under the lender's control. Most engagements are fixed-scope: the scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Before quoting, expect the discussion to cover which products and interest methods are in scope, which origination channels call the APIs, which payment providers and credit bureaus are connected, and how the tenant model and accounting mappings will be set up. DeployOpen does not publish a price list, so the written scope is the document to compare across bidders.
Security work is scoped alongside the build rather than after it. DeployOpen runs security testing of applications and APIs, cloud and infrastructure, and AI systems and agents, which for a lender usually means testing the origination API, the admin consoles, the decisioning integration and the payment webhooks before go-live. Evidence preparation is also in scope: DeployOpen prepares systems, controls and records for compliance assessments, such as access logs, change records and backup restore tests, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask any partner to show, in the written scope, which evidence it will produce, in what format, and who owns the review of each item. Confirm which of these controls your regulator or auditor expects to see in its own words before you agree the deliverables.
Once the system is live, the cost of running it shifts to retainers for upgrades, patching and support. Fineract releases are published quarterly, and a lender should decide early who applies those upgrades, who tests them against its own products and who signs off on the change record. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which are separate from the initial fixed-scope build. Ask each partner to state in writing the response expectations, the upgrade cadence, how backups are restored and tested, and whether the retainer covers the Mifos X front end, the database and the infrastructure or only the application layer. Confirm these terms against your own service requirements before signing, since DeployOpen will only commit to what the written agreement says.
