Credit policy rules every small NBFC should automate (with an example BRE policy)

Every NBFC has a credit policy. The question is whether it lives in a PDF that credit managers interpret, or in credit policy rules that run automatically on every application. This article lists the rules small NBFCs and LSPs should automate first, shows how to structure them in a business rule engine (BRE), and flags the mistakes that make automated policies misfire.

The six rule groups in a lending credit policy

Group rules by purpose and run them in this order. Cheap, decisive checks come first so the engine does not pull a bureau report for an applicant who was always going to be rejected.

1. Knock-out rules

Hard stops. If any one fails, the application is rejected with a reason code.

• PAN or mobile number appears on your internal blacklist
• An active loan with you is already overdue
• KYC verification failed or the face match did not pass
• Location or IP address is flagged as high-risk

2. Eligibility rules

Is this applicant someone this product is designed for?

• Age within the product's band (for example 21–58)
• Pincode in your serviceable list
• Employment type the product allows (salaried, self-employed)
• Requested amount and tenure within product limits

3. Bureau rules

• Bureau score at or above your cut-off
• No write-off or settlement in the last N months
• Maximum number of credit enquiries in the last 30 or 90 days
• Maximum number of active unsecured loans

4. Affordability rules

Affordability is usually measured with FOIR — the share of monthly income already committed to fixed obligations such as EMIs. The rule checks FOIR including the new EMI. Try different values in our FOIR calculator.

• FOIR after the new EMI must stay at or below your cap
• Net monthly income above a minimum for the product
• No more than N EMI or cheque bounces in the last six months of bank statements

5. Limit rules

Instead of only approving or rejecting, set the amount:

• Approve the lower of the requested amount and the amount that keeps FOIR within your cap
• Cap first-time borrowers at a lower amount than repeat borrowers with a clean history

6. Routing rules

• Refer any application above a set amount to a senior credit manager
• Refer when a data source is unavailable instead of rejecting
• Refer near-misses (for example, FOIR within two points of the cap) for human review

An example policy for an unsecured personal loan

Here is how those groups look as a single decision table. The values are illustrative.

The same policy expressed as configuration might look like this:

policy: personal-loan
version: 3
rules:
  - id: blacklist      when: pan in blacklist            then: reject
  - id: kyc            when: not kyc.verified            then: reject
  - id: age            when: age < 21 or age > 58        then: reject
  - id: bureau_score   when: bureau.score < cutoff       then: reject
  - id: enquiries_30d  when: bureau.enquiries_30d > 4    then: refer
  - id: foir           when: foir_with_new_emi > 0.50    then: reduce_amount_or_reject
  - id: bounces_6m     when: bsa.bounces_6m > 1          then: refer
default: approve

How rules differ by product

One policy rarely fits every loan you offer. Keep a separate rule set per product so you can tune each one on its own:

Common mistakes when automating credit policy

• Rejecting on missing data. If the bureau times out, “reject” loses good borrowers. Route to refer instead.
• No reason codes. A decision without a reason cannot be explained to an auditor or a borrower.
• Editing rules in place. Always create a new policy version so past decisions remain explainable.
• Automating everything on day one. Start with knock-outs and clear approvals; keep the middle in the referral queue until the numbers prove the rules.
• Never reviewing thresholds. Check approval, referral and early-delinquency rates by policy version every month.

For real-world scenarios — clearing a credit backlog, stopping repeat fraud, reacting to rising delinquencies — read six ways a BRE improves lending operations.

Frequently asked questions