Auto-Approve, Refer, or Decline: Introducing the ExactSum Decision Engine

Most underwriting queues have the same problem: a handful of files genuinely need a human, and the rest are obvious. Obvious yeses sit waiting next to obvious nos, and the cases that actually deserve attention get the same slot as everything else.

The ExactSum Decision Engine fixes the ordering. Every set of statements is scored against your underwriting rules and returned with one of three outcomes: Auto-Approve, Refer to Underwriter, or Decline. The clean files clear themselves. The grey area lands on a desk. The obvious declines stop wasting time.

How a Decision Gets Made

Once a project's statements have been parsed, the engine runs four steps:

1. Aggregate. Every transaction in the project is rolled up into a set of underwriting metrics — cashflow, balances, revenue, concentration, tax behaviour, and more.
2. Load rules. Your organisation's active ruleset is loaded. Each rule carries its own thresholds for pass, refer, and fail.
3. Evaluate. Each rule is checked against the metrics. A rule can independently pass, refer, or fail.
4. Decide. The overall result is the worst outcome across the rules. One fail means Decline. One refer means Refer to Underwriter. All pass means Auto-Approve.

The logic is deliberately strict. Underwriters don't want an engine that quietly averages a red flag away — they want the one thing that broke the file surfaced and explained.

What It Measures

The engine computes a battery of metrics drawn from the full transaction history, covering average daily balance, net cashflow, total revenue, customer concentration, headroom against monthly outgoings, director-transfer share, and tax-payment behaviour. Each metric can feed multiple rules, so the same number drives both affordability and compliance checks without recalculation.

Crucially, the engine always uses all project transactions — not a sample, not a recent window. The statement coverage you've uploaded is the statement coverage the decision is made on.

Rules in Practice

Every organisation runs its own ruleset, and thresholds are fully configurable. A few examples to show the shape of what's possible:

• Account verification — the account holder on the statement matches the borrower on file.
• Customer concentration — revenue isn't dangerously dependent on a single counterparty.
• Unpaid and returned items — bounced direct debits and returned payments are caught and weighted to your tolerance.
• Headroom ratio — average balance comfortably covers committed monthly outgoings.
• Tax compliance — PAYE and VAT payments line up with the months covered, and HMRC enforcement indicators trigger a referral.
• Trend and seasonality — cashflow is stable or improving, and monthly deposits don't swing outside an expected range.

That's a flavour, not the full list. Sector exceptions (a law firm's director-account behaviour looks very different to a builder's), bespoke fraud flags, and lender-specific policy rules are all in scope. If you can write the rule down, we can wire it in.

Why Underwriters Like It

• The work shrinks. Auto-Approve and Decline outcomes take a glance to sign off. The middle stack is where the day actually goes.
• The reasoning is visible. Every decision shows which rules passed, referred, or failed, with the metric that drove it. No black box, no "the model said so".
• Policy stays in policy. Thresholds live in your ruleset, not in someone's head. Tighten a limit on Monday and every project from Tuesday onwards reflects it.

Availability

The Decision Engine is available on the Enterprise plan, and as an add-on module for customers on other plans. We'll work with you to translate your existing underwriting policy into a starting ruleset and tune the thresholds from there — contact us to set yours up.