Commercial loan management software and the request before the booking

Commercial loan management software is the system that holds a commercial loan after it exists: the commitment, the balances, the accruals, the amortisation, the payments applied, the fees, the statements and the regulatory extracts. It is the system of record, and the good ones are very good at it. What almost none of them hold is the half-hour before the loan moves — the borrower's emailed notice of borrowing, the payoff letter from another lender, the rate election that is a day short of its notice period, the changed wire instruction that must be telephoned about before anything is released. Botminds' Drawdown & Payoff Request Processing is built for that half-hour, and it is deliberately not a system of record.

This guide is written for the head of loan operations or the COO who is choosing, replacing or extending a servicing platform while the funding desk is already running late most afternoons. The scale figures come from the federal banking agencies; the desk figures come from the solution's own sample data, on fictional borrowers.

What commercial loan management software actually covers

Strip the category names away and three different products are usually being discussed in the same meeting. Origination software takes an application to a credit decision and a closing. The servicing or management system books the resulting loan and runs it for its life. And a thin, usually invisible layer of spreadsheets, shared mailboxes and someone's personal checklist handles everything the borrower asks for in between.

The system of record's job is defined by what it must be right about: the balance, the accrual, the next payment date, the fee, the extract that goes to a regulator. Those are stock questions, asked of a state the system itself holds. Everything about that design is sound, and it is why you should not try to make it do the other thing.

The other thing is a flow question asked of documents the system has never seen. Is this notice in on time, under this agreement's own clause? Is there availability, once the borrowing base certificate delivered last week is applied? Is the person who signed still on the incumbency certificate? Is this account the account we have always paid? Not one of those can be answered from the loan master file, which is why the desk answers them by opening four other things.

The gap your system of record leaves: everything before the booking

The gap is not an oversight; it is a boundary, and the examiners describe what sits on the far side of it. The FDIC's Loan Operations Review module asks the examiner to verify whether commitments "are limited in amount, cover a specific period, and indicate the conditions that must be satisfied before draws will be honored", and, separately, to "determine whether controls help ensure loans are booked with the same terms as approved". Those two questions are the gap, stated by the people who will ask them of you.

Read the first one closely: conditions that must be satisfied before draws will be honored. A system of record records that a draw happened. It is structurally incapable of demonstrating that the conditions were satisfied first, because the conditions live in a signed agreement and a certificate it has never read. Whatever answers that question in your bank today — a checklist, a second pair of eyes, a long-serving specialist's memory — is the system the examiner is asking about, whether or not it is software.

The size of the gap can be estimated in an afternoon. Take last month's draws, payoffs and rate elections; count them; multiply by the minutes it takes to check one by hand; and compare that with the hours the desk actually has between the morning post and the cut-off. On many commercial desks the two numbers do not reconcile, and the difference is being absorbed by checks that are performed quickly rather than performed fully.

Replace, extend, or configure what you already run?

The buying question is usually posed as which system is best, and that is the wrong question because the three candidate answers cost between nothing and several million. Pose it as which gap you are filling and the field narrows immediately.

If the accruals are wrong, the extracts are late or the amortisation cannot handle your structures, that is the system of record, and the answer is replace or upgrade it: a long, expensive, unavoidable project. If the system of record is sound and the afternoon is the problem, replacing it will not help, because the afternoon's work was never in it. That is an extend, and it is a much smaller purchase than the one people arrive intending to make.

The third answer is the one worth testing first and few banks do: configure. Some of the afternoon's pain is not missing software but missing settings — a cut-off that was never written down, an approval limit that lives in someone's head, notice defaults that were set once and never re-read against the agreements. A desk that cannot state its own cut-off, its own second-approval limit and its own call-back triggers from memory should fix that before it buys anything, because every vendor will ask for exactly those three numbers in week one.

There is a fourth answer that gets chosen by default and deserves to be chosen deliberately or not at all: add a person. One more specialist absorbs a surprising amount of volume, costs less than most projects, and starts on a Monday. What it does not do is make the checking consistent — two people performing nine checks by hand produce two slightly different desks, and the one that is quietly skipping the signer check against the incumbency certificate is invisible until the day it matters. If the problem being solved is volume, hire. If it is variance, hiring makes it worse.

What should you ask a vendor about draws, payoffs and changed instructions?

Demonstrations are built to succeed. The questions below are the ones that distinguish a product that handles the awkward afternoon from one that handles the tidy one, and each has a right answer that a vendor either gives or evades.

One question deserves expanding. Asking which rules cannot be changed sounds like a complaint about inflexibility and is actually the opposite: it is how you find out whether the product contains a control or merely a workflow. On the sample desk two things are not settings. The release button stays locked while any check is open, and that cannot be turned off. And the particular agreement's own clause always beats a bank-wide default, so no configuration screen can quietly relax a notice period that a borrower negotiated.

The honest test of a system is which of these are settings

What you have to bring: agreements, certificates and the payee file

Every implementation of this kind of software succeeds or fails on five inputs, and four of them are documents the bank already has in a form nobody has had to assemble before. The honest version of the project plan starts with finding them, not with configuring anything.

One question decides how week three goes: who in the bank owns assembling that list. It is not a technology task and it is almost never staffed. The amendments sit with relationship managers, the certificates with credit administration, the incumbency file with the loan closers and the payee data with payments, and none of those four teams has a reason to prioritise a project they did not ask for. Name one person, give them the authority to ask across all four, and start them before the contract is signed; few decisions in the implementation return more.

How long does it take to go live, honestly?

Any number given without knowing the state of those five inputs is a guess, and a vendor who gives one anyway has told you something about how the project will go. The useful answer has a shape rather than a duration: three phases, of which only the middle one is about software.

The parallel run is the phase buyers try to shorten and should not. For three weeks every request is checked both ways, by the desk as it works today and by the new process, and the two answers are compared. Disagreements are the whole product of that phase: each one is either a configuration error, a missing document, or — often enough to be worth the exercise — a check the desk has been performing incorrectly for years.

"Live, limited" means live for a subset: one facility type, or one portfolio, or every request under a stated amount. Going live for everything on a Monday converts a manageable set of surprises into an afternoon nobody forgets.

Third-party risk stays yours, whatever the contract says

Buying this kind of software hands a part of a control to somebody else, and the supervisory position on what that does to accountability is settled. The interagency third-party guidance adopted by the OCC, the Federal Reserve and the FDIC in 2023 asks a bank to scale its third-party risk management to its own risk profile and complexity and to how critical the activity the third party supports is (OCC Bulletin 2023-17).

Read the last clause as a sizing instruction. A tool that reformats statements is one thing; a tool that stands between a payoff letter and a Fedwire release is a critical activity, and the diligence should match. In practice that means three things the procurement team will not ask for on its own: what happens to the desk if the service is unavailable at 3:40 p.m., where the bank's agreements and payee data are held and who can read them, and what the bank's own people can see about why a particular result was produced.

The same principle governs how the thing is evaluated. The agencies' model risk guidance — SR 26-2, which replaced SR 11-7 on 17 April 2026 — treats validating vendor products as an important part of managing them, and expects ongoing monitoring and outcome analysis of whether a bought model stays accurate and fit for purpose (revised guidance, section VII). It also places generative and agentic AI outside its own scope and leaves their controls to the bank's governance, which is no licence to examine them less. A bought component is not an unexamined one.

Measuring it afterwards: four numbers, not a demonstration

A purchase that cannot be measured will be re-argued every budget cycle. Four numbers, all of which can be captured before the project starts, settle it.

The first is turnaround against your own cut-off: the minutes from a request arriving to every check being complete, and the proportion that finish with more than an hour to spare. The second is what the desk did with the exceptions: how many requests were held, for which reason, and how long each took to resolve — a desk that holds nothing is not careful, it is unaware. The third is call-backs made and instruction changes caught, which is the only direct measure of the control that matters most. The fourth is rework: requests actioned and then corrected, which should approach zero and whose causes are more useful than its value.

Capture all four for a month before anything changes. Few banks do, and it is the reason these projects are defended with anecdotes.

The desk, with the clock on it

Where Drawdown & Payoff Request Processing fits, and where it does not

It sits between the borrower's request and your system of record, and it stops at both ends. It reads every draw, payoff, paydown, rate election and payoff-quote request as it arrives by email, fax or portal; matches it to the facility; tests it against the agreement, the loan system's balances, the latest certificates, the incumbency file and the verified payee file; and puts it on one release console where a person releases.

What it is not: it is not a system of record. It does not book loans, keep balances, accrue interest, apply payments or produce regulatory extracts, and it should not be bought by a bank whose actual problem is any of those. It does not release money — it builds the payment instruction and a person sends it. It does not edit the payee file. And it does not replace the relationship manager's conversation with a borrower whose draw has been held; it gives that conversation the clause and the date that would work.

If the gap in your afternoon is the request before the booking, that is the shape of the thing to buy, whoever you buy it from. If your system of record is the problem, nothing on this page helps. What a notice of borrowing has to survive is the best short description of the work the desk is actually doing, and the solution itself shows it running end to end.

Questions people ask

What is commercial loan management software?

It is the system that administers a commercial loan after booking: commitments and balances, interest accrual on the agreement's day-count basis, payment application, fee billing, escrow where it applies, participations, statements and regulatory extracts. It is a system of record, measured by whether its numbers are right. The request traffic that arrives before any of those numbers change — notices of borrowing, payoff letters, rate elections — is a different job and is usually handled outside it.

How do you evaluate commercial loan management software?

Separate the system of record from the request desk and evaluate each against its own failure. For the system of record, test the structures your book actually contains: multi-tranche facilities, delayed-draw terms, odd day counts, participations. For the request desk, test the awkward afternoon: a changed payoff account, a notice forty minutes late, a signer removed by a certificate. Ask every vendor to show a case its product gets wrong.

Can loan management software read a credit agreement?

Traditional servicing systems do not; they hold terms that a person keyed in at booking, which is why a March amendment that nobody re-keyed is such a common source of error. Products that read the agreement itself do exist, and the question to ask them is not whether they can read but what they do when they are unsure: the acceptable answer is to ask, cite the clause it relied on, and stop — never to fill in a value it did not find.

What is the difference between a system of record and a servicing workflow?

A system of record owns state and must be right about it. A workflow owns a sequence of decisions and must be able to show why each was made. They fail differently: a wrong system of record produces a wrong number that is later corrected, while a wrong workflow produces a right-looking action that cannot be undone, such as a released payment. That is why controls, approvals and evidence belong to the workflow and reconciliation belongs to the system of record.

How much does commercial loan management software cost?

Published pricing is rare and comparisons are unreliable, because the licence is usually the smaller half. The costs a business case should carry are implementation and data assembly, interfaces to core banking and the general ledger, the parallel run, and the internal time to write down the rules the desk has never written down. Ask any vendor for the fully loaded cost of three named comparable banks' implementations, not a licence figure.

Who owns third-party risk for a servicing vendor?

The bank does. The interagency guidance frames third-party risk management as the bank's own practice, scaled to how critical the activity supported by the third party is — and software standing between a payoff letter and a released wire is about as critical as a servicing function gets. Contractual indemnities change who pays afterwards; they do not move the supervisory expectation or the operational consequence of a payment that left on a Friday afternoon.