When a Fineract loan becomes a non-performing asset and what you configure
A credit or risk lead who reports non-performing assets from Fineract data needs the classification rule agreed and tested before go-live, because every NPA report, provision and arrears view will be built on it. In Fineract, NPA status and arrears ageing are two separate decisions, and both depend on the number of days a loan is overdue. The platform exposes these rules as product and system configuration rather than as fixed logic, so the same loan can be classified differently depending on how the product and global settings are set. Confirm the exact setting names, their defaults and how they behave in the Fineract 1.15.0 documentation for your deployment, and test them with dated scenarios before relying on them.
This page covers how to decide the overdue-day threshold for NPA, when an account may move out of NPA (only once arrears are cleared), how arrears tolerance and grace on arrears ageing change the ageing result, and how these settings relate to delinquency buckets. It also covers the verification steps and the operating controls that keep the configuration stable after launch. It does not decide the regulatory definition of an NPA, the number of days that triggers classification, the sub-standard, doubtful or loss categories, or the provisioning percentages. Those come from the lender's regulator and the lender's own credit policy, and the implementation should record the rule source so auditors can trace each setting back to it.
Before configuration starts, the risk owner, the finance lead and the Fineract administrator should agree a written classification rule covering the overdue-day threshold, the arrears tolerance, the grace applied to ageing, and the bucket boundaries used for reporting. Ask whether the regulator treats partial payments as curing arrears, and whether restructured loans carry a different classification. A quote for this work should include the rule workshop, the test scenarios and the reconciliation of Fineract reports against the agreed rule, so that the scope of the configuration is clear before anyone builds it.
Which NPA and arrears ageing settings fit which lending book
This table compares the five classification settings a lender must decide on, with the lending books where each usually fits and the reporting or provisioning effect to confirm with the regulator. Read each row as a decision: choose the setting that matches the loan tenor and collection pattern, then confirm the threshold and bucket boundaries against your own regulatory rules before configuring anything.
| Setting | Where it tends to fit | Reporting or provisioning effect to confirm |
|---|---|---|
| Overdue-day threshold for NPA | Short-term consumer or payday-style loans, where arrears build quickly and a short threshold reflects collection risk; longer threshold for long-tenor secured loans with monthly installments | Which date the loan is reported as non-performing and when provisioning rules apply; confirm the threshold with the regulator and the lender's credit policy |
| Condition for leaving NPA | Books where borrowers often pay a partial amount to restart the cycle; a stricter condition suits lenders that need full cure before reclassification | Whether a partial catch-up returns the loan to performing status and how the provision is released; confirm the cure rule in the regulatory guidance |
| Arrears tolerance | Retail books with frequent small timing differences, such as salary-date mismatches; tolerance is usually narrow for secured or corporate loans where any missed amount is significant | Whether small overdue amounts count toward arrears and ageing; confirm how tolerance is disclosed and whether it changes reported arrears totals |
| Grace on arrears ageing | Loans with payment holidays, seasonal income or agricultural cycles, where a short grace avoids penalizing borrowers for scheduled deferrals | Whether grace days delay ageing and NPA entry; auditors will expect the grace policy to be documented and applied consistently |
| Delinquency bucket boundaries | Lenders that report aged portfolio analysis by bucket; finer buckets suit high-volume short-tenor books, coarser buckets suit low-volume long-tenor books | Bucket limits must match internal reports and regulatory returns; confirm the bucket structure with the regulator and reconcile it to provisioning tiers |
Decisions to settle before configuring NPA rules
Each decision below changes which loans Fineract flags, when they leave that status, and what the board and regulator see. Settle them in writing before product configuration starts, because the answers set the overdue-day thresholds, the arrears basis and the bucket reports. Changing them after go-live means restating historical classifications.
Regulatory NPA definition
Decide which regulatory definition of non-performing asset your reports follow, including the overdue-day threshold, any additional triggers, and whether restructured or rescheduled loans keep their status. Fineract's overdue-day setting is a parameter you choose, so it must match the rule your regulator applies, not a default. Ask your compliance lead and regulator reporting team to confirm the wording in writing before anyone edits a product. If deferred, product settings get copied from a guess and reports later disagree with the core system.
Arrears basis: principal, interest or both
Decide whether an overdue installment counts toward arrears only when principal is unpaid, when interest is unpaid, or when either component is overdue. The same loan can be current on one basis and in arrears on another, especially on loans with grace on principal. Write the rule as a worked example using a sample schedule and check it against your reporting definitions. If deferred, ageing reports and NPA lists will use the default basis and finance will reconcile two different delinquency numbers.
Treatment of partial payments
Decide how a partial repayment affects the ageing date and the NPA status: whether any payment resets the oldest overdue installment, whether payments must clear all arrears before status changes, and how small residual amounts are handled. This interacts with the repayment transaction processing strategy you select. Test partial payments against each product in a non-production tenant. If deferred, borrowers paying part of an installment can appear current or stay classified for months, and collections teams will not know which rule applied.
Delinquency bucket boundaries
Fix the bucket ranges used in board packs, regulator returns and provisioning, such as the number of days overdue at each boundary and whether the last bucket is open-ended. Confirm that the NPA threshold coincides with a bucket boundary or document the mapping. Store the boundaries in one place so product reports and external returns read the same values. If deferred, buckets get redefined in spreadsheets, and the same portfolio produces different totals in different reports.
Approval of manual overrides
Define who may change an loan's classification by hand, under what evidence, and how the change is reviewed. Typical cases include restructured loans kept out of NPA, or loans held in NPA despite a clearing payment. Name the approver role, the required justification, and the report that lists every override. Confirm how your Fineract roles and approval workflows will enforce this instead of relying on a spreadsheet. If deferred, overrides get applied informally, and auditors cannot trace why a loan's status differs from the rule.
Post go-live rule ownership
Name the team that owns NPA parameters after launch, the change process for product settings, and the schedule for reviewing buckets against the regulator's latest guidance. Include who runs the reconciliation between Fineract classifications and the general ledger provisions. Make sure this owner can test changes in a non-production environment before they reach production. If deferred, nobody is accountable when a regulation changes, and product settings drift from policy without a record.
How to set up NPA classification and arrears ageing in Fineract
This sequence turns a written NPA and arrears policy into tested Fineract product and loan settings, with each step checked against hand-calculated results before the configuration reaches production. The output is a verified record of when loans move into non-performing status, when they leave it, and which delinquency bucket they occupy at each business date.
Confirm the rule and bucket definitions in writing
The credit or risk owner, with compliance, writes down the overdue-day threshold for NPA classification, the rule for leaving NPA status, the arrears tolerance and any grace on arrears ageing, and the delinquency bucket boundaries with their labels. Each rule should name the regulator or internal policy it comes from and say whether it counts calendar or business days. Your regulator or internal policy owner must confirm these figures, since Fineract only applies what you configure. Done means a signed rule sheet that the test in later steps can be checked against.
Map each rule to Fineract settings in a test tenant
In a non-production tenant, the implementation lead maps each written rule to a specific product or loan setting, such as the overdue-days setting used for NPA, the arrears tolerance, the grace on arrears ageing and the delinquency bucket definitions. Record the exact setting names and values from your Fineract version, and confirm in the product documentation how each one behaves, because the names and options differ between releases. Done means a mapping table where every rule points to one setting and every setting points back to one rule, with no unmapped items.
Load sample loans at known overdue ages
The data team creates a set of illustrative loans in the test tenant, each on a product using the mapped settings, and brings them to chosen overdue ages by disbursing, withholding repayments and posting partial payments where needed. Include boundary cases at the threshold, one day before and one day after it, loans that cure a partial arrears amount, and loans inside the tolerance and grace windows. Done means a loan list in which every account has a documented expected status and bucket written down before the batch job runs.
Run the business date forward through close of business
The operator advances the logical business date one day at a time and runs the close-of-business job after each change. This job runs on the batch instance, so confirm with your platform team which instance runs it in the test environment and how its logs are read. Also measure how long the job takes on a dataset close to your production account volume, because the Fineract documentation notes it can run for hours on large deployments. Done means each business date has a completed run with logs retained and no failed steps.
Check NPA status and buckets against hand calculations
The tester compares each loan's NPA flag, overdue days and delinquency bucket with the expected values from the calculated schedule, using an independent spreadsheet built from the rule sheet rather than from Fineract output. Pay particular attention to the day a loan crosses the threshold, the day it should stay in NPA despite a partial payment, and the day it clears and leaves NPA. Any mismatch is logged with the business date, the setting and the expected and actual values. Done means zero unexplained differences, or a documented fix followed by a rerun of the affected dates.
Record evidence and lock the configuration
The implementation lead exports the mapping table, the test loan list, the close-of-business logs and the reconciliation sheet, and gets sign-off from credit risk and compliance. Product changes are then moved to production through your normal change process, and the first production close of business is watched and compared with the same reconciliation logic. Done means a dated evidence pack and a change record, so auditors and internal reviewers can trace each NPA and bucket rule to its configuration and its test result.
Moving out of NPA only when arrears are cleared
Most lenders require that a loan clear its arrears in full, not just reduce them below a threshold, before it leaves non-performing status. The reason is that a single payment can bring an account back under the overdue-days limit while the borrower still owes a meaningful amount, and a partial catch-up often reflects a temporary fix rather than a return to repayment. The implementation must reflect the lender's written exit rule exactly, including whether the test is the full arrears balance, a minimum payment, or a set number of consecutive on-time installments. Confirm this rule with the credit risk owner before configuring anything, because it determines whether tolerance or grace settings are appropriate at all.
Tolerance and grace change the picture in two different ways. Arrears tolerance on the ageing configuration lets small overdue amounts be ignored for classification, so a loan can appear performing while still carrying arrears. Grace on arrears ageing delays when overdue days start counting. Both affect the exit path, because an account that never entered NPA under tolerance will not need to exit it. Test each combination on a sample loan: a partial payment that clears part of the arrears, a full clearance, a payment that clears arrears but leaves a later installment overdue, and a backdated repayment. Record the classification and the arrears figures after each step, and compare them with the policy table.
Rescheduling and restructuring need their own test cases. A reschedule that moves installments forward may reset the overdue position, which can make an NPA loan look performing without any cash being received. Confirm with the policy owner whether a restructured loan must stay classified as non-performing for a defined period, and whether Fineract's documented behavior for each reschedule path matches that answer. Also test what happens when a loan is restructured, then paid partially, then cleared, because the exit condition must still be evaluated on the restructured schedule. Check the Fineract documentation for the current behavior of each path before relying on it, since the details are version-dependent.
Controls and operations that protect NPA reporting
NPA classification is only as trustworthy as the rules behind it and the people who can change them. The controls below cover who can alter product and tolerance settings, how manual reclassification is approved, how changes move between environments, and how batch results are checked before reports are produced. Each one depends on a Fineract security or deployment setting that should be confirmed in your own environment.
Restrict who changes product rules
Overdue-days thresholds, arrears tolerance and grace settings sit on loan products, so any user who can edit a product can change when loans become NPA. Limit product maintenance to a small named group and review that group against your delegation matrix each quarter. Fineract authorizes requests through its user and role model, so confirm which permissions cover product edits and test that a standard teller or loan officer account cannot reach them. Remove the default development login before go-live, since a known credential would let anyone reach these permissions.
Change the default login and enforce HTTPS
The README ships a default development login, and anyone who knows it can act as an administrator. Replace it before any real deployment, store the new credential in your secrets manager, and tie access to your identity provider where the chosen authentication method supports it. Enforce HTTPS only, using the SSL settings the documentation exposes through environment variables such as FINERACT_SERVER_SSL_ENABLED, so classification changes and reports are not exposed in transit. Confirm these settings in every environment, not only production.
Approve manual reclassification
Moving a loan into or out of NPA by hand, for example after a restructuring or a borrower dispute, bypasses the automatic rule and should need a second person. Use Fineract's maker-checker approval features where they cover the action in your version, or document a manual approval record in a data table if they do not. Require a written reason and the supporting evidence for each override, and reconcile overrides to the monthly NPA report. Confirm with your Fineract release which actions the approval workflow covers before you write the procedure.
Review the audit trail
Changes to product settings, tolerance values and loan status should leave a record of who changed what and when. Schedule a periodic review of those entries, compare product configuration against the approved change log, and investigate any change made outside a change window. Confirm which entities Fineract's audit records cover in your release and whether the logs are shipped to storage your audit team controls. A review that nobody signs is not evidence, so assign an owner and keep the sign-off.
Control configuration between environments
Product rules and tolerance settings often change first in a test environment and then get re-keyed into production by hand, which is where classification drift starts. Keep product definitions in version-controlled exports or scripts, promote them through the same review path as application code, and compare production products to the approved baseline after every release. Do not copy production customer data into lower environments to test NPA rules. Use synthetic loans that exercise the same overdue-day and grace paths.
Check batch results before reporting
NPA status is assigned during the end-of-day batch processing, so a failed or partial run can leave loans in the wrong state when reports are pulled. Before any regulatory or management report is produced, confirm that the close-of-business job for the reporting date completed, check its error and skipped-loan counts, and compare the number of loans in arrears against the previous run. Fineract batch jobs can run for hours on large portfolios, so build the check into the reporting calendar with a fixed cut-off time.
How the rule changes for each lending book
Short-tenor and payday-style loans have few installments, so one missed due date can represent a large part of the remaining contract. Overdue days therefore build quickly, and any arrears tolerance or grace you set has the most visible effect on how many accounts move into NPA. Confirm how your Fineract version counts overdue days from the first missed due date before you set any threshold.
- Overdue days start early: A missed due date on a short loan can reach ageing thresholds within a short window, so review the threshold with the credit team before go-live.
- Tolerance belongs on the product: Set arrears tolerance on the product and check that loan-level overrides are controlled and recorded with a reason.
- Collection timing: Automated debits and wallet collections can settle after cut-off. Test whether a payment received on the due date is applied to the correct business date.
- Renewals and rollovers: Test whether an extension or refinance resets overdue days, carries old arrears forward, or clears them.
Check each step with test loans: a payment on the due date, a late payment, a partial payment, and a rollover. Confirm the ageing bucket and NPA flag after each one.
Monthly installment loans have a fixed due date for each installment, which makes overdue days easy to explain to borrowers and auditors. The main design question is which unpaid installment sets the ageing start, and how partial payments reduce arrears across several installments. Grace matters most at the first installment and wherever the credit policy allows a short extension for arrears ageing.
- Oldest unpaid installment: Confirm whether ageing starts from the oldest unpaid due date in your version, and document the answer for your NPA policy.
- Partial payments: Test a payment that covers part of one installment and part of the next. Check whether the older installment still shows as overdue.
- Grace on ageing: Use a short grace only where the credit policy names it. Test that it changes the ageing start without changing the contractual schedule.
- Holidays and moved due dates: When a due date moves for a holiday, test that the overdue day count follows the moved date.
Before go-live, run a complete loan lifecycle with a missed installment, a partial payment, a catch-up payment and a holiday. Confirm that the ageing bucket and NPA status match the written policy at each stage.
Secured and mortgage loans run for long tenors, and many jurisdictions set NPA rules that differ by product type. Overdue days still drive the classification, but collateral and restructuring decide what happens after the account is classified. Confirm the regulator's NPA definition for each secured product before you map it to Fineract settings, because the rule may differ from unsecured lending.
- Small arrears, long tenor: A small missed amount on a long loan can still create overdue days. Test the day count independently of the amount.
- Reschedules and restructuring: Test whether a rescheduled loan clears the old arrears, carries them, or keeps the NPA flag until the policy's conditions are met.
- Collateral records: Collateral data is held separately from ageing. Test that adding or updating collateral does not change the NPA status or ageing bucket.
- Write-off and recovery: Test how a write-off or later recovery changes the NPA status and the reporting view.
Ask your compliance team to sign off the test cases for each secured product, including reschedules and write-offs. Keep the evidence of those tests with the product configuration record.
Group and center-based microfinance lending often collects repayments at scheduled meetings, so many loans can fall due and post on the same day. Overdue days can therefore arrive in batches, and the timing of posting relative to the due date becomes a classification question. Field teams may track arrears by group, while the NPA rule usually applies to each loan account.
- Meeting-day posting: Payments collected at a meeting may be recorded later. Test whether late posting pushes a loan into arrears and how the business date is set.
- Group follow-up versus loan classification: Field staff may chase arrears by group, but test that each loan account keeps its own ageing and NPA status.
- Tolerance across products: Test that the arrears tolerance applies consistently to loans opened mid-cycle and to repeat borrowers.
- Center closures and holidays: Test shifted meeting dates alongside your holiday and working day rules, so the due date and overdue count match the meeting calendar.
Before a pilot, simulate a full collection meeting with some payments on time, some late and some missing. Confirm the arrears list, ageing buckets and NPA flags agree with the field records.
Limits to confirm in your environment before committing to a design
Fineract's NPA and arrears ageing behavior depends on the exact release, the product type and how your reporting reads the results. The cards below list the points to settle with the project documentation and a test run before you fix a classification design. Each one can change the rules you configure or the data your reports depend on.
Available NPA and ageing options by version
The NPA and arrears ageing settings you can use depend on the Fineract release you run. The current stable release is 1.15.0, but your deployment may be on an earlier 1.x line, and the options for overdue days, tolerance and grace may differ between them. Check the exact settings in the documentation for your target version, then confirm them against a running instance before you write the classification policy.
Behavior on progressive loans
Progressive loans recalculate schedules, accept backdated changes and can be restructured, so overdue days and arrears may not behave as they do on standard products. Confirm how the NPA trigger and the exit condition apply when an installment is re-aged, rescheduled or partly paid after a rate change. Test each case on a progressive product in a non-production tenant before you rely on it.
Behavior on restructured loans
A restructured loan may keep its original overdue history, start a new schedule or carry arrears forward into new installments. Decide which outcome your credit policy requires, then verify that Fineract classifies the loan the same way. Pay particular attention to whether a restructure clears an NPA flag automatically or only after arrears are paid.
Whether reports read values directly
Delinquency buckets and NPA status may be available as live fields that reports read, or they may only appear in exports that your reporting pipeline must rebuild. Ask which of these applies to your version, and whether the values are stored or computed at report time. If a regulatory report needs a snapshot at a fixed date, confirm how that snapshot is produced and whether it reflects the business date.
Holidays and business dates
Overdue days are counted against dates, so holidays, non-working days and the logical business date can shift when a loan crosses the NPA threshold. Confirm how your tenant's holiday calendar and business date settings affect ageing, and test a loan that falls due on a holiday. Also confirm when the end-of-day job updates classification, since this sets how current the reported status is.
Fit with your regulator's definition
Regulators define non-performing status in their own terms, including thresholds, counting rules and treatment of restructured or partially paid loans. Map each element of that definition to a setting or a required custom process, and mark any element the standard settings cannot express. Ask your regulator or compliance advisor to confirm the mapping, since DeployOpen prepares the configuration but does not determine what your regulator accepts.
Questions lenders ask about NPA and arrears ageing in Fineract
How much effort does an NPA classification design take?
The effort depends mainly on how many loan products carry different classification rules, how many regulatory rules the institution must apply, which reports the classification must feed, and how much test data the team can build. A single product with one overdue threshold is a small exercise. A lender with several product families, separate rules for restructured or written-off accounts, and regulator-specific ageing buckets needs more design time, more configuration and a larger test matrix. Ask any partner to show how each of these four drivers is counted in their quote, and to list which rules are in scope and which are left to the institution to confirm with its regulator.
Can an internal team configure NPA and arrears ageing without outside help?
Yes, a team with Fineract administration skills and access to a test environment can configure the settings, provided it has someone who understands the credit policy and can write test cases for each product. The harder part is usually agreeing the rules and proving they behave correctly across overdue days, grace and tolerance settings, and the moment an account leaves NPA status. Internal teams often underestimate the regression testing needed after each change. A partner can take on the design, test scripts and evidence, or only the review, and the split should be written into the scope before work starts.
What does the credit and risk team need to provide?
The credit and risk team owns the rules, so the engagement cannot start without its decisions. It needs to supply the overdue day threshold for each product, the conditions under which an account leaves NPA status, how arrears tolerance and grace apply, and the mapping between delinquency buckets and provisioning or reporting categories. It also needs to name the people who approve each rule and who signs off test results. Expect the team to review test cases with real product examples, because configuration errors in these settings often only show up in edge cases such as partial payments on the due date.
How long does a classification build and test cycle take?
Timing depends on scope, and no duration is given here. The main variables are the number of products, the number of rule sets, whether reporting outputs must be reconciled, and how many test cycles the institution requires before go-live. Ask for a timeline that separates design sign-off, configuration, test execution and defect fixing, and that names the dependencies on the credit team's decisions and on access to a non-production environment. A timeline that does not show these dependencies is hard to hold a partner to.
Can NPA rules change after go-live, and what does a change require?
Rules can change after go-live, but the change should be treated as a controlled release, not a settings tweak. Before any change, confirm which open loans are affected, whether the new rule applies to existing accounts or only to new ones, and how the change will be recorded for audit. The team should re-run the test cases for affected products, check the reports that depend on classification, and agree who approves the change. Fineract configuration changes should be tracked in the same change process as code and environment changes, so the institution can show what was in force on any given date.
What should a fixed-scope quote for NPA classification include?
A fixed-scope quote should list the products and rule sets in scope, the regulatory or internal rules each one must satisfy, the reports and data outputs to be verified, and the test cases and environments used. It should name the deliverables, such as a configuration record, test evidence and an operating procedure, and state what the institution must provide, including credit policy decisions and test data. It should also state what is excluded, such as regulatory interpretation, which remains the institution's responsibility, and whether post-go-live support is a separate retainer. DeployOpen does not publish a price list, and a quote follows from the written scope.
Does DeployOpen certify that the classification meets regulatory requirements?
No. DeployOpen plans, configures and tests Fineract so that the classification behaves as the agreed rules specify, and it prepares the evidence an assessor will ask for. Independent auditors and certification bodies issue audit reports and attestations, and the institution's regulator decides whether the rules themselves are correct. The practical question to ask a partner is what evidence they will hand over, in what format, and how the institution's compliance team will be able to rerun the tests without the partner present.
How DeployOpen scopes and delivers NPA classification for Fineract
DeployOpen plans, implements, tests and documents Fineract deployments inside your own infrastructure, including the NPA and arrears rules that decide when a loan is classified as non-performing. Engagements are fixed-scope, with the classification rules, test cases and handover agreed in writing before build work starts.
How we scope
- Written scope lists each loan product that needs an NPA rule and the overdue-day threshold for each
- Scope records the rules for leaving NPA status, including which arrears must be cleared first
- Scope sets how arrears tolerance and grace on arrears ageing apply, product by product
- Scope confirms which delinquency buckets feed reporting and which teams own each rule
How we build
- Configure NPA and arrears ageing settings on a non-production Fineract tenant first
- Map each delinquency bucket to its overdue-day range and test the boundary dates
- Test repayments that clear part of the arrears to confirm the account stays in NPA
- Run repeatable test scripts against the Close of Business job for each product type
How we hand over
- Documentation records each NPA rule, its configuration value and the reason it was chosen
- Test evidence shows expected and actual classification for each agreed scenario
- Runbooks explain how operations staff review loans near a classification boundary
- Knowledge transfer sessions cover changes that need a product owner's sign-off
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer
- Retainer work can retest NPA rules after Fineract upgrades or product changes
- Support can review classification reports and arrears ageing data with your finance team
- Confirm with your auditors which evidence they expect for classification controls
