Skip to main content
Business Analysis

A Business Rules Catalogue for Underwriting and Lending

April 17, 2026
A Business Rules Catalogue for Underwriting and Lending

A lending business runs on rules. Some are regulatory (affordability, responsible lending, sanctions screening). Some are risk-driven (probability of default, loss given default, limits). Some are commercial (pricing, product eligibility, cross-sell triggers). Some are fairness-driven (treatment of vulnerable customers, equal access). When the rules are scattered across underwriting manuals, policy documents, application code, spreadsheets and the memories of experienced underwriters, the business cannot explain why a decision was made, cannot test a change systematically, and cannot satisfy a regulator asking how a particular outcome occurred.

The business rules catalogue is the artefact that consolidates all of the lending rules in one authoritative, versioned, testable repository. This post covers how to build one that works in regulated scope, the structural patterns that scale, and the common failure modes we see when the catalogue is treated as a document rather than as operational infrastructure.

Why the catalogue matters

Under Consumer Duty, the FCA expects firms to deliver good outcomes for retail customers and to evidence how their decisioning logic supports this. Under the EU AI Act, credit scoring is a high-risk use case with specific governance and transparency obligations. Under GDPR Article 22, customers have rights relating to automated decision-making. Without a rules catalogue, firms cannot answer these regulatory questions without forensic investigation of policy documents and code.

Beyond compliance, the catalogue enables two things that make lending businesses more efficient. Consistent decisioning across channels, because every channel references the same authoritative rules. Systematic testing of rule changes, because changes happen in the catalogue and the catalogue drives the decisioning engine.

For a broader view on decisioning and AI governance, see our posts on decision logs for AI model governance and decision rights in AI-native operating models.

What a lending rules catalogue contains

A comprehensive lending catalogue covers five rule families.

1. Eligibility rules

Who qualifies for which product. Age thresholds, residency, employment status, existing relationship, product-specific criteria (for a secured product, the security type). Eligibility rules are usually the most stable. They also include the regulatory eligibility: sanctions screening, adverse media checks, PEP status handling.

2. Affordability rules

Whether the applicant can afford the product. Income calculation rules (gross, net, treatment of variable income, treatment of self-employment, FX normalisation for foreign income). Expenditure rules (minimum living expenses, treatment of existing credit commitments, stress testing for rate rises). The ratio calculations (debt-to-income, loan-to-income, debt service coverage). Under the FCA MCOB rules for mortgage lending, the affordability assessment has specific regulatory requirements that must be reflected.

3. Credit risk rules

The scoring and classification rules that translate the applicant's circumstances into a risk decision. Scorecard inputs and outputs, cut-offs by segment, overrides, manual referral triggers. For model-driven scoring, the rules include the model identifiers, the challenger models, and the override policy. The PRA SS1/23 on model risk management sets expectations on the governance of these rules.

4. Pricing rules

The rules that set the price (rate, fee, term) for the approved product. Pricing tiers by risk grade, segment-specific pricing, promotional pricing, fairness-driven constraints (for example, no systematically worse pricing for protected characteristics). Pricing rules are where Consumer Duty outcomes show up most visibly, because pricing decisions translate most directly to customer outcomes.

5. Treatment rules

The rules that govern how specific customer populations are handled. Vulnerability flags and their consequences, payment holiday policy, forbearance triggers, complaints handling. Treatment rules are increasingly scrutinised under Consumer Duty and fair value obligations.

Structural properties of a good catalogue

Atomicity

Every rule is atomic. "Applicants under 25 with declared income below 25,000 who are self-employed are declined" is three rules compounded: the age rule, the income rule, the employment rule. Decompose into three atomic rules and compose them in a decision table. Atomic rules are easier to test, easier to change, and easier to audit.

Versioning

Every rule has a version, an effective date, and a change history. When a customer challenges a decision, the firm must be able to reconstruct which rules were in force at the time of the decision. Version discipline makes this retrieval trivial. Without it, the reconstruction is forensic.

Ownership

Every rule has an accountable owner, typically the function whose domain the rule serves. Affordability rules are owned by credit risk. Pricing rules by commercial with oversight from Consumer Duty governance. Treatment rules by the customer function. Ownership is not just a label; the owner is accountable for the rule's continued appropriateness and for signing off changes.

Documentation

Each rule has a plain-language description, the regulatory or policy source, the decision table or formula that implements it, the test cases that verify it, and the expected behaviour if the inputs are missing or unusual. This documentation is mandatory, not optional.

Traceability

Rules trace to the policies they implement, the regulations they satisfy, and the decisions they produce. When the regulator asks how a decision was made, the answer runs from the decision through the rules to the policy and regulation. See our post on requirements traceability matrices for the broader traceability discipline.

Representation: the DMN option

For the rules themselves, DMN (Decision Model and Notation) is the standard representation. DMN decision tables express rules in a form that is readable by business users and executable by decisioning engines. A DMN table for affordability looks like a structured table with input columns (monthly income, monthly commitments, debt-to-income ratio), output columns (affordable yes/no, reason codes) and rows that specify the conditions.

The advantage of DMN is that the same artefact serves the business (readable), the decisioning engine (executable), and the auditor (tabular and testable). Tools like Camunda, IBM Operational Decision Manager, SAP Signavio and Red Hat Decision Manager support DMN directly.

For rules that do not fit decision tables (complex calculations, external service calls, machine learning model invocations), DMN supports literal expressions and function invocations that call out to the implementation. The catalogue remains the authoritative record.

Connection to the decisioning engine

The catalogue is not a document that the decisioning engine reads once at deployment. The catalogue is the source of truth that drives the engine in production. Changes to the catalogue propagate to the engine through a controlled pipeline: rule change in the catalogue, test execution against the test suite, approval through governance, deployment to the engine, post-deployment monitoring.

This pipeline is the governance of the rules in motion. Without it, rules in the catalogue and rules in the engine drift, and the audit trail breaks down.

Common failure modes

Failure: rules in code and rules in documents

The underwriting manual describes the rules. The code implements them. Over time, the code changes and the manual does not. When the regulator asks what the rules are, the firm has two sources that disagree. Fix: the catalogue is the authoritative source. The manual is generated from the catalogue. The code is generated from or references the catalogue. The two cannot drift because they are not independent.

Failure: unversioned rules

Rules are documented but not versioned. A customer disputes a decision from 18 months ago. The firm cannot determine which rules were in force. Fix: rules are versioned with effective dates and change histories. Decisions reference the rule version they applied.

Failure: the opaque override

Experienced underwriters override rules without recording why. Over time, the override becomes the norm but is not in the rules. The effective policy differs from the stated policy. Fix: overrides are first-class entries in the rules, with documented triggers. An override that is being used regularly should be promoted to a rule, not left as an informal practice.

Failure: missing treatment rules for vulnerable customers

The catalogue covers eligibility, affordability, risk and pricing comprehensively. Treatment rules for vulnerability, forbearance and complaints are ad hoc or missing. Under Consumer Duty this is a gap. Fix: treatment rules are a first-class family, owned and documented with the same rigour as the others.

Failure: the catalogue as a separate fiefdom

The catalogue is owned by one team and maintained in isolation from policy, risk and product. Changes in policy are not reflected in the catalogue, or vice versa. Fix: catalogue change is integrated with policy governance. Every policy change that affects decisioning triggers a catalogue review.

Worked example: buy-now-pay-later eligibility

Consider a buy-now-pay-later product subject to FCA affordability rules and Consumer Duty.

Rule R-ELIG-BNPL-001: age

  • Description: Applicant must be 18 or older.
  • Source: General lending policy, Consumer Credit Act.
  • Owner: Credit Policy.
  • Version: 1.0, effective 2024-06-01.
  • Test cases: applicant age 17 (decline), 18 (allow), 65 (allow).

Rule R-ELIG-BNPL-002: residency

  • Description: Applicant must be UK resident with verified address for the last 3 months.
  • Source: AML policy, product policy.
  • Owner: Financial Crime.
  • Version: 1.2, effective 2025-01-15 (updated from 6 months to 3 months after Consumer Duty review).
  • Test cases: UK resident 3 months (allow), 2 months (refer), non-resident (decline).

Rule R-AFF-BNPL-001: affordability check

  • Description: For transactions above 100 GBP, perform affordability check using monthly net income minus committed monthly outgoings, must cover the repayment with a 1.5x buffer.
  • Source: FCA CONC 5.2A, internal affordability policy.
  • Owner: Credit Risk.
  • Version: 2.1, effective 2025-04-01.
  • Test cases: multiple worked examples spanning the buffer boundary.

Rule R-VULN-BNPL-001: treatment on vulnerability flag

  • Description: If CRM vulnerability flag is set, route to supported-journey channel with human review before commitment.
  • Source: Consumer Duty cross-cutting rule, internal vulnerability policy.
  • Owner: Customer Outcomes.
  • Version: 1.0, effective 2024-12-01.
  • Test cases: vulnerable customer at threshold transaction, at sub-threshold transaction.

Each rule is atomic, versioned, owned, tested. The decisioning engine executes them. The audit trail reconstructs decisions against rule versions in force at the time.

External references

The OMG DMN specification is the canonical reference for decision modelling. The FCA Handbook CONC covers consumer credit rules applicable to lending in the UK. The EBA guidelines on loan origination and monitoring provide the European supervisory expectation.

The short version

The business rules catalogue is one of the highest-value artefacts in a regulated lending business. Built well, it drives consistent decisioning, enables systematic testing, and provides the audit trail regulators expect. Built badly or not at all, it leaves the business unable to explain its own decisions and exposed to supervisory and litigation risk.

The patterns are not complicated: atomic rules, versioned, owned, traceable, represented in a standard like DMN, connected to the decisioning engine through a controlled pipeline, and integrated with policy governance.

Our business analysis service and operational workflow automation service can help you stand up or remediate the rules catalogue discipline for your lending business.

Ready to do the structural work?

Our AI Enablement engagements are built around the five pillars in this article. We start with a focused diagnostic, then redesign one priority workflow end-to-end as proof — including the data layer, decision rights, and governance machinery.

Explore the AI Enablement service
Monthly newsletter

More like this — once a month

Get the next long-form essay on AI enablement, embedded governance, and operating-model design straight to your inbox. One considered piece per month, written for senior practitioners in regulated industries.

No spam. Unsubscribe anytime. Read by senior practitioners across FS, healthcare, energy, and the public sector.