What is a decision engine?
Last week, you left a credit policy meeting with an agreed change: a new income threshold and a referral band. The decision is made, but the lending system’s next release is the earliest anyone says it can go live. You have been asked to look at decision engines, so you open vendor pages between the meeting and the release planning. One calls the product a rules engine, another a decisioning platform, and another a decision engine. One leads with a scorecard. You are trying to connect those labels to the change already waiting on your desk. What would actually change for this threshold?
The income change enters the decision flow
A decision engine runs a decision flow: it takes the inputs sent to it, runs the configured decision logic and returns the result, or reports when the run stops before an outcome. The decision engine brings the policy and its inputs into one recurring decision.
Your lending system sends the credit application data, including income, and a data source calls the bureau for its information. A rule set applies the hard rules, including the agreed income threshold. The scorecard calculates the score, and a decision table maps the score band to an outcome. A decision table is one way to set those bands. A machine learning model can also produce a score inside the flow when the policy uses one.
The referral band and the approve and decline bands determine what happens to the application after those checks. The income threshold changes which applications pass that rule and which applications are approved, referred or declined.
What the scorecard and engine do
A scorecard turns applicant characteristics into a score. A decision engine runs the wider decision flow around that calculation, from the data and policy rules to the application’s outcome. On its own, a scorecard does not set the policy for the application or define how the score leads to an outcome.
A rule set applies hard rules such as the agreed income threshold. The scorecard takes the applicant’s characteristics and writes a score into the data for later parts of the flow. A decision table then maps the score band to approve, refer or decline.
The wider flow defines which data it calls for, which rules run before the score and how the score bands lead to outcomes. It also defines the policy response if an outside data call fails.
Missing inputs and uncovered bands change outcomes
Before deciding whether the flow fits your policy, inspect the outcomes it returns when an application takes an unexpected path. The outcomes below describe documented product behaviour.
In the income example, an empty value counts as zero in a numeric comparison. If the bureau call fails, the bureau step is marked as failed and the rest of the flow carries on. If a score of 35 reaches a fork whose bands cover 0 to 30 and 40 and above, no branch matches. A missing date produces no match in either direction of a date comparison. The documented decision run outcomes distinguish these cases from a step that cannot complete, which stops the run with an error.
| What happened | What it means | What comes back | What to do |
|---|---|---|---|
| A data source did not answer | The data source did not answer, answered with an error, or could not use its credential. The step marks its own result as failed and the rest of the flow carries on | A decision, with an error on that step | A rule that branches on the step's error |
| A number is empty, false or null | It counts as 0 in a numeric comparison | A decision made as if the value were 0 | An "is not a number" condition placed first |
| A date is missing | A date comparison matches in neither direction | A decision | A test for the missing value, and a branch on that |
| No branch of a fork matches | The run ends at the fork | HTTP 200 with everything computed up to that point | A final branch with the "any value" condition, pointed at manual review |
| A step could not complete | The run stops at that step | HTTP 500 with a reason, which is not a decision | The attribute mappings on the named step, checked against the data you send |
A failed bureau call leaves a decision in the response, and an unmatched fork returns HTTP 200 with only the work completed before the fork. A step that cannot complete returns HTTP 500. Check both the response status and its contents to confirm whether the flow reached an outcome.
Write exception handling into the policy
Each of those cases needs a rule in the decision flow. For income, test whether the value is missing or non-numeric before running the threshold comparison, because the comparison reads an empty number as zero. Then define what the policy does with that application.
For the bureau, check whether the data-source call failed and choose the next action in the policy. That could be another provider, a cautious outcome or manual review. If the flow skips the failure check, the rules can read the missing bureau information as no hit.
For the score fork, add a final branch with an any-value condition and point it to manual review. This covers a score such as 35 when the other bands leave a gap.
Test a release before deciding to deploy
Put the agreed income threshold and referral band into a release, then test the ordinary path and the exceptions before production. A release captures the decision flow’s logic. You can test it with sample applications, deploy it to a staging endpoint and then deploy it to production.
Use sample applications for the income threshold and referral band, an empty income value, a failed bureau call and a score of 35. For each result, check whether the intended rule ran, whether the application reached the chosen outcome and whether an unmatched score reached manual review. Run these checks on each sample application.
You can write decisions to your organisation’s database and enable recording of the flow’s steps to support review. Before deployment, backtest the new release against decisions already made. Review each decision that would change and ask whether the new policy was meant to change it. Where the history includes outcomes, compare those too. For each backtest change you want to avoid, adjust the relevant threshold, band or exception rule, issue a new release and test it again. A backtest reports the changes. The policy owner decides whether they are acceptable.
Decide whether the income change is ready
For the threshold and referral band waiting on your desk, use this procedure to build the policy, check its exceptions and decide whether the change is ready to go live.
- Pick one recurring decision with a written policy. List its inputs, thresholds and possible outcomes.
- For each input, mark whether it comes in the request your system sends or from a data source the flow calls.
- Build the policy in one decision flow. Use rule sets for hard rules, a scorecard for the score, a decision table for outcomes by band, and a model where the policy uses one.
- For every input, write a missing-value rule ahead of every rule that uses that input.
- After each data source, add a rule for a failed call and choose the policy’s response, such as another provider, a cautious outcome or manual review.
- For each fork, add a final any-value branch to manual review.
- Release the flow, test it with sample applications, and deploy it to staging before production.
- Keep each decision in your organisation’s own archive and record the flow’s steps during testing.
- Before the next policy change goes live, backtest the new release on decisions already made. Review the decisions that would change, check their outcomes where the history includes them, and revise the policy to match the intended changes.
Questions about decision engines
What is a decision engine and how does it differ from a scorecard?
A credit scorecard converts an applicant’s or account’s characteristics into a number that ranks credit risk. A decision engine runs the broader decision flow around that score, including the data calls, policy rules and logic that produces an outcome. The scorecard supplies a result for the process to use, and the flow determines how that result affects the decision.
What is the difference between a rules engine and a decision engine?
A rules engine evaluates rules against facts. A decision engine runs the wider decision flow, which can combine rules, scores, data sources and outcome handling.
See rule engine architecture for how rules are stored, managed, deployed and executed, how versions are handled, and why testing comes before release.
How does a decision engine work?
A system sends inputs to the flow, which evaluates its configured components in order. The run can return a decision, a partial response or an error, depending on what happens in the flow.
Should decisions run in real time or in batch?
Use real time when each transaction needs a decision as it arrives. Use batch when the engine needs to decide a dataset, such as a customer portfolio for pre-scoring. See real-time decisioning and batch or real-time processing.
Can a decision engine use a machine learning model?
Yes. A trained model can be imported and used to produce a score inside the decision flow.
What should happen when a decision engine cannot get a required input?
Write an explicit policy for the case. Check for missing values before using them, branch on failed data-source calls, and give each fork a final any-value branch such as manual review.
