Problem loan management software is the system that keeps a bank's watch list — the credits graded special mention, substandard, doubtful or loss — current between committee meetings, and turns it into the decisions the committee has to take: upgrades, downgrades, moves to non-accrual, transfers to the workout team. The work is hard to buy well because most of it is not reporting. It is reading documents that arrive on their own timetable, recomputing numbers the way a particular loan agreement defines them, and showing a credit officer the source of every figure she is about to defend. Botminds' Problem Loan Management does that part — one current page per troubled loan, each line cited to its document — and deliberately stops short of the decisions, which are votes a bank's own officers take and sign. This guide is about how to tell the difference when you are evaluating anything in this category, including ours.
The regulatory expectations below are the federal banking agencies' own. The worked figures are the solution's sample data on a fictional bank and are described as such.
Three numbers to hold any system in this category to
Same day
from a document arriving to the line it changes being rewritten, with its source attached
Both
schedules recomputed on every modified loan — the one the borrower signed and the one the bank granted
0
decisions the system takes on its own: no grade, no accrual status, no transfer, no borrower contact
What problem loan management software is, and what it is not
It is not a loan origination system, and it is not the core. The core knows what the borrower owes today and what it has paid; it does not know that the plant was revalued last week or that the sponsor's promised equity never arrived. It is not a customer relationship tool with a credit module bolted on, because the unit of work is a credit's file rather than a contact history. And it is not a reporting layer over the loan system, because the facts the report needs are mostly not in the loan system at all.
What it is, functionally, is three things fused: a reader of the credit file, a calculator that applies each agreement's own definitions, and a drafting surface that produces the pages a committee votes from. A product that does only the third is a document generator and will be fed by the same manual work it was bought to remove.
The test to apply to any demonstration is simple and awkward to stage: ask what happens when a document arrives that nobody expected. A new appraisal, an amendment, a late certificate. Who reads it, how long before it reaches the page, what it recomputes, and where the committee sees that it changed something.
The job the regulation gives the system
The specification already exists, and it is six lines long. A bank must keep a system, sized to its business, that identifies problem assets and stops them deteriorating, and that system should review asset quality periodically, estimate the losses inside problem assets and reserve for them, compare the problem totals with capital, take corrective action on each problem asset, weigh material concentrations, and report periodically to management and the board (12 CFR 364, appendix A, II.G). What each of those duties asks of a board report is worked through in the criticized asset report.
It is worth being blunt about which of those a purchase can touch. Identification, measurement and reporting can be substantially bought, because they are work on information. Corrective action cannot be bought at all: it is calling the borrower, demanding the equity, ordering the field exam, taking the name to Special Assets. Reserving is partly bought and mostly judged. A vendor whose answer to the sixth duty is a dashboard and to the fourth is a workflow with status fields has described a filing habit, not a resolution.
So the honest claim for any product here — ours included — is narrower than the duty. It can make sure the facts a bank acts on are current, complete and traceable, and that the actions it decided on are followed up. The acting is still the bank's.
A requirements matrix for problem loan management software
Must read
Every document and record that changes the picture, in the form it actually arrives: statements and tax returns, compliance and borrowing base certificates, appraisals and valuations, amendments and sponsor letters, payment and overdraft activity, and the relationship manager’s own words.
Must recompute
Spreads and trailing twelve months, every financial covenant exactly as the agreement defines it, debt service on the original schedule as well as the modified one, and collateral coverage at the newest value — every time a document lands, not once a quarter.
Must cite
Each line back to the document behind it, with the date, one click away. A number whose source cannot be opened in the meeting is a number that will be argued about instead of acted on.
Must keep
Every version of every page back to the one the committee last read, so what changed since the last meeting is a fact rather than a recollection, and so a decision can be reconstructed a year later.
Must never decide
The grade, the accrual status, the transfer, the action plan and the contact with the borrower. Those are the bank’s to make, vote and sign.
Three ways banks do this today, and what each one costs in people
Banks run a watch list in one of three broad ways, and the choice is usually historical rather than deliberate. Setting them beside each other makes the trade visible, because each is genuinely better than the others at something.
Three ways to run a watch list, and what each one is actually good at
| Spreadsheet, shared drive and email | Reports out of the loan system | Agents that keep one page per name | |
|---|---|---|---|
| What it is good at | Flexibility. Anything can be recorded, in any form, the week it is needed. | Accuracy on what the core knows: balances, payments, past dues, line use. | Keeping every name current from documents, and showing the source of each line. |
| Where the facts come from | People, re-keyed. The document stays wherever it was filed. | The core only. Documents and covenants are outside its reach. | The documents themselves, read as they arrive, with the record of what each one changed. |
| Covenants and modifications | Recomputed by hand when someone remembers; usually on the amended terms. | Not covered. The loan system holds the terms in force, not the agreement’s definitions. | Recomputed on the agreement’s own definitions and on both schedules, every time figures land. |
| Cost in people | Highest, and it falls on the senior people: days a month per cycle, in reassembly. | Low to run, but the gap it leaves is filled by the same manual work. | The gathering largely goes; the judgement, the calls and the committee stay. |
| What an examiner can test | The conclusion. The path is in people’s heads and inboxes. | The balances. Not the grades or the reasons. | Every line, back to its document, with the dates it moved. |
| Where it fails | Silently, when a document arrives and nobody circulates it. | Silently, when a borrower is current only because of a concession. | Visibly: the page shows what it has not been given, and late statements are flagged rather than assumed. |
What the system has to read, and where each item comes from
A procurement that lists features will miss the thing that determines whether the system works, which is coverage of inputs. Six feeds carry essentially everything a watch list needs, and a product that cannot take one of them leaves a hole that a person will fill by hand for as long as the product is owned.
From the loan system: payments, past dues, maturities and line use. From the deposit system: overdrafts and balance trends — the cheapest early signal a bank owns, because it arrives without asking the borrower anything. From the credit file: statements and tax returns, compliance and borrowing base certificates, appraisals and valuations, amendments and sponsor letters. From the relationship manager: an update in his own words, through one form rather than six email threads. From the bank's own history: the watch list, the grade history and prior committee minutes. And from policy: the rating scale, the Special Assets rules and the committee charter, which are what the whole thing is measured against.
That last feed is the one most often underestimated. If the rating scale and the triggers are built into code rather than held as settings, every policy change becomes a change request, and a bank that cannot change its own thresholds without a release will stop changing them.
Your credit policy as settings, not as code
What it may never do: the authority line, written down
Every product in this category should be able to tell you, in writing and without being pushed, what it will not do. The reason is not caution for its own sake. Grades, accrual status and transfers are decisions a bank's officers answer to examiners for, and a system that takes them has moved an accountability that cannot actually move.
The limits below are the ones built into this solution. They are a reasonable template for the question to put to any vendor, and the useful follow-up is: show me where in the product that limit is enforced, rather than where it is described.
Six agents, and the decisions that stay with people
Agent
Watch list monitorReads every new item on a name and logs it as a change since the last review, with its source; asks the relationship manager for an update when a plan item is due within five days.
Never: Never changes a grade or an action plan.
Agent
Financial spreader and covenant testerSpreads statements into the bank’s template, computes trailing twelve months, and recomputes each covenant exactly as the agreement defines it.
Never: Never treats a waiver as compliance.
Agent
Account activity watcherWatches past dues, overdrafts, line utilisation, borrowing base availability and deposit trends against the thresholds in settings.
Never: Never contacts a borrower.
Agent
Modification screenFinds every amendment, extension, deferral, rate concession, interest-only period and payment-in-kind feature in the last twenty-four months, and computes debt service on both schedules.
Never: Never counts a modification as a cure.
Agent
Grade recommenderTests the facts against the bank’s scale and the supervisory definitions and proposes a change, with each reason cited and the allowance effect stated.
Never: Never sets a grade.
Agent
Committee pack writerOrders the agenda, writes one page per discussion name, puts unchanged names on the consent list, and afterwards drafts the minutes and the action log.
Never: Never records a decision the committee did not take.
A person decides
The committee, and the chairVotes every grade change, every move to non-accrual and every transfer, with a quorum; the Chief Credit Officer signs the minutes.
This is also where to be honest about what the category does not replace. It does not replace the committee, and it does not replace credit risk review: the interagency guidance expects policies that describe the risk rating framework and "establish responsibilities for loan review based on the portfolio being assessed" (SR 20-13), and the OCC expects the rating process itself to be validated independently, over and above what examiners test. A system that keeps the file current makes both of those cheaper to do well. Neither goes away.
How do you pilot problem loan management software on your own names?
On your own names, on your own documents, against an outcome you already know. The only pilot worth running is one where the bank can mark the answer, which means choosing names whose last two committees are on record and asking the system to reproduce the position the bank reached — then explaining every difference.
A four-week pilot on your own watch list names
- Week 1 — choose twelve names and freeze a date
Mix the grades: four special mention, six substandard, two non-accrual. Include at least two with a modification in the last year and one whose collateral has been revalued. Freeze the date as of the committee two meetings ago.
- Week 1 — hand over the file as it really is
The documents in the form they arrive: scans, spreadsheets, an email thread, a certificate with a handwritten note. A pilot run on clean data tests a product the bank will never own.
- Week 2 — score the reading, not the look
For each name: did every document reach the page, how long did it take, and is each line traceable to its source? Count the facts it missed, and the ones it asserted without a document.
- Week 2 — test the covenant arithmetic against your own spreads
Pick the three most awkward definitions in your book. Check that each is recomputed as written, that a waived covenant shows as waived, and that both schedules appear on every modified loan.
- Week 3 — run the frozen date forward and compare
Let it process what actually arrived between the two committees. Compare its proposals with the decisions your committee took, and require a reason for every difference. A system that disagrees with a good reason is more useful than one that always agrees.
- Week 3 — build one package and time it
From the finished pages, produce the agenda, the discussion pages and the consent list. Time the whole cycle, then have the chair read it cold and mark what he had to ask for.
- Week 4 — try to break the authority line
Attempt to have it set a grade, move a loan to non-accrual, alter an action plan or send something to a borrower. Each attempt should fail, and the refusal should be visible to the user.
- Week 4 — change a policy setting yourself
Move a trigger, change a review frequency, add a rating band. If that needs the vendor, the bank has bought a version of its policy rather than a system that holds it.
Proving it: the grade, the number, and the source behind each
The outcome a bank is buying is an accurate, timely grading system, and the supervisors have said which direction of error matters most. The OCC's handbook tells examiners to worry most about ratings that understate risk, while still criticising any significant inaccuracy, because a wrong grade in either direction distorts the picture every other portfolio process relies on (Comptroller's Handbook, Rating Credit Risk); the handbook is read section by section in the guide to the Rating Credit Risk booklet. Accuracy is not symmetric: a system that is late downgrading is worse than one that is quick to.
Timeliness has its own one-line standard in the same handbook — a rating system should be dynamic, with ratings that move when the risk moves — and that is the thing a pilot can actually measure. Take the names whose grade moved in the last year, find the document that should have triggered the move, and measure the distance between the two dates. That distance is the number the bank is trying to reduce, and it is the only number in this category that is both honest and comparable between products.
Why it matters is written most plainly in a review of a failed bank: "an effective, accurate, and timely risk-rating system provides a foundation for an institution's credit risk review function to assess credit quality, and ultimately, identify problem loans in a timely manner" (FDIC Office of Inspector General, material loss review MLR-11-004). Everything downstream — the allowance, the capital comparison, the board report, the examination — rests on grades being right and being right on time. What happens to those totals once they are, and how an examiner tests them, is covered in the criticized asset report.
One page per troubled loan, every line citing the file
Due diligence on the vendor, as the supervisors expect it
Buying this is a third-party relationship, and the interagency guidance sets two expectations that are easy to fail with a vendor the bank already likes. The first is that familiarity is not diligence: knowing a supplier from earlier work does not stand in for due diligence tailored to the specific activity it will now perform (Interagency Guidance on Third-Party Relationships, SR 23-4). An existing supplier moving into credit decisions support is a new activity and gets a new assessment. The guidance as a whole is set out in the guide to the interagency third-party guidance.
The second is a proportionality rule that cuts both ways: the scope and depth of the diligence should match the risk and complexity of the relationship. A system that drafts proposals the committee votes on, and holds the evidence those votes rest on, sits toward the higher end of that scale even though it never moves money.
Practical consequences for the file: establish what the bank can see of how a recommendation was reached, how it would reconstruct a decision taken a year ago, what happens to the pages and the audit trail if the relationship ends, and who validates the rating logic independently of both the vendor and the lending line. None of those are unusual questions. They are simply ones a demonstration never raises on its own.
How long does implementation take, and what does the bank have to bring?
The honest answer is that the elapsed time is mostly the bank's, and the preparation is a credit exercise rather than an IT one. What has to exist before anything is configured is the rating scale with its definitions, the change triggers the bank wants watched with their thresholds, the committee charter with its quorum and cadence, the Special Assets rules, and a sample of watch list files complete enough to be realistic.
From the first document read to the first committee run on it
- Rating scale and definitions, triggers, committee charter, Special Assets rulespolicy
- A sample of real watch list filesfiles
- Settings configured to the bank’s own policyset up
- Connections to the loan and deposit systems and the credit filefeeds
- Backfill: the watch list, grade history and prior minuteshistory
- Parallel run beside the existing process for one cycleparallel
- First committee run from the pageslive
Two sequencing points are worth insisting on. Backfill the history before the parallel run, because a page that cannot show what changed since the last committee cannot be judged by the people who read the last one. And run in parallel for a full cycle, comparing proposals against decisions name by name, because that is the only point at which a disagreement is cheap. In this solution the deployment goes live once every quality check has passed, and it is walked through first on a sample of the buyer's own watch list names for exactly that reason.
Where the deeper workout cases go after the committee has voted is covered in what a special assets department is, and the signals a system should be watching in the guide to early warning systems. To see the pages, the settings and the package on your own names, start from Problem Loan Management.
Questions people ask
Can software set a loan risk rating?
It can propose one, and it should not assign one. The grade is a judgement the bank's officers answer to supervisors and to a board for, and examiners test it by comparing a sample of internal ratings with their own. A sensible design proposes a change with each reason cited to a document and the allowance effect stated, and leaves the assignment to a vote. In this solution the grade recommender never sets a grade; the committee does, and the chair signs the minutes.
Can AI write the credit committee package?
It can write everything that is a restatement of the file — one page per discussion name, the consent list, the agenda ordered by decision weight and exposure, and afterwards the minutes drafted from the decisions as they are recorded. What it should not write is a decision nobody took, which is why the useful design constraint is that minutes come only from recorded votes. In the solution's sample data, building a 44-page package across 41 names took 1 minute 46 seconds.
What should you ask a vendor before buying?
Four questions, in this order. Show me a document I bring being read, and the line it changes. Show me a covenant recomputed on the agreement's own definition, and a modified loan on both schedules. Show me where a line's source opens from the page. And tell me, in writing, what the system will never decide, and where that limit is enforced. Everything else — the dashboard, the integrations, the roadmap — is easier to verify later and harder to be misled by.
How do you evaluate credit risk software for a bank?
Treat it as a third-party relationship with a scope of due diligence proportionate to the risk and complexity of the activity, and do not substitute familiarity with the vendor for assessment of the specific activity — the interagency guidance is explicit on both. Beyond that, evaluate against outcomes the supervisors already name: are ratings accurate, do they change when risk changes, and can the bank reconstruct how each one was reached.
What data does it need from the core system?
Less than most buyers expect, and that is the point. From the loan system: payments, past dues, maturities and line use. From the deposit system: overdrafts and balance trends. Everything else that decides a grade — statements, certificates, appraisals, amendments, sponsor letters, the relationship manager's update — lives outside the core, which is why a product that only consumes core data covers the smaller half of the problem.
Does it replace the loan review function?
No, and a vendor who implies otherwise should be pressed. Credit risk review exists to test independently of the lending line that grades follow the facts, with responsibilities established in policy, and the rating process itself is expected to be independently validated. What a current, fully sourced file changes is the economics of that work: a reviewer who can open the document behind every line spends her time on judgement rather than on reassembling the evidence.