When a loan application dies, most small lenders only remember that it died. Nobody writes down why. A month later, the branch manager knows approvals are down but can’t say whether the cause was incomplete IDs, weak income proof, a guarantor who never picked up, or borrowers who simply walked away after hearing the terms. A short list of loan decline reason codes, tagged on every application that doesn’t reach release, turns that guesswork into a weekly number you can act on.
The short answer: pick eight to ten fixed codes, split into “we said no” and “they left”, tag exactly one code on every application that stops, and count them every Monday. After four weeks you will know which two reasons cost you the most loans, and who on the team owns the fix.
What a decline reason code is (and isn’t)
A decline reason code is one short label, picked from a fixed list, recorded the moment an application stops moving. It answers a single question: what was the main thing that stopped this loan?
It is not a free-text note. Notes are useful for the file, but you can’t count them. “Kulang docs, babalik daw” and “incomplete requirements” mean the same thing, yet a spreadsheet treats them as two different reasons. A code forces everyone to pick from the same shelf.
It also covers more than lender rejections. Some of your lost applications are borrowers who withdrew. Those deserve their own codes, because the fix is completely different: a decline usually points at intake or credit policy, while a withdrawal usually points at speed, pricing, or how the terms were explained.
A starter list you can use this week
Keep it short. Eight to ten codes is enough for a desk handling a few dozen applications a week. Split them into two groups: D codes are your decisions, W codes are the borrower’s. The “fix owner” column is the person who should bring an answer to the Monday review when that code tops the list.
| Code | Meaning | Fix owner | First fix to try |
|---|---|---|---|
| D-DOC | Required documents still missing after the follow-up window | Intake officer / desk lead | Hand a one-page requirements list at first contact; remind on day two, not day five |
| D-ID | Identity could not be confirmed or IDs didn’t match | KYC officer | Post the list of accepted IDs at the counter; check name and birth date match at intake, not at approval |
| D-INC | Income or cash flow too weak for the requested amount | Credit officer / branch manager | Check whether a smaller first loan fits your written policy before declining outright |
| D-HIST | Poor repayment history with you or a known reference | Credit committee | Confirm the threshold is written down, so two officers don’t apply it differently |
| D-GUAR | Guarantor or co-maker unreachable or declined | Account officer | Verify the guarantor’s contact before approval, not at release |
| D-CI | Field visit found address or business didn’t check out | Credit investigator | Capture a landmark or map pin on the application so the visit finds the right door |
| W-TERMS | Borrower withdrew after hearing rate, fees, or schedule | Branch manager | Show the full cost in writing earlier, before documents are collected |
| W-SLOW | Borrower withdrew because the process took too long | Desk lead | Time each step and find the one eating the days |
| W-OTHER | Borrower withdrew, reason unknown or personal | Desk lead | One short follow-up call within two working days, asking a single question |
If W-SLOW keeps climbing, pair this list with a loan turnaround time tracker so you can see which step is eating the days. If D-ID is common, tighten intake with a KYC field checklist so mismatches surface on day one.
Four rules that keep the data honest
- One primary code per application. If three things went wrong, the officer picks the one that would have stopped the loan on its own. Secondary details go in the note.
- Code it the same day. Reasons get fuzzy fast. Treat the code as a required column whenever an application is moved to declined or withdrawn, and have the desk lead check for blanks before closing the day.
- Don’t add codes on the fly. If officers keep using W-OTHER or a catch-all, review those notes monthly and decide together whether a new code is earned. A list that grows every week stops being comparable.
- Separate “not yet” from “no”. An application still waiting on a payslip isn’t declined. Only code it when your follow-up window closes, for example five working days after the last reminder.
What to record for each lost application
The code alone tells you what. A few extra columns tell you where and when, which is what makes the Monday review useful. Keep the tally sheet lean:
| Column | Example | Why it matters |
|---|---|---|
| Application reference | APP-0412 | Links back to the file without copying the applicant’s name into another sheet |
| Date received | Mon 5 Oct | Shows how long the application lived |
| Date closed | Fri 9 Oct | Puts the loss in the right review week |
| Officer | Initials | Spots coaching needs, not blame |
| Product and amount requested | Sari-sari store loan, ₱25,000 | Shows whether one product drives most losses |
| Code | D-DOC | The number you count |
| One-line note | “Payslip not sent after two reminders” | Context for the top two codes |
Use the reference number, not names, mobile numbers, or ID numbers. The full details already live in the loan file, and a sheet printed for a huddle should carry as little personal data as possible.
The 15-minute weekly review
Every Monday, the branch manager or desk lead pulls last week’s closed applications and counts three things:
- Totals by code. Which two codes account for most losses?
- Codes by officer. If one officer has far more D-DOC than the rest, that’s a coaching conversation, not a policy problem.
- D versus W. A desk that loses most applications to withdrawals has a speed or explanation problem. A desk that loses most to its own declines may be marketing to the wrong borrowers.
Run it on a timer so it stays at 15 minutes:
| Minutes | What happens | Output |
|---|---|---|
| 0–3 | Read totals by code, next to last week’s | Top two codes named |
| 3–7 | Read three notes from each of the top two codes aloud | What the top codes looked like this week |
| 7–10 | Look at codes by officer | Coaching to schedule one-to-one |
| 10–12 | Check the D vs W split and the W-OTHER count | Whether follow-up calls are happening |
| 12–15 | Pick one change for the week | One change, one owner, checked next Monday |
One change per week is the point. Try four fixes at once and next Monday can’t tell you which one worked.
A worked example
Here is an illustrative week, not real data, for a single-branch lender that closed 40 applications without release:
| Code | Count |
|---|---|
| D-DOC | 14 |
| W-SLOW | 9 |
| D-INC | 6 |
| D-GUAR | 5 |
| W-TERMS | 3 |
| Other codes | 3 |
| Total | 40 |
Before coding, the manager’s instinct was that borrowers were “too risky lately.” The tally says otherwise. D-DOC and W-SLOW together are 23 of 40 losses, a little over half, and both are things the desk controls. The fix for the week: hand every walk-in a one-page requirements list at first contact, and send a reminder on day two instead of day five. Credit policy doesn’t need to change at all.
Four Mondays later
Continuing the same illustrative branch, with about 100 applications closed each week (released plus lost), and one change added per week:
| Code | Week 1 | Week 2 | Week 3 | Week 4 |
|---|---|---|---|---|
| D-DOC | 14 | 11 | 8 | 7 |
| W-SLOW | 9 | 8 | 5 | 4 |
| D-INC | 6 | 6 | 7 | 6 |
| D-GUAR | 5 | 4 | 4 | 2 |
| W-TERMS | 3 | 3 | 4 | 3 |
| Other codes | 3 | 3 | 3 | 3 |
| Lost | 40 | 35 | 31 | 25 |
| Released | 60 | 65 | 69 | 75 |
| Change tried that week | Requirements list + day-2 reminder | Same, plus approver checks the queue twice a day | Guarantor call before approval | Keep all three |
How to read it: D-DOC and W-SLOW fell from 23 to 11, which accounts for most of the improvement. D-GUAR dropped once the guarantor call moved before approval. D-INC barely moved, which is expected, because none of the changes touched credit policy. That stable number is useful too: it tells the manager the remaining declines are real credit decisions, not desk problems. One week of W-TERMS ticking up is not a trend.
If D-GUAR keeps showing up at your branch, tighten the guarantor step before approval rather than at release. Our guide on rechecking guarantor contacts covers that flow.
Telling the applicant why
A clear, polite reason often brings an applicant back, and silence rarely does. Match the message to the code, keep it to one sentence about what is needed, and send it the same day you code the file:
- D-DOC: “We still need your latest barangay clearance and one month of payslips before we can continue. You can bring them to the branch any weekday.”
- D-INC: “We can’t approve the amount you requested right now. If you’d like, we can review a smaller amount based on the income you showed us.” Only say this if your policy actually allows a smaller first loan.
- D-GUAR: “We haven’t been able to reach your co-maker. Please ask them to call the branch, or name another co-maker.”
For W-TERMS, the fix sits earlier in the process. The Truth in Lending Act (Republic Act No. 3765) already requires a written statement of the finance charge before the loan is consummated. Showing that cost early, before the applicant has spent a week gathering documents, means the ones who walk away do it on day one instead of day six, and both sides waste less time.
Mistakes to avoid
- Coding to look good. If officers are measured on approvals, they’ll drift toward W codes (“borrower withdrew”) to avoid owning a decline. Review codes, not people, in team meetings.
- Treating every D-INC as final. Some of these borrowers qualify for a smaller first loan. Track how many you could have offered a reduced amount.
- Keeping declined files forever. Applicant data is still personal data after a decline. Under the Data Privacy Act of 2012 (Republic Act No. 10173), it should be retained only as long as necessary for the purpose it was collected for, for legal claims, for legitimate business purposes, or as the law provides. Write a retention period for declined and withdrawn files into your privacy policy, and record consent the way you do for approved files, as in our borrower consent log guide. This is general information, not legal advice; confirm your retention period with your data protection officer or counsel.
Who this is for, and who can skip it
This works best for SEC-registered lending and financing companies and microfinance desks closing roughly 20 or more applications a week, where patterns start to show within a month. For multi-branch lenders, the same codes across branches show whether a problem is one branch’s habit or company policy.
If you only see a handful a week, keep the codes anyway and review monthly instead.
Setting it up without new tools
A spreadsheet is enough to start. Add a dropdown column with the fixed codes so nobody can type their own, add the columns from the table above, and freeze the code list on a separate tab with the meaning and fix owner next to each code. A pivot or COUNTIF by code and week gives the Monday numbers in a minute, from records kept the day each file closed rather than rebuilt from memory.
Where PesoLend fits today
In PesoLend, applications submitted through the public apply form land in an officer review queue, where each one is approved or rejected and the officer can leave a review note; approved applications can then be converted into a borrower file. Disbursements and repayments go through branch maker-checker approval, with the checker’s note kept on the approval record. PesoLend doesn’t have a dedicated decline-code field or a decline-reasons report, so the practical setup is to start each review note with the code (for example, “D-DOC: payslip not sent after two reminders”) and keep the weekly count in the spreadsheet described above. Existing teams can log in to PesoLend to review their application queue before Monday’s huddle.
Frequently asked questions
How many decline reason codes should a small lender have?
Eight to ten. Fewer than six and everything lands in a catch-all; more than twelve and officers pick inconsistently. Add a code only when the monthly catch-all review shows a clear, repeating reason.
Should we tell applicants the exact code?
No. The code is an internal label. Tell the applicant what is needed or what was decided in plain language, as in the scripts above. “D-INC” means nothing to a borrower; “we can review a smaller amount” does.
What if an application has two equally strong reasons?
Pick the one that came first in your process and would have stopped the loan on its own. Put the second reason in the note.
Does a withdrawn application need a code if the borrower never told us why?
Yes, use W-OTHER, then make one follow-up call. If W-OTHER becomes one of your top two codes, that tells you the follow-up calls aren’t happening, which is itself a fix to make.
What to do next
Print the starter list, agree on it with your officers in one short huddle, and make it mandatory from tomorrow. Set up the tally sheet today, put the first 15-minute review on next Monday’s calendar, and assign a fix owner to each code. After four Mondays you’ll know where your applications really go, and the first fix is usually cheaper than you expected.