Why Apache Fineract fits an NBFC's loan ledger and where it stops
Yes, Apache Fineract can serve as the loan and accounting ledger for a non-bank lender, provided the build is planned as a core system project rather than a software install. Fineract holds client records and KYC documents, manages loan and savings portfolios, and posts to a real-time integrated accounting ledger. It is also headless: it exposes REST APIs and has no user interface of its own. Your loan officers, collections staff, credit committee and inspectors will need a front end, reporting layer and document workflow built or chosen separately. The project's documentation points to the Mifos X web application as one front end, and that choice belongs in the design phase.
The NBFC situation is demanding. The loan book must be classified by overdue days, provisioned, and presented to inspectors with evidence that approvals and changes were controlled. Fineract supplies the transaction and accounting base for that work, but the classification rules, provisioning logic and inspection reports must be designed against your regulator's requirements and then tested in your environment. Confirm with your compliance team which overdue-day buckets, provisioning rates and report formats apply to your licence before you configure anything. The same applies to any repayment strategy your regulator prescribes.
The Fineract README is direct on this point: a production deployment can be complex, costly and time-consuming, the project does not provide a comprehensive production deployment guide, and organizations may pay a vendor for deployment and maintenance. Treat the build as a planned program with named owners for hosting, database operations, backup and recovery, identity, integrations and change control. Ask any implementation partner, DeployOpen included, to put the scope, deliverables and test evidence in writing before work starts, and ask your own team to confirm which operational responsibilities they will carry after go-live.
NBFC requirements Fineract must meet and what each means for the build
This table maps the core controls a non-bank lender is typically inspected on to what each one means for a Fineract configuration. Read each row as a question to settle with your regulator's current directions before design starts, since the thresholds and sequencing rules come from the RBI and your own compliance team, not from Fineract. The main takeaway is that most gaps sit in configuration decisions and reporting outside the core, so they need to be designed early.
| Requirement | Source of the requirement | What it means for the Fineract configuration |
|---|---|---|
| NPA classification by days past due | RBI prudential norms for NBFCs, applied through current RBI directions (confirm the exact thresholds and effective dates with the RBI texts) | Overdue days are computed from the repayment schedule and the business date. Confirm how Fineract counts days past due for each product, and whether a separate asset classification field or report is needed to record the stage. |
| Repayment waterfall order | Loan agreement terms and the lender's board-approved policy, aligned with the RBI fair practices expectations for application of payments (confirm with current directions) | Set the payment allocation order for each product so that charges, penalties, interest and principal are applied in the approved sequence. Test partial and advance payments against that order before go-live. |
| Provisioning | RBI provisioning rules for NBFC assets as set in current directions, and the lender's accounting policy (confirm the rates and categories) | Fineract does not decide provisioning rates for you. Map the provision ledger accounts, decide whether provisions are booked in Fineract or in an external ledger, and confirm that the NPA stage and the provision calculation use the same overdue data. |
| Maker-checker approvals | Internal control expectations for loan origination, disbursement and write-off, and inspection findings on segregation of duties | Enable and test maker-checker on loan approval, disbursement, adjustment and write-off actions. Confirm which roles can act as maker and checker, and document who holds each role at each branch. |
| Audit trail for inspections | RBI inspection practice and the internal audit standard the lender adopts, with the Fineract audit and history records as the system evidence | Confirm which transactions, edits and user actions are recorded and retained, and how long. Plan an export or archive process so inspectors can see the history without access to the production database. |
| Reporting gaps to fill | Regulatory returns and board reporting required for the lender's licence category (confirm the return formats with the RBI) | Fineract provides the loan and ledger data, but regulatory return formats are usually not produced out of the box. Budget a reporting layer, such as a data warehouse or reporting service, and list each return field with its source table before the build. |
Which Fineract modules and settings carry NBFC lending
Loan products are where most NBFC lending rules first take effect. In Fineract, a loan product fixes the principal range, interest method, repayment frequency, charges and the overdue behavior that later drives classification. Configure each product once, then test it against the lender's sanctioned terms in a non-production tenant before any client is onboarded. Confirm how a change to an existing product affects open loans in your version.
- Repayment order and allocation: Set how each payment is applied to charges, interest, principal and penalties, because the allocation order determines how overdue amounts age.
- Interest and schedule methods: Choose the interest calculation and schedule method per product, and record why each product fits the lending policy.
- Charges and penalties: Attach fees and penalties to products as charges so that every overdue amount is traceable on the statement.
- Amount, tenor and guarantor rules: Use the product-level limits your version supports, and keep the matching decision record in the credit policy.
- Custom repayment strategy: Where the lender's strategy goes beyond standard allocation, plan a custom processor or a documented manual step, and confirm it against your version's extension points.
Check that each product's schedule, allocation and overdue behavior matches the signed-off policy before go-live.
Close of business (COB) advances the books and updates overdue status each day, so the timing of asset classification depends on it. In Fineract, COB runs as a Spring Batch job. The README notes that it can run for several hours on deployments with millions of accounts and supports remote partitioning across worker nodes coordinated through ActiveMQ or Kafka. Logical business dates let processing run for a date other than the calendar day. Confirm how your version handles back-dated and catch-up runs before relying on them for regulatory cut-off dates.
- Run time at real account volume: Measure COB on a dataset close to the expected account count, because overdue ageing and provisioning updates run inside that window.
- Partitioned workers: Plan remote partitioning across worker nodes, coordinated through ActiveMQ or Kafka, and size the workers to the account count.
- Instance layout: The documentation recommends one write instance, one batch instance and multiple read instances on database read replicas. Plan database capacity and failover around that layout.
- Schema change timing: Liquibase migrations run only on write instances, so schedule schema upgrades outside COB windows.
- Business date control: Document who can move the business date and how a missed, repeated or failed COB is detected and corrected.
Confirm COB duration and failure recovery with a load test that reflects your expected account count before you fix the reporting cut-off.
Fineract provides real-time integrated accounting, so each loan and savings transaction produces ledger entries. The accounting mode set per product and the mapping of each product, charge and write-off to a general ledger account determine what the ledger records. NBFCs need that mapping to match the chart of accounts used for statutory returns and for any external ERP. Because entries are generated from transactions, a mapping error repeats on every transaction until it is found and corrected.
- Product-to-GL mapping: Map every loan product, charge, penalty and write-off to a ledger account, and review each mapping against the approved chart of accounts.
- Accounting mode: Choose the accounting mode per product and confirm the income recognition approach with finance and the external auditors.
- Period closure and manual journals: Use accounting closures to lock completed periods, and define who may post manual journal entries and how they are approved.
- Income suspension on NPAs: Confirm whether standard accrual posting covers income reversal or suspension for non-performing assets. If it does not, plan a journal process or a custom job and document it.
- ERP feed: Decide whether the external ERP receives journal entries directly or through a reconciled extract, and test the period totals before the first live close.
Reconcile a sample of product and charge postings to the external ledger in a test tenant before go-live.
Maker-checker in Fineract is a configurable workflow that holds selected actions until a second user approves them. For NBFCs, inspection readiness depends on which actions require a checker, who holds the maker and checker roles, and whether the approval trail can be produced on request. Delinquency and provisioning draw on overdue data. Fineract supports delinquency and provisioning configuration, but the bucket boundaries and provisioning percentages must come from the lender's current regulatory directions and approved policy, which compliance should confirm.
- Maker-checker scope: Enable approval for the actions the policy names, such as disbursement, write-off, restructuring and manual journals, and confirm which actions your version can hold.
- Role separation: Ensure no user holds both maker and checker rights for the same action, and review role assignments on a set schedule.
- Overdue buckets: Define overdue-day buckets that match the asset classification rules in your jurisdiction, and have compliance confirm each boundary in writing.
- Provisioning configuration: Load provisioning categories and rates from the approved policy rather than from defaults, and keep a versioned record of each change.
- Classification gaps: Classification rules that go beyond aging, such as restructured accounts or sector-specific rules, typically need a custom report or job. Plan, build and test them as separate work items.
Walk one delinquent loan from overdue status through its approval trail and provisioning entry to confirm the evidence chain holds together.
Fineract is headless and exposes its data through REST APIs, so every regulatory return is produced by the lender's own reporting layer or by Fineract reports. Return templates rarely match the built-in outputs exactly, so NBFCs usually build an extract layer that reads from the API or a database read replica and maps fields to each template. The documentation recommends read instances on database read replicas for high load, which is the natural place for heavy reporting queries.
- Replica-based reporting: Point heavy reporting queries at read instances so that reporting load does not compete with the write path during COB.
- Field-level gap analysis: List each required return field, then map it to a Fineract report, an API response or a custom query, and mark every field with no source as a gap.
- Audit history: Confirm which change history Fineract keeps for loans, users and configuration, and whether it holds the evidence an inspector will ask for.
- Business events: External events such as ClientCreated can feed ActiveMQ or Kafka, but publishing is disabled by default. Enable it deliberately and document each consumer.
- Scheduled export jobs: Give each export job a named owner, a checksum and a retention rule, and test that a rerun produces identical files.
Request a field-by-field mapping for each required return and keep that mapping under change control with the configuration.
How an NBFC rollout sequences policy, configuration and cutover
The sequence turns regulatory and credit policy into configured Fineract behavior, proves that migrated data and ledger balances agree, and ends with a go-live that leaves an evidence pack an inspector can follow.
Map regulatory and credit policy to platform rules
Compliance, credit risk and finance agree in writing which rules the lender must follow: asset classification thresholds, repayment waterfall order, provisioning categories, approval limits and reporting obligations. Each rule is traced to a named owner and to the Fineract feature expected to enforce it, with gaps listed separately. The step is done when every policy item has either a configuration target or a documented custom build item.
Design the chart of accounts and product set
Finance designs the chart of accounts and the general ledger mappings before any product is configured, so that each loan and savings product posts to accounts that match the lender's statutory and management reporting. Loan products are then specified with interest method, charges, overdue handling and write-off rules drawn from step one. The output is a signed product and mapping specification that a reviewer can check line by line.
Configure products in a non-production tenant
The platform team builds the offices, currencies, products, accounting settings and roles in a non-production tenant. Fineract is multi-tenant: API requests carry the Fineract-Platform-TenantId header, and tenant connections are read from a tenants database, so the non-production tenant must be kept separate from production in both the header routing and the database configuration. Each configured item is checked against the specification, and the output is a configuration baseline stored under version control.
Build and test custom NPA and waterfall logic
Only where step one found a rule that standard configuration cannot express, the team builds custom logic as an extension rather than a fork, then tests it against scenario accounts covering each overdue band, partial payments and restructured loans. Tests are reviewed by credit risk, not only by engineers. The step closes when every scenario produces the expected classification and allocation and the results are retained as test evidence.
Migrate data and reconcile balances
Client, loan and savings data are loaded with the import mechanisms the platform provides, in an order that respects dependencies such as offices and products before accounts. Each load is reconciled against the source system at the level of counts, principal, interest, arrears and ledger balances, and every difference is either corrected or signed off. Migration is repeated on fresh copies until the reconciliation is clean, so the final load is a rehearsed procedure rather than a first attempt.
Run a parallel period and measure close of business
The lender runs the new platform alongside the legacy system for a period agreed in advance, comparing daily balances, overdue classifications and provisioning outputs. The team also measures how long the Close of Business Day job takes on the actual account volume, because the README notes that this job can run for several hours on deployments with millions of accounts and grows with account count. Differences are logged with root causes, and the step ends when the agreed comparisons match or every exception has an approved explanation.
Go live with an inspection evidence pack
Cutover follows a written runbook with a rollback decision point, freezing configuration and migrated data at the agreed moment. The team assembles an evidence pack covering the policy map, configuration baseline, change approvals, test results, reconciliation records, parallel-run comparisons and access reviews, indexed so that an inspector can trace each rule to its evidence. The step is complete when the pack is stored in a controlled location and the lender's compliance owner has accepted it.
How the close of business day affects NPA classification
Overdue status and provisioning are only as current as the last Close of Business Day (COB) run. In Fineract, a loan's arrears and the classification that follows from them are updated by the batch job, not continuously as payments arrive. If the COB job for a business date has not completed, or has completed with errors, the aging you report to the board or the regulator reflects the previous day's position. For an NBFC that classifies NPAs by days past due, a missed or partial run can move accounts across the 90-day line late, and the error compounds because each subsequent day's arrears calculation builds on the one before it. The Fineract README notes that the COB Spring Batch job can run for several hours on deployments with millions of accounts, so the schedule has to leave room for that duration, and for reruns, before the business day opens for reporting.
The job supports remote partitioning across worker nodes, coordinated through ActiveMQ or Kafka. That is a capacity decision with a failure mode attached: if workers or the broker are undersized, unavailable or misconfigured, partitions can stall while the job appears to be running. Decide who owns the COB schedule, what the completion check is (job status, record counts per partition and a reconciliation against the aging report), and who is paged when the run is late. Run the aging report from the same business date after each COB and compare overdue buckets, account counts and provisioning totals against your own independent calculation for a sample of accounts. Treat any difference as a stop condition for regulatory reporting until it is explained.
Back-dated corrections need explicit confirmation before go-live. Fineract's logical business dates and the effect of a transaction posted to an earlier date on already-run COB days determine whether an arrears correction reprocesses the affected days, flags them for review or leaves past classifications unchanged. Ask the vendor how the platform behaves for each case, then test it in your own environment with a back-dated repayment and a back-dated reversal, and record which NPA classifications and provisions change. Write the resulting procedure into your maker-checker and audit design so that an inspector can see who approved a correction and which period it restated.
Compliance and audit controls an NBFC inspection will test
An NBFC inspection tests whether the lending system restricts who can change it, protects data in transit, and leaves a record of every change. Fineract provides the building blocks, but the controls must be configured, documented and evidenced in your own environment, which is where DeployOpen prepares the material for your assessors.
Access control and default credentials
The Fineract README ships a development login of mifos with a default password, and that login must be changed before any real deployment. Check that default accounts are disabled or replaced, that each staff member has a named user, and that role assignments follow your maker-checker matrix. Review who can alter products, accounting mappings and business dates, because those changes affect every loan on the book. Keep the user list and role export as dated inspection evidence.
HTTPS only with enforced SSL settings
The Fineract documentation strongly encourages HTTPS only and configures SSL through environment variables such as FINERACT_SERVER_SSL_ENABLED. Confirm that plain HTTP is closed at the load balancer and gateway as well as in the application, and that certificates are issued from a managed authority with a renewal process. Inspectors will ask for the configuration that proves this, so store the deployed values and a scan result alongside the change record.
IT general control evidence
Inspectors often review IT general controls in the same way SEC Release 33-8810 describes them for internal control over financial reporting: program development, program changes, computer operations and access to programs and data. This is a reference model, not a rule that binds most NBFCs. Build evidence for each area: approved change tickets tied to deployments, Liquibase migration logs, batch job run records for Close of Business Day, and periodic access reviews.
Multi-factor authentication for system access
Where the FTC Safeguards Rule applies to your institution, 16 CFR 314.4(c)(5) requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. Fineract's OAuth2 support lets you place an identity provider in front of it, but MFA must be enforced at that provider for staff, administrators and remote access. Document the exceptions, the written approvals and the enrollment records.
PCI DSS scope when cards are involved
If your lending or repayment flows store, process or transmit cardholder data, or could affect systems that do, PCI DSS applies to that environment and to the connected payment components. Fineract does not need to hold card data, so a common design keeps card capture and tokenization in a separate, validated service and sends only tokens or payment references to Fineract. Map the data flows before the build, and confirm with your acquirer or payment brand what validation they require.
Third-party terms under DORA Article 30(2)
For lenders with EU operations, DORA Article 30(2) requires each ICT services contract to state where services are provided and data processed, to give advance notice of location changes, and to cover data return on insolvency or termination. Fineract itself is open source with no contract, so these terms apply to your implementation partner, hosting provider and any managed database service. Ask for the register of information entries and tested exit plans as part of the contract package.
What NBFCs ask before hiring a Fineract partner
What drives the cost and duration of a Fineract implementation for an NBFC?
Scope drives both cost and duration more than anything else: how many loan and savings products you configure, how many integrations you build, how much historical data you migrate, and how many reporting outputs you must reproduce. Each of these is a separate line in a written scope, so ask the partner to price them individually. Some costs are one-time, such as design, build, migration and testing. Others recur, such as hosting, database operations, upgrades and support. Fineract's own README warns that a production deployment can be complex, costly and time-consuming, so treat any estimate that skips infrastructure and operations as incomplete. DeployOpen does not publish a price list; a quote follows from the agreed written scope.
What must our lending team supply before an implementation partner starts work?
Your team has to supply the decisions that the software cannot make for you. That means the written credit and collections policy, the product rules for each loan and savings type, the NPA and overdue-day classification rules you must apply, the provisioning method, the chart of accounts and accounting mappings, and the list of regulatory reports with their field definitions. Data is the other half: clean client records, loan books with schedules and repayment history, and a named owner who can answer questions quickly. Ask the partner to produce a written list of these inputs at the start, with a due date for each, because late policy decisions are one of the most common causes of rework.
Can our internal team run Fineract after the partner hands over the system?
Often yes, but only if the handover is designed for it. Your team needs skills in PostgreSQL administration, container or Kubernetes operations, Fineract configuration, and the business rules behind your products. Fineract is headless and has no built-in user interface, so you also need to decide how staff will work with it. Ask for runbooks covering scheduled jobs, the Close of Business Day job, backups, restore tests, upgrades and configuration changes, plus knowledge transfer sessions recorded against those runbooks. Ongoing support, upgrades and continuous testing are available as retainers if you prefer a shared operating model.
How do we validate NPA classification and provisioning outputs from Fineract?
Validate them against a written test pack built from your own policy, not from the software's defaults. Take a set of loans with known repayment histories, including edge cases such as partial payments, reschedules and restructured accounts, and calculate the expected overdue days, asset class and provision amount by hand or in a separate spreadsheet. Run the same loans through Fineract on a test tenant and compare the results. Repeat the check after every configuration change and every release upgrade. Keep the test cases, expected results and sign-offs as evidence for internal audit and for your regulator's inspection.
Which regulatory reporting gaps does Fineract leave, and how are they filled?
Fineract provides the ledger, loan and savings data and configurable business rules, but it does not ship every regulatory return your supervisor may require. Expect gaps in report formats, field mappings, classifications that depend on your jurisdiction, and aggregations across entities or products. These gaps are usually filled in one of three ways: custom reports built on the REST API or database read replicas, an external reporting layer fed from Fineract data, or manual schedules maintained by finance staff. Each approach carries different controls, so document the source of every field, the transformation applied and who approves the output. Confirm the exact return formats with your regulator and with the people who will sign them.
What should we ask for in a quote from an implementation partner?
Ask for a written scope that lists each product, integration, migration batch, report and control as a separate deliverable. Request the assumptions behind each line, including the environment (cloud account, data center or air-gapped network), the number of environments, and the data volumes assumed. Ask which items are one-time and which recur, what the handover includes, what knowledge transfer is provided, and which items are excluded. Also request the acceptance criteria for each deliverable, the change process if scope moves, and the support options after go-live. A quote that cannot be traced back to these items is hard to compare with other bids.
How does DeployOpen handle security and audit controls for a self-hosted Fineract deployment?
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, and runs security testing on applications, APIs and infrastructure. For Fineract, that means changing the default development login before go-live, enforcing HTTPS and TLS settings, separating read, write and batch instances, and setting up logging and access records that support maker-checker and audit reviews. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations, so confirm the evidence they need before the design is fixed.
Reporting gaps to fill around Fineract
Fineract records loans, repayments, accounting entries and events, but it does not produce the return formats, provisioning views or inspection packs an NBFC files with its regulator. The cards below cover the gaps that usually need custom jobs, reports or data pipelines. Each one must be confirmed against current RBI requirements and your own reporting calendar before design begins.
Regulator return formats
Regulatory returns follow prescribed layouts, field definitions and submission calendars that a core ledger does not produce by default. Map each return line to a Fineract table, API response or journal entry, and record where a value must be derived rather than read directly. Confirm the current RBI formats, field lists and filing dates for your NBFC category with your compliance team, because these change and a schedule set from an old circular will fail at filing. Expect custom reports or extract jobs for each return, owned and tested by your team.
Provisioning beyond the standard
Fineract can store loan provisioning settings and accounting entries, but a provisioning rule that depends on asset class, security cover, collateral type or product-specific floors is usually beyond the stock configuration. Decide whether provisioning is computed in Fineract, in a downstream calculation service, or in a reconciled spreadsheet, and document which system is the record of truth. Confirm each provisioning rule against current RBI directions for your lender type. Test every rule with sample loans that cover each asset class before the first closing.
Delinquency buckets for reporting
Overdue-day buckets used in regulatory and management reporting may not match the aging buckets shown in standard Fineract views. Define the bucket boundaries, the day count basis and whether buckets are reported by principal, interest or total overdue, then build the report on that definition. Agree with your credit and finance teams which bucket feeds the NPA flag, so the same loan does not appear in two categories. Confirm the boundaries against current RBI guidance before any report goes live.
Data lineage for inspections
An inspector may ask how a reported figure was produced, from which loan records, on which business date, and with which configuration in force at that time. Fineract's business date handling and configuration history help, but lineage across the ledger, the reporting database and any downstream calculation needs its own design. Record job run identifiers, source extract timestamps and configuration versions alongside every return. Confirm with your auditors which lineage evidence they will request, and rehearse one reconstruction before the inspection.
Loan-level audit exports
Inspectors often request loan-level histories covering every disbursement, repayment, charge, waiver, restructuring and write-off with the user who made each change. Fineract records transactions and audit information, but the export format, retention period and file layout are your decision and usually need a custom report. Specify the fields, the date range logic and the approval chain for producing the export, and test it against a sample of closed and written-off loans. Confirm the retention requirement for these records with your regulator and legal team.
Decisions an NBFC must make before the build starts
The first decisions an NBFC makes set the scope of the Fineract build, so they should be settled in writing before any configuration starts. The most consequential is the product catalogue and the repayment waterfall: which products exist, how each allocates a payment across charges, penalties, interest and principal, and whether that order matches the rules the regulator and the lender's board expect. Fineract's payment allocation and overdue handling are configured per product, so a waterfall agreed late will mean re-testing every loan product. Maker-checker is the second decision. Name who may create, modify and approve loans, disbursements, write-offs, NPA overrides and manual journal entries, and map each to a Fineract role and permission set. Ask the implementation team to show how the approval records are retained, because inspectors will ask for them.
The third decision is where regulatory reporting lives. You can build the NPA classification by overdue days, provisioning and return extracts inside Fineract, or feed them from an external warehouse that reads Fineract data. The choice affects who owns the logic, how changes are tested and how the reporting gaps described on this page are closed. Fourth, decide where the platform is hosted, including whether data and backups must stay in India, and confirm this against your regulator's current requirements and your own outsourcing policy. Fifth, fix the phase one integrations: KYC verification, payment rails for disbursement and collection, and credit bureau reporting. Each needs a named owner, a data contract and a test environment. Anything left for phase two should be recorded as such, so it does not quietly enter the critical path.
What the lender's team owns after go-live
After go-live, the lender's team runs the Fineract platform day to day, so this sequence hands over the operating runbooks, upgrade and backup routines, and access controls that keep the lending ledger running and auditable. Each step closes with a named artifact that the team can show to an inspector or a partner.
Hand over the COB and batch runbooks
DeployOpen walks the lender's operations and platform staff through the Close of Business job, the batch instances and the failure paths for each, including how to identify a stalled or partially completed run and who is authorized to restart it. The lender's team then runs at least one scheduled business day under its own supervision while DeployOpen observes. The step closes when the team has signed off a written runbook and has completed a restart rehearsal in a non-production environment.
Set the upgrade plan against release cadence
The lender's platform owner records the Fineract version in production, subscribes to the project's release announcements, and agrees a quarterly review point, since the project creates official releases at the end of each quarter. The review decides whether to adopt each release, what regression testing it needs, and when an end-of-life release must be retired, because the project archives those releases. The step closes with a dated upgrade calendar and a named owner for each release decision.
Confirm the PostgreSQL platform and its owner
The lender confirms that production runs on PostgreSQL, the database the project recommends, since MariaDB and MySQL are deprecated under FSIP-9. The team records who owns the database platform, its patching, its major-version plan and its connection to the tenants database. The step closes with a documented database ownership record and a confirmed PostgreSQL version that matches the Fineract release in use.
Run backups and prove restores
The operations team schedules database and configuration backups, including tenant data, and runs restore tests on a regular cadence that the lender sets in its own policy. Each test restores into an isolated environment, reapplies the Fineract version in use, and checks that loan and savings balances reconcile with the ledger. The step closes with a restore test record that shows the time taken, the checks passed and any gaps found.
Schedule periodic access reviews
The security owner reviews Fineract user accounts, maker and checker roles, teller and office assignments, OAuth2 clients and administrative access against the approved roles matrix. The team confirms that the default development login was replaced before go-live and that HTTPS is enforced for all access. The step closes with a signed review record for each cycle and a log of revoked or changed permissions.
Agree support arrangements in writing
The lender confirms in writing which party answers which incident, including platform defects, batch failures, infrastructure faults and upgrade work, and what response the lender can expect from each. The project's documentation does not provide a complete production guide, so the lender should ask any partner to state the support scope, escalation path and exit terms in the contract. The step closes with a signed support schedule that is reviewed alongside the upgrade calendar.
How DeployOpen scopes and delivers an NBFC Fineract implementation
DeployOpen plans, builds, documents and supports self-hosted Apache Fineract inside your own cloud accounts, data centers or air-gapped networks. For NBFCs and non-bank lenders, we start from your lending products, overdue-day rules and inspection evidence, then build the platform and controls around them.
How we scope
- We agree a written scope covering loan products, NPA buckets, provisioning rules and repayment allocation before work starts.
- The scope names the Fineract modules, ledger mappings, integrations and migration sources that are in and out of the engagement.
- Engagements are fixed-scope, so deliverables and timelines are confirmed in writing and a quote follows from that scope.
How we build
- We configure products and close-of-business settings in a non-production environment, then test overdue-day aging against agreed sample loans.
- Maker-checker approvals, role assignments and audit trail settings are built and tested against your inspection evidence needs.
- Reporting gaps are identified early, and we build or document the extracts your regulator and internal audit will ask for.
How we hand over
- You receive configuration records, mapping documents, test scripts and results, and runbooks covering batch jobs, backups and recovery.
- Operational ownership is transferred through walkthroughs with your finance, credit risk and IT teams, with named owners for each control.
- Evidence packs are prepared for your auditors, and we make clear that independent auditors, not DeployOpen, issue any assessment outcome.
How we support
- Ongoing support, Fineract upgrades and continuous testing are available as retainers after handover.
- Upgrades follow the project's quarterly release cadence and end-of-life policy, with regression tests re-run against your product rules.
- Changes to products, provisioning rules or reports go through the same scoped change and testing process as the original build.
