Co-lending and loan transfers on open source loan software

It runs in the lender's own cloud account, data center or air-gapped network, so both the loan data and the database stay under the lender's control. The architecture is the same whichever platform you choose: an application tier, a relational database, background processing and a secure channel out to each partner. Where the two institutions are separate legal entities, decide early which one hosts the shared book and how the other gets read access. That decision drives network design, access logging and who is responsible for backups. Confirm the hosting location with your compliance team before design starts, since data residency rules can limit where partner data may sit.

Apache Fineract should run on PostgreSQL, which the project's README names as the recommended database. The README also states that MariaDB and MySQL are deprecated under proposal FSIP-9, and the official Docker image ships only the PostgreSQL JDBC driver. For a shared book, plan for a write instance, a batch instance and read instances on database read replicas, so partner reporting does not compete with servicing writes. Liquibase migrations run only on write instances, so schedule them as a separate step during upgrades. Confirm the instance layout with your implementation partner against your expected load.

The frappe_docker repository provides production images and Compose files for ERPNext and other Frappe apps, including Frappe Lending, with services for MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx. Split repayment jobs, interest accruals and partner statements run through the background workers and scheduler, so their capacity and failure alerts matter as much as the web tier. The single-file demo setup is marked for short-lived evaluation only and should not carry a live shared book. Confirm the exact services and versions you need against the current repository before you commit to a design.

Frappe Cloud public shared benches do not allow Server Scripts, and Server Scripts are disabled by default from version 15 onward unless the server_script_enabled setting is turned on. Any custom split logic, such as a partner-specific repayment waterfall, therefore needs either a private bench you control or a custom app deployed with the code under your change management process. Server Scripts also run Python on document events, which makes them easy to start with and harder to audit at scale. Decide where split rules live before you pick the hosting option, because this choice can rule out a managed setup.

Borrower payments arrive through a payment provider or bank rail, and the lending system matches each receipt to a loan and allocates it according to the agreed split. The integration must handle partial payments, reversals, failed collections and late postings, because a mismatch between the collected amount and the allocated amount creates a reconciliation break for both lenders. Collections data should be reconciled daily against the bank statement. Ask any partner to show how it matches receipts, how it treats returned payments, and which system holds the authoritative record of each allocation.

Each lender needs its own ledger entries for its share of principal, interest, fees and write-offs, posted from the loan system into the general ledger of the entity that owns the asset. Shared-book activity should carry a partner or entity dimension so each side can close its books independently. Fineract offers real-time integrated accounting, and Frappe Lending connects to ERPNext accounting, but the mapping from loan events to chart-of-accounts codes is custom work for most co-lending models. Agree the posting rules, cut-off times and reversal handling with both finance teams before go-live.

A secure partner reporting channel should give each institution read access only to the loans it funds or services, through scoped reports or an API that filters by partner. Use encrypted transport, individual credentials with multi-factor authentication, and access logs that record who pulled which report and when. Scheduled file drops to an SFTP location or a read-only reporting database are common alternatives to live API access, and each one needs its own retention and deletion rules. Confirm the channel design with your security team and check which records each partner must keep under its own retention obligations.

The lender that operates the shared book typically owns the platform, its hosting, the split logic and the reporting channel, while each partner owns its own ledger and its own access controls. An implementation partner such as DeployOpen can plan, implement, integrate, harden and document the self-hosted deployment within a fixed scope agreed in writing before work starts. Ongoing upgrades, backups and support are usually handled under a separate retainer. Ask any partner to state in writing which systems, interfaces and runbooks it delivers and which remain with your team.

The main drivers are the number of lending partners, how complex the split rules are, how many loans are already in servicing, and whether Apache Fineract needs custom work for the same model. Each partner adds its own funding terms, reporting formats, sign-off steps and accounting entries. Splitting principal, interest, fees and late charges by percentage is straightforward; splitting by tranche, by loan age or by performance trigger takes more design and more testing. Loans already in servicing add a migration and reconciliation workload that new originations do not. Ask any partner to price each of these drivers separately so you can see which ones move the total.

Duration depends on the scope you agree in writing before work starts, not on a standard timeline. A rollout limited to Frappe Lending with one partner, a single split rule and new originations is much smaller than one covering several partners, reporting packs and a book of existing loans. DeployOpen does not publish durations, so ask for a phased plan that shows design sign-off, configuration, data migration, partner reporting and parallel testing as separate milestones. Each milestone should name the inputs it needs from you and the acceptance test that closes it.

The work needs signed commercial rules, test data and written sign-offs from each partner. The signed rules should define the split for principal, interest, fees and penalties, who owns collections on delinquent loans, how a transfer is triggered and what happens on early repayment or default. Test data should include realistic loan files, repayment histories and a set of edge cases such as partial payments and reversals. Partner sign-offs cover reporting formats, reconciliation cut-off times and the accounting treatment each institution expects. Without these inputs, configuration tends to be rebuilt during testing.

An internal team can do it if it already runs the platform in production and has engineers who understand the lending product model, the accounting integration and the database. The skills most often missing are product configuration experience, testing of split and transfer logic, and partner reporting design. Frappe Lending is configured through the ERPNext-style desk and Server Scripts, which are disabled by default from version 15 and must be enabled with the server_script_enabled setting, so confirm how your team will govern custom logic. Fineract is headless and needs custom Java work for models it does not support out of the box. Many lenders split the work: internal staff own the business rules and operations, and an implementation partner handles configuration, testing and hardening.

DeployOpen does not publish a price list. Most engagements are fixed-scope, meaning scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Ask for the quote to separate one-time work (requirements, configuration, custom development, data migration, testing, documentation and training) from recurring work (hosting, upgrades, monitoring and support). Ask which items depend on the number of partners, the number of loans in migration and the Fineract customizations you choose. Ongoing support, upgrades and continuous testing are available as retainers, and those should be priced as a separate line.

Both Frappe Lending on ERPNext and Apache Fineract are open source, so the platform itself carries no license fee. ERPNext is licensed under GPL-3.0 and the Frappe Framework under MIT, and Fineract is licensed under Apache-2.0. Self-hosting ERPNext is free according to its pricing page, and Frappe Cloud hosting starts at a published monthly rate, though that rate is not a Frappe Lending figure. The costs that remain are your cloud or data center infrastructure, database operations, backups, monitoring and staff time. For Fineract, the project's own README warns that production deployment can be complex, costly and time-consuming, so budget for hosting and operations as a recurring line. Confirm sizing with your infrastructure team against your expected loan volume.

A co-lending implementation should produce evidence that the split and transfer logic works as agreed, that access and changes are controlled, and that partner reports reconcile to the ledger. Under the FTC Safeguards Rule at 16 CFR 314.4, covered lenders must encrypt customer information, apply multi-factor authentication, adopt change management and log authorized user activity, so keep change records for split rules and configuration. Where continuous monitoring is absent, the rule calls for penetration testing and vulnerability assessments at least every six months. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the audit reports. Confirm with your counsel which record-keeping obligations apply to your partners' books.

The contract should cover scope, deliverables, acceptance criteria, responsibilities for each partner and the process for changes. Specify which split rules are in scope, which partners and products are covered, how many loans are migrated, and which reports each partner receives. Ask for named acceptance tests that prove split accuracy on sample loans, reconciliation of partner balances to the ledger, and reversal handling. Clarify who owns the signed rules after go-live, how post-launch changes are priced and how defects found in parallel running are handled. Ask whether ongoing support, upgrades and testing are part of a retainer and what that retainer covers.