Rethinking the Business Rules Engine for Modern Underwriting

Underwriting relies on business rules engines to apply credit policy consistently. These systems determine whether an applicant meets eligibility criteria, where an application should be referred, and which conditions should prevent a loan from proceeding.

Historically, implementing these rules has required converting policy documents into programmatic logic. A risk manager defines the policy, a business analyst turns it into technical requirements, and an engineering team implements the corresponding rules. Testing, approvals, and deployment follow. This creates an operational gap between the people who own credit policy and the systems that enforce it.

A threshold change that takes minutes to approve may take weeks to reach production. Adding a policy exception can require changes across several interconnected rules. If a bureau provider modifies its response format or a new document structure appears, the engine may no longer find the fields it depends on. The maintenance burden grows with every product, borrower segment, data provider, and policy variation.

Why Traditional BREs Become Difficult to Maintain

The complexity of a BRE rarely comes from the comparison itself. Most lending rules eventually reduce to a threshold, ratio, range, or logical condition. The difficult work lies in determining which data should be used.

A policy concerning recent delinquency must define the relevant accounts, repayment period, bureau fields, exclusions, and treatment of incomplete history. An income rule must establish which documents are acceptable, how income is normalized, and which source takes precedence when values disagree.

Encoding these decisions requires a combination of credit expertise and technical knowledge. A developer may understand the rule engine while lacking the domain context behind the policy. A risk manager may understand the policy precisely while being unable to express it inside the production system.

Over time, important policy knowledge becomes embedded in implementation details. The official policy document describes one view of the rules, while the deployed engine contains the version that actually determines outcomes. This divergence creates a governance problem. When a decision is challenged, teams must reconstruct how the written policy became executable logic and whether the correct data was used.

The Tempting AI Shortcut

Large language models appear well suited to this problem. They can read policy documents, interpret financial language, and examine applicant records without requiring every input to follow a fixed structure.

A common implementation sends the policy and applicant documents to a model with a simple instruction: decide whether the application should be approved. The resulting answer may appear credible. It may include a verdict, a summary, and several observations about the applicant. However, a fluent response does not provide the controls required for financial decisioning.

Underwriting requires a complete decision record. Which document supplied the income value? Which repayment entry caused a policy failure? Was a ratio calculated correctly? How was missing information treated? Were all rules evaluated? Did contradictory identity information affect the result?

A single probabilistic request cannot answer these questions reliably after the decision has been made. The output combines document interpretation, calculations, policy evaluation, and judgment into one opaque operation. That architecture may support demonstrations, but it introduces unacceptable risk when used to approve or reject real applications.

Separating Interpretation From Evaluation

A viable AI BRE needs distinct boundaries between policy interpretation, data extraction, and rule evaluation. Each stage should produce an output that can be inspected independently. This principle guides the AI underwriting architecture we have built at Crego.

The process begins with policy intent. Risk teams can provide rules through plain language or existing policy matrices. The platform interprets those rules and creates a structured definition of the data required to evaluate them. This allows the system to determine its evidence requirements before examining the applicant, rather than constructing a decision from whichever information appears useful.

The next stage performs grounded extraction. Applicant documents are examined only to populate the required fields. Every extracted value carries a reference to its source, while unavailable information is recorded explicitly.

If an income figure contributes to a rejection, the lender can trace it to the document from which it was extracted. If a required value is missing, the system retains that absence instead of filling the gap with an assumption. Sensitive identity information is also masked before results are persisted.

Once the evidence record is complete, the rules are evaluated against it. Each result includes the policy condition, the values used, the severity of the rule, and the mathematical or logical basis for the outcome. A failed hard rule remains distinguishable from a soft exception, while missing evidence remains distinguishable from a policy failure. Applications with insufficient or contradictory information can be referred for review without forcing the system to invent certainty.

Auditability Has to Be Part of the Architecture, Not an Afterthought

Auditability cannot be added after a model produces its answer. It has to exist throughout the decision process. Crego maintains the connection between policy, extracted evidence, individual rule results, and the final underwriting recommendation.

The wider underwriting workflow also checks document sufficiency, identifies discrepancies across applicant records, assesses risk factors, and records the basis for referral or decline. AI is used where interpretation is valuable, while structured schemas, rule validation, evidence references, and controlled decision states provide the required discipline around it.

This approach also preserves a role for deterministic enforcement. Policies that need fixed execution can be converted into validated rule logic, while AI assists with authoring, evidence gathering, and analysis. Lenders can introduce AI without surrendering the controls already built into their credit operations.

Maintainable Credit Policy Layer

AI BRE changes the relationship between credit policy and software. Risk teams gain a more direct way to configure and revise policies, while engineering teams spend less time translating routine rule changes. Underwriters receive a clearer account of the evidence behind each result, and compliance teams retain visibility into how automated decisions were reached.

The value comes from the complete decision trail: what the policy required, what information was found, where it was found, how the rule was evaluated, and why the application received its outcome. That is the standard we are building toward at Crego.