A policy is already a list of rules

Open your lending policy to the used-vehicle section and you will find a sentence like this one: Maximum loan-to-value on used vehicles is 90% of retail value, including tax, title, and warranty. That sentence has everything a rule needs. A value to check: loan-to-value. A limit: 90%. A condition: used vehicles. A definition of the value: retail, with the add-ons included.

A rules engine takes the policy one sentence at a time and keeps each as a rule it can check on a file. The whole policy becomes a hundred or so of them. Then every application that reaches a person is checked against all hundred, and each one answers: within the limit, outside it, or not enough in the file to say.

One rulePolicy rev. Sep 2026

Maximum loan-to-value, used vehicles

In the policy
“Maximum loan-to-value on used vehicles is 90% of retail value, including tax, title, and warranty.”
As a rule
Used vehicle: loan-to-value, with tax, title, and warranty, at most 90% of retail value.
On this file
104.6% of $27,500 retail · Needs attention
The sentence in the policy, the rule it becomes, and the result on one file. Illustrative.

Why the rules should read like the policy

There are two ways to hold a rule. One is code, or a vendor’s configuration screen, where the sentence above becomes a condition only a specialist can read and only a ticket can change. The other is plain English: the rule reads like the policy, so the people who wrote the policy can read it, check it, and change it.

The difference shows up on the Monday after a board meeting. If the rule is the sentence, the person who changed the policy changes the rule, and every file after that is checked against the new one. If the rule is code, the change waits in a queue, and underwriters carry the new limit in their heads until it ships.

Rules, scorecards, and models

A rules engine answers one question: does this file fit the policy? It is deterministic. The same file against the same policy gives the same results, and each result points at a sentence your board approved.

A scorecard or a credit model answers a different question: how likely is this member to repay? It weighs attributes and returns a number or a grade. That is useful for ranking risk and pricing it, and most credit unions already have one inside the LOS. The two are not rivals. The model is good at the files that never need a person; the rules engine is for the files that do. The comparison, in more detail.

What to look for

  • Every rule, every file. Not a sample, and not the dozen a configuration project got to before launch.
  • Each result shows its work. The value, the limit, and the sentence in the policy.
  • Your team owns the rules. Reads them, changes them, and can show the board the version in force on any date.
  • It needs nothing from the LOS. Beside it, read-only, with no integration project before the first file.
  • Approvals outside a rule are visible. When an underwriter steps over a line on purpose, the file shows which rule, by how much, and why. More on exceptions.
  • Policy changes are dated. Every file knows which revision it was checked against. More on policy changes.

Where Sidecar fits

Sidecar is a lending rules engine for credit unions. Your lending policy becomes rules in plain English, owned by your team. Every file that needs an underwriter is checked against all of them, beside the LOS you already run, and every result shows its work. The underwriter decides.