# Underwriting Rules Engine: Knockout Rules for Statements - Author: TrueBankFlow (https://www.truebankflow.com) - Published: 2026-08-27 - Updated: 2026-08-27 - Category: Analysis software and reports - Canonical: https://www.truebankflow.com/blog/underwriting-rules-engine > What an underwriting rules engine does with statement data: knockout rules, NSF limits, deposit minimums and why every rule needs a human override. An underwriting rules engine applies a lender's written credit rules to the figures from a borrower's bank statements and returns pass, refer or decline for each rule. With statement data it typically checks NSF and overdraft counts, minimum average deposits, balance floors and existing debt payments. Every rule still needs a named person who can override it. ## What does an underwriting rules engine do with statement data? An underwriting rules engine reads figures that statement analysis has already produced, compares each against a threshold in the lender's credit policy, and records the outcome. It does not read statements itself. Its output is a list of rule results that tells an underwriter where a file stands and what to look at first. ### Inputs the engine reads Statement analysis supplies the engine with numbers such as: - Average monthly deposits, total and qualifying - Number of statement months and accounts covered - NSF and overdraft events, by month - Average and lowest balances - Recurring debits that look like loan or advance payments - Flags for large or unusual deposits still unexplained ### Outputs the engine returns For each rule, the engine returns a result. Most lenders use three: **pass** (the file meets the rule), **refer** (a person must look), and **decline** (the file fails a knockout). The engine should also return which input drove the result, so a reviewer does not have to guess. ### Where the analysis tool ends Analysis software and a rules engine are different jobs. TrueBankFlow, for example, organizes and summarizes what is in the statements and states plainly that it does not make a credit decision. Its averages, NSF counts and flags are the kind of figures a lender's own rules can read, while the rules and the decision stay with the lender. ## Knockout rules built on bank statement figures A knockout rule is a rule that ends a file early when one statement fact falls outside policy, whatever else the file shows. Knockouts save time on applications that cannot be approved, so underwriters spend their hours on files that can. They should be few, clear and tied to written policy. ### An example rule table The rules below are examples of the form, written for a fictional small business lender. The thresholds are illustrations, not recommendations. Each lender sets its own from its credit policy and loss history. | Rule | Input | Example threshold | Outcome if breached | Override allowed by | | --- | --- | --- | --- | --- | | Minimum history | Statement months provided | Fewer than 3 | Decline | Credit manager | | Revenue floor | Average monthly qualifying deposits | Below 10,000 | Decline | Credit manager | | NSF limit | NSF and overdraft events, last 90 days | More than 4 | Refer | Senior underwriter | | Balance floor | Average daily balance, last 3 months | Below 1,000 | Refer | Senior underwriter | | Existing advances | Distinct recurring advance payments | 3 or more | Refer | Senior underwriter | | Unread pages | Statements that failed a balance check | Any | Refer, no auto-decline | Any underwriter | ### Decline versus refer Not every rule should decline. A file with too few months of statements can be declined with confidence, because the evidence is missing. A file with a cluster of NSF events may have a clear explanation, such as one late customer payment, so that rule refers the file to a person. Reserve the decline outcome for facts that no explanation could change. ### Knockouts and adverse action A decline from a knockout is still a decline. The lender must be able to state the reasons, which means each knockout needs a plain-language description that matches what the engine actually checked. ## How should NSF limits be written as engine rules? An NSF limit rule should name four things: what counts as an event, the time window, the count that triggers the rule, and whether events on one day count once or separately. A rule missing any of these will be applied differently by different people, and the engine will do whatever its default happens to be. ### Define the event Decide whether the rule counts non-sufficient-funds returns only, or overdrafts paid by the bank as well. Decide whether a fee the bank later refunded still counts. Write the answer into the rule, because the statement shows both cases and the analysis can count either way. ### Choose the window A count over the whole lookback treats a bad month a year ago the same as a bad month last week. Many lenders weight recent months more by using a short window, such as the last 90 days, alongside a longer one. Two rules with two windows are clearer than one rule with a complicated formula. ### Count per item or per day A day when four checks bounce can be four events or one. Per-item counting punishes a business that writes many small checks. Per-day counting can hide a large problem in one bad week. Pick one, write it down, and make sure the analysis you feed the engine counts the same way. ## Deposit minimums and balance floors in a rules engine Deposit minimums and balance floors are thresholds on the money flowing through and sitting in the account. A deposit minimum sets the smallest average monthly revenue the lender will consider. A balance floor sets the lowest average or daily balance it accepts. Both depend on which deposits are counted. ### Qualifying, not total A deposit minimum should test qualifying deposits, after transfers and one-time items are removed, not total deposits. A business that moves money between its own accounts can show far more deposits than it earns. If the engine reads total deposits, the minimum tests the wrong number. ### Sizing the minimum to the request A fixed revenue floor ignores the size of the loan. Some lenders add a second rule that compares the proposed payment with monthly qualifying deposits, so a small business asking for a small loan is not knocked out by a floor meant for larger requests. Express that rule as a ratio and state the input it reads. ### Balance floors and timing Balances swing within a month. A business that pays payroll on the first may look thin on the second and healthy by the fifteenth. An average daily balance is fairer than a month-end balance. If only month-end balances are available from the analysis, set the rule to refer, not decline. ## Why does every underwriting rule need a human override? Every underwriting rule needs a human override because fixed thresholds meet cases they were not written for: a one-time NSF cluster with a documented cause, a seasonal business in its slow month, a transfer misread as revenue. An override lets a named person record why the rule does not fit this file, and keeps that reason in the record. ### What a good override looks like An override records the rule, the input value, the person, the date and the reason, in words. "Overridden" is not a reason. "Four overdrafts in August caused by a delayed customer payment of 18,000.00, received 2026-09-03, statement in file" is. ### Who may override what Match override authority to the weight of the rule. In the example table above, an unread page can be cleared by any underwriter once the missing page arrives, while the revenue floor needs a credit manager. Writing that into the engine stops overrides from drifting to whoever is least cautious. ### Watch the override rate If one rule is overridden on most of the files it touches, the threshold is probably wrong. Review override counts by rule every quarter. A rule that is always overridden is not protecting anything; it is just adding a step. ### When work is sent out Lenders that send statement analysis to an outside team should make sure the override record stays with the lender. [Outsourcing bank statement analysis](/blog/outsourcing-bank-statement-analysis) covers what to keep in-house. ## Bad rules engine inputs from misread statements A rules engine is only as good as the figures fed into it. A misread page, an uncaught transfer or a deposit counted twice changes the input before any rule runs, and the engine returns a confident result on a wrong number. Most bad outcomes trace back to the analysis, not the rule. ### Inputs that commonly go wrong - **Transfers counted as revenue.** Money moved from the borrower's savings into checking inflates deposits and can carry a file over a revenue floor. [Interaccount transfer detection](/blog/interaccount-transfer-detection) explains how those pairs are matched and where matching fails. - **Missing pages.** A statement with a page missing can show fewer NSF events or lower deposits than the borrower had. - **Wrong period.** An analysis that covers 11 months when the rule assumes 12 shifts every average. ### Guard the engine Two checks stop most of this. First, a statement that fails its balance check, where the opening balance plus transactions does not equal the closing balance, should send the file to refer, never to an automated decline or approval. Second, the engine should log the source of every input, so a reviewer can follow a result back to the statement line. Tools built for that trace, like the ones scored in [what to look for in a bank statement analyzer](/blog/bank-statement-analyzer), make the second check practical. ### Mortgage files and asset rules On mortgage files, statement figures also feed asset rules for reserves and funds to close. Those rules read balances and large deposits, with their own documentation rules, described in [verification of assets for a mortgage](/blog/verification-of-assets-for-mortgage). ## Change logs for rules engine thresholds A change log records every edit to a rule: the old threshold, the new one, who approved it, when it took effect and why. Without it, a lender cannot explain why two similar files a year apart got different outcomes, and cannot tell whether a change improved results. ### What to log 1. The rule name and its plain-language description. 2. The old and new threshold or logic. 3. The effective date and time. 4. The approver and the reason, such as a policy update or a loss review. 5. A test result: how the new rule would have scored a sample of past files. ### Test before switching Before a threshold changes, run the new rule against recent files and compare outcomes with the old rule. Count how many files would move from pass to refer or decline, and look at a few by hand. A change that would have declined files you later approved and that performed well deserves a second look. ### Keep old results readable Store each file's rule results with the version of the rules that produced them. When an auditor or a borrower asks why a file was declined, you need the rule as it stood that day, not as it stands now. If you want statement figures with that kind of trace to feed your own rules, you can [request early access to TrueBankFlow](/get-started).