When Loan Eligibility Rules Change: How the ICMG Anatomy Model Transforms Requirements Management

This blog is part of the series “Rethinking Requirements: How the ICMG Enterprise Anatomy Model Makes Lending Systems Change-Ready.”

In this post, we explore a requirement change scenario driven by a shift in credit risk policy—an example of a Rule/Motivation change. We examine how such a change impacts the lending architecture and how the ICMG Enterprise Anatomy Model (Project Edition) enables precise, coordinated responses across the architectural perspectives and variables involved.

Perspectives covered: Strategy, Business Process, System, Component Specification, Implementation, Operations

Key variables impacted: Rule, Data, UI/Access Channel, Event

The Challenge of Frequent Requirement Changes

Retail lending is a dynamic space. Loan eligibility criteria evolve constantly due to shifts in credit risk appetite, regulatory directions, and business strategy.

Consider a typical requirement change:The credit policy team increases the minimum credit score for loan eligibility from 650 to 700.

While the change may seem simple, in most lending systems it leads to significant disruption:

• Developers must modify code across multiple systems

• UI and backend display inconsistent eligibility decisions

• Pre-approved customers are incorrectly accepted or rejected

• Testing becomes reactive and manual

• Business teams lose confidence in delivery

These problems arise because most teams react at the implementation level without understanding the system’s architectural anatomy. The ICMG Enterprise Anatomy Model (Project Edition) addresses this challenge through a structured, multi-perspective, variable-driven approach.

Why Conventional SDLC Approaches Fail

What goes wrong:

• Credit score rules are hardcoded across backend services, APIs, and decision engines

• Customer portals display outdated or inconsistent messaging

• Loan officers manually override system behavior

• Compliance reports reflect incorrect approval decisions

The root cause:

Conventional SDLC lacks architectural traceability. Changes are implemented in code without evaluating:

• Which business processes are affected

• Which rule, data, UI, and event components need to be updated

• What user-facing changes are required

• How to validate the outcome against business strategy

Applying the ICMG Enterprise Anatomy Model (Project Edition)

Strategy Perspective

The organization aims to reduce default risk by tightening credit policies.

Business Process Perspective

Affected processes include:

• Loan Origination

• Underwriting

• Auto-Approval and Auto-Rejection Workflows

System / Subsystem Perspective (by Variable)

Variable	Subsystems Involved
Rule Sub System	Loan Eligibility Rule Engine
Data Sub System	Credit Score Repository, Risk Model Store
Function Sub System	Loan Origination System, Eligibility Calculator
UI / Access Channel Sub System	Customer Portal, CRM Agent Dashboard
Event / Timing Sub System	Eligibility Status Event Handler, Notification Bus
Network / Deployment Sub System	Credit Bureau API Gateway, Rule Engine Deployment

Component Specification Perspective

Single-Variable Component Impacts

Rule Components:

• CreditScoreThresholdRule

• RiskCategoryMappingRule

Impact: Update threshold value to 700. Reassess dependency rules.

Data Components:

• CreditScoreField

• KYCStatusFlag

Impact: Ensure real-time delivery of bureau scores. Validate data contracts.

UI Components:

• EligibilityStatusWidget.vue

• RejectionReasonBanner

Impact: Update messaging, sync with new rule outcomes.

Event Components:

• EligibilityFailEvent

• ApplicationRejectionEvent

Impact: Ensure accurate and timely event firing.

Network Components:

• CreditBureauScoreAPIClient.ts

Impact: Ensure score accuracy, timing, and fallback logic.

Function Components:

• evaluateEligibility()

Impact: Pass correct data to rule engine and log outcomes.

Multi-Variable Component Impacts

Rule + Data Component:

• EligibilityRuleWithScoreInput

Impact: Validate score data mapping and integration with rule logic.

UI + Event Component:

• RejectionBannerPopup

Impact: Show dynamic feedback when rejection event is triggered.

Implementation Perspective (Mapped by Component)

Component	Task
CreditScoreThresholdRule	Update value in eligibility_rules.yaml; version control commit
RiskCategoryMappingRule	Reassess mapping thresholds
CreditScoreField	Validate real-time data fetch, update schema if needed
EligibilityStatusWidget.vue	Update tooltip and status logic
EligibilityFailEvent	Update trigger and enrich payload
CreditBureauScoreAPIClient	Add validation, test fallback logic
evaluateEligibility()	Update logic, ensure audit logging

Operations Perspective (Linked to Processes)

Business Processes: Loan Origination, Underwriting

Validation Activities:

• Simulate applications with various credit scores

• Ensure eligibility logic correctly applies new rule

• Monitor triggered rejection events and UI updates

• Validate reports for compliance with new policy

Summary: Cascading Impact of the Change

Level	Example Impact
Strategy	Risk reduction through policy update
Process	Origination and underwriting logic updates
System / Subsystem	Changes to 6 subsystems (rule, data, function, UI, event, network)
Component Specification	10+ components impacted
Implementation	8 key tasks across YAML configs, frontend files, backend functions
Operations	UAT scenarios, audit logs, SLA validation
Cross-Variable Effects	Rule-to-Event, UI-to-Event, Rule-to-Data linkages affecting consistency

Traditional SDLC vs ICMG Enterprise Anatomy Model (Project Edition)

Area	SDLC Problem	ICMG Solution
Scope of Analysis	Limited to code-level implementation	Evaluates across all architectural perspectives and variable impacts
Rule Change Implementation	Manual updates in multiple services	Centralized rule definition traceable through Rule Subsystem and Rule Components
UI Consistency	Often missed or updated after complaints	UI components linked to eligibility rule via component map
Testing and Validation	Broad regression with unclear focus	Focused test cases derived from component-variable change trace
Strategy Alignment	Not traceable to implementation	Direct trace from strategic credit policy to implementation and operation components
Developer Coordination	Ad hoc handoffs, missing ownership	Role-based traceability to components, tasks, and subsystems

Important things to note

This change in credit score threshold appears minor but touches nearly every part of the lending platform. Using the ICMG Enterprise Anatomy Model (Project Edition), organizations can:

• Trace the impact from strategy to implementation

• Identify and align system behavior across six variables

• Assign precise implementation and testing tasks

• Validate the operational behavior against intended business outcomes

It’s not just code management—it’s architecture-driven change execution. And that’s how you build adaptive, resilient lending platforms.

If your organization is looking to fast-track its readiness for evolving compliance requirements, explore the Fast Track Rating and Enterprise Select Program. These initiatives leverage the ICMG model to enhance your compliance posture and operational resilience. Connect with us to learn how your business can stay ahead of regulatory challenges with confidence and agility.