Two kinds of files

Every application your credit union receives goes one of two ways. The clear ones are approved or declined by the decision engine in your loan origination system, in seconds, on the rules your team configured there. That part works, and nothing on this page is about changing it.

The rest go to a person. A thin file, a used vehicle over the LTV line, income that needs a second look, a member the dealer is pushing for. At some credit unions that is a third of the applications; at others it is most of them. It is where the hours go, and it is the queue underwriting automation is for.

What a person does with a file today

An underwriter opens the file beside a copy of the lending policy. Sometimes the policy is a PDF in another window. More often it is memory. They check the rules they know to check, in the order they always check them, until one fails. If one fails, the write-up usually names that rule and stops there. If none do, they move on.

On a quiet Tuesday with an experienced underwriter, this works. On a Saturday with the dealer queue backed up and the newest hire on shift, the rules that get checked are the ones someone remembers. Nobody is doing anything wrong. The policy is long, and it is being applied by hand, one file at a time.

Sample application Policy rev. Sep 2026

Used auto · $28,750 · 60 months

102 of 102 rules checked

3 need attention

  • Needs attention: Maximum LTV, used vehiclesLimit 90% 104.6%
  • Needs attention: Maximum term, used vehiclesLimit 54 months 60 mo
  • Needs attention: Proof of incomeTwo paystubs or a YTD return Not in file
  • Passes: Debt-to-incomeLimit 40% 32.5%

+ 98 more passed

Counter within policy

$24,750 financed · 54 months

Brings LTV to 90%. Subject to proof of income.

A file as the underwriter opens it: every rule checked, three that need attention, and a counter within policy. Illustrative, not member data.

What automation changes

With the policy applied by software before the file reaches a person, four things change.

  • Coverage. Every rule is checked on every file, not the dozen someone remembers. The long tail of the policy, the rules about seasoning and co-signers and the second vehicle, stops being optional.
  • Order. Nothing is missed because the first failing rule ended the review. All three reasons a file needs attention are visible at once, which is what the counteroffer and the adverse-action notice both need.
  • The write-up. Each result names the rule it came from and the value it checked. The underwriter writes a sentence of judgment instead of a page of arithmetic.
  • Speed. Decisions come back while the deal is still warm, because the underwriter opens a file that is already checked.

What it does not change

The underwriter still decides. The policy is still your board’s, owned and changed by your team. The LOS still receives the application, decisions the clear ones, and books the loan. Underwriting automation of this kind sits beside all three, read-only, and asks none of them to move.

Six questions to ask any vendor

Whatever you look at, including Sidecar, these questions separate coverage from a demo.

  1. Does it check every rule in the policy, or a configured subset?
  2. For each rule, does it show the value it checked and the limit it checked against?
  3. Who writes and changes the rules: your team, or the vendor’s configuration staff?
  4. Does the LOS have to change, or does it work beside what you run?
  5. What happens on the day the policy changes? How long until every file is checked against the new rule?
  6. When an underwriter approves outside a rule, is that recorded as an exception, with the reason?

Where Sidecar fits

Sidecar is underwriting automation of this kind: a rules engine that holds your lending policy as rules written in plain English, checks every file that needs a person against all of them, and shows its work. Your team owns the rules. Your underwriters make the decision. Your LOS stays as it is.