What a model is for
A credit model takes the attributes of an applicant and returns a probability or a grade. Built on enough history, it ranks risk better than a traditional scorecard, which is why credit unions use models to approve more of the members who will pay, to price risk, and to decide which files never need a person at all.
A model needs three things to earn its keep: volume, so the patterns are real; history, so the patterns are tested; and governance, because a model that cannot explain itself is a model the examiner, the board, and the member will ask about. The vendors in this space have put real work into that explanation, and the credit unions that run models take model risk seriously. None of that is a reason not to use one.
What a rules engine is for
A rules engine asks a narrower question: does this file fit the policy the board approved? It takes the lending policy as rules, checks the file against every one, and returns each result with the value it checked and the limit it checked against. Nothing is predicted. The same file against the same policy gives the same answers, and every answer is a sentence in the policy.
It is at its best on the files that need a person: the ones the decision engine referred, the ones with a thin file or a hard collateral question. The underwriter opens a file that has been checked against the whole policy and spends their time on judgment. It needs the policy written as rules, and a team that owns them.
| Aspect | Credit model | Rules engine |
|---|---|---|
| Question it answers | How likely is this member to repay? | Does this file fit our lending policy? |
| What goes in | Applicant attributes, bureau data, and the history of many loans | One file, and the policy as rules |
| What comes out | A probability or grade, and a decision on clear files | A result for every rule: within, outside, or not enough in the file |
| How it explains | Reason codes derived from the model | The rule, the value, and the limit, in the policy’s own words |
| What it needs | Volume, history, and model governance | The policy as rules, and a team that owns them |
| Who changes it | The model vendor, on a retraining cycle | Your lending team, when the policy changes |
| Best at | Ranking risk, clear approvals and declines, pricing | The files that need a person, coverage, the write-up |
Beside each other
The two are not alternatives, because they do not do the same work. The model, inside the LOS, decides which files are clear enough to never need a person. The rules engine makes sure the files that do need one get the whole policy, with its work shown, before the underwriter looks.
A credit union that runs a model and no rules engine has fast clear decisions and a manual queue checked from memory. One that runs rules and no model has every referred file checked against the policy, and no prediction to help with pricing or with growing approvals. Many will want both. The question is not which one, but what each file needs.
Questions to ask about either
- Can it show, for this member, why it said what it said, in words the member and the examiner would accept?
- Who owns the logic: your team, or a vendor’s cycle?
- What happens on the day your policy changes?
- When an underwriter overrules it, where is that recorded, and what does it count as?
- What does it need from the LOS, and what does it leave alone?
Where Sidecar fits
Sidecar is a rules engine, not a credit model. It holds your lending policy as rules in plain English, checks every file that needs an underwriter against all of them, beside the LOS, and shows its work. If your credit union runs a model today, Sidecar does not replace it. It takes the files the model refers.