Did your last policy change do what you expected?
Seven questions every risk leader should be able to answer before a credit rule goes live
Every risk team changes policy. A bureau cutoff moves up by 20 points. FOIR tightens for a segment showing stress. A new income surrogate is allowed for self-employed borrowers. Each change is debated, documented and approved.
Then it goes to production, and the team waits.
For most lenders, the first real feedback arrives a quarter later, when the approval rate has shifted, sourcing is complaining, or early delinquency on the new cohort starts to show. By then the book has already been written on the new rule. If the change was wrong, the cost is already in the portfolio.
So the question this blog is built around: how much do you actually know about a policy change before it goes live? Try these seven.
1. How many approvals did your last cutoff change cost you?
Not the estimate from the committee note. The actual number. If your bureau floor moved from 700 to 720, how many applications approved last quarter would now be declined? Which segments carried the loss? Which sourcing channels?
Most risk teams can answer this three months after the fact. Very few can answer it the day before.
2. How many of those declines were good customers?
Every tightening removes some bad loans and some good ones. The ratio is the whole point. A change that removes 8% of volume and 30% of expected losses is a good decision. One that removes 8% of volume and 9% of expected losses is a quarter of lost disbursals for almost nothing.
Can your team see that ratio before the rule is deployed, using your own historical applications and their actual performance?
3. What did the change do to your deviation rate?
Tighten a rule, and credit managers start approving around it. Deviations climb. The policy on paper says one thing, the book says another, and the gap shows up only when someone pulls the deviation report.
Discover how Decide enables risk teams to simulate policy changes, measure approval and deviation impacts, and deploy version-controlled credit rules faster.
4. Who tested the rule, and against what?
Usually IT tested that the rule executes, with a handful of cases written to confirm the logic. Nobody tested what the rule does to the portfolio, because that means running it against thousands of historical files, and the engine does not make that easy.
The first proves the code works. The second proves the decision is right.
5. How long between approval and production?
Policy approved on Monday. Change request raised on Tuesday. Estimated, scheduled, built, tested and released over the next four to six weeks. In between, the book runs on old parameters while the documentation says otherwise.
Under the RBI’s draft guidance on model risk management, that gap is precisely where supervisors will probe.
6. If the change is wrong, how fast can you roll it back?
If every version of every policy is stored with an owner, a timestamp and the results that justified it, rolling back is a decision. If the rule lives in application code, rolling back is another change request.
7. Who owns the rule once it is live?
Risk wrote the policy. IT wrote the rule. When the two disagree, which one is the institution actually running?
What simulation changes
Celusion built DECIDE so the people who write credit policy can also test it and deploy it. A risk analyst takes a proposed change, runs it against the institution’s own historical applications, and sees the result before anyone touches production: approvals gained, approvals lost, the shift in deviation rate, the segments and channels most affected. If the numbers hold, the same team deploys the rule, version-controlled, with no release cycle in between. If they do not, the rule never leaves the sandbox.
Rules are authored in logic as familiar as an Excel formula, so the specialist layer between policy and production disappears. Every version is retained with its owner and timestamp, which is the audit trail the model risk guidance expects.
SK Finance automated more than 200 login validations on DECIDE and now clears 98% of applications without rework. Different problem, same principle: when the business team owns the rule, the rule matches the business.
One last question
Pick the policy change sitting in your approval queue right now. If you could see its effect on last quarter’s book before it went live, would you still deploy it as written?
If you are not sure, that is the case for running it through DECIDE first. Thirty minutes is enough to see one of your own pending changes simulated against your own data.
