Credit Decision Engines: Rules, Exceptions and Human Review

The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.

An applicant’s income is sufficient under one rule, but a recent change makes the evidence uncertain. The credit decision engine returns “decline.” A reviewer says the case should have been referred. The product team cannot settle the dispute by pointing at the code: the code has implemented a policy interpretation, and the organization needs to know which one was approved.

Illustrative scenario. A decision engine is more than a calculator. It turns data, policy, precedence and human authority into an outcome that affects a person. Its quality depends on how it handles cases that do not fit a clean yes or no.

Separate the kinds of decision

Eligibility, affordability, fraud signals, identity checks and credit-risk appetite may contribute to a decision, but they are not interchangeable. A missing document is not the same as an adverse credit finding. A possible fraud signal may require a different review route from an affordability concern. Define what each component can decide, what it can only flag, and what it must never silently override.

Create an explicit state model: approved subject to any applicable conditions, declined for an approved reason, more information requested, or referred to an authorized reviewer. These are illustrative categories. The actual outcomes and communications depend on product, policy and jurisdiction. Ensure the customer-facing status reflects the real state without revealing sensitive control details.

Make conflicts and missing information visible

Rules need precedence. If an applicant passes a score threshold but fails a mandatory exclusion, which rule governs? If a data provider times out, does the system wait, retry, use another source or refer? If two sources disagree, which is authoritative? The engine should not convert “unknown” into “no” merely because a binary field is convenient.

Test with a decision table, not only a set of successful examples. Include threshold boundaries, missing values, conflicting records, duplicated events, stale evidence and changes between application and final decision. Product, risk and engineering should be able to trace each outcome to the input version, rule version and approving policy owner.

Human review needs a real mandate

A referral queue is not a control if nobody has time or authority to resolve it. Define which role may review each case, what evidence can be considered, when a second approval is needed, how conflicts of interest are handled and what happens when the reviewer is absent. An override should record the original recommendation, the revised decision, rationale, authorized person and time. It should be possible to distinguish a legitimate exception from an unapproved workaround.

The product also needs a route for correction or challenge appropriate to the context. A person may supply new information, dispute an error or ask what happened. The response must be designed with the relevant legal and risk owners; “human review available” is not a substitute for a functioning process.

Monitor the decision after release

Approval rate alone is not a quality measure. Review referrals, missing-data rates, overrides, turnaround, policy exceptions, downstream performance and customer complaints by relevant segments. A change in the applicant mix or data source can alter engine behaviour even when code has not changed. Investigate unusual shifts before concluding that the model or the market has improved.

For a new policy version, compare decisions on a representative historical set before switching live traffic. Define who approves the release, how in-flight applications are treated and how the previous version can be recovered if a defect appears. Sampling decisions and overrides after release tests whether policy is operating as intended.

A product review for the engine

• Can we explain the approved policy source and precedence behind each outcome?
• Do missing, conflicting and delayed data produce explicit states?
• Who can review or override, under what authority and with what record?
• Can a customer correction be received and handled appropriately?
• What monitoring would reveal drift, unfairness or an operational backlog?

Research note: the Basel Committee’s credit-risk principles discuss approval authority, documentation, exception processing and ongoing monitoring for banks. They inform the governance questions here. A particular lender must apply its own jurisdiction’s requirements and approved policy; this article does not prescribe a credit decision rule.