🤖 AI

Learning from Change: Predictive Models for Incident Prevention in a Regulated IT Environment

This study demonstrates that an interpretable LightGBM model, enhanced with organizational context and SHAP-based explainability, outperforms traditional rule-based methods in predicting IT change-related incidents within a regulated banking environment, thereby enabling proactive risk mitigation while satisfying audit and compliance requirements.

Original authors: Eileen Kapel, Jan Lennartz, Luis Cruz, Diomidis Spinellis, Arie van Deursen

Published 2026-04-16

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Eileen Kapel, Jan Lennartz, Luis Cruz, Diomidis Spinellis, Arie van Deursen

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the captain of a massive, high-speed cruise ship (the bank) carrying thousands of passengers (customers). Every day, your crew needs to make small adjustments to the engine, the navigation system, or the kitchen to keep the ship running smoothly. These adjustments are called "Changes."

However, sometimes a simple tweak to the engine causes the whole ship to sputter or stop. In the tech world, these are called "Incidents."

This paper is about a team of engineers at ING Bank who asked a simple question: "Can we predict which adjustments are likely to break the ship before we even make them?"

Here is the story of how they built a "Crystal Ball" to see the future, explained in plain English.

1. The Problem: The Old Way Was Like Guessing

Before this study, the bank used a Rule-Based System to decide if a change was safe. Think of this like a checklist a pilot uses before takeoff.

The Rules: "If the change affects the engine, it's risky." "If it happens on a Friday, it's risky."
The Flaw: The checklist was too rigid. It flagged almost everything as risky just to be safe. This meant the crew spent hours checking changes that were actually perfectly fine, while sometimes missing the truly dangerous ones. It was like a smoke detector that went off every time you toasted a piece of bread, so people started ignoring it.

2. The Solution: A "Smart Co-Pilot" (Machine Learning)

The researchers decided to build a Machine Learning (ML) model. Instead of following a rigid checklist, this model is like a super-experienced veteran captain who has seen thousands of voyages.

How it learns: They fed the computer 175,000 past "adjustments" (changes) and told it which ones caused problems (incidents) and which ones went smoothly.
The Goal: The computer learned to spot subtle patterns that humans missed. For example, it might learn that "Changes made by Team X on a Tuesday involving the kitchen software are usually fine," or "Changes made by Team Y on a Friday involving the engine are dangerous."

3. The "Black Box" Problem: Why You Can't Just Use a Magic 8-Ball

In the banking world, you can't just say, "The computer says it's safe, so let's go." Regulations require you to know why a decision was made. You can't use a "Black Box" (a model that gives an answer but won't explain how it got there).

The Fix: SHAP (The "Why" Explainer)
The researchers used a tool called SHAP. Imagine your smart co-pilot doesn't just say "Danger!" but instead hands you a report card:

"I flagged this as risky because:
- The change was made by a team that has had trouble before.
- It involves a critical part of the ship.
- It's happening during a busy holiday season."

This makes the AI transparent and trustworthy, satisfying the strict rules of the bank regulators.

4. The Secret Sauce: Adding "Team Personality"

The researchers tried two versions of their model:

The Basic Model: Looked only at the specific change (what was being fixed).
The Enriched Model: Looked at the change PLUS the history of the team doing the work.

The Analogy:

Basic Model: "This mechanic is fixing the brakes. Is the brake pad worn?"
Enriched Model: "This mechanic is fixing the brakes. Is the brake pad worn? AND has this mechanic been rushing lately? AND have they had a good week of successful repairs?"

The Result: The Enriched Model was the winner. By understanding the "personality" and recent performance of the team (the "Aggregated Team Metrics"), the model became much better at predicting trouble.

5. The Results: Catching More Trouble, Wasting Less Time

When they tested the new system against the old checklist:

The Old Checklist: Missed about half of the dangerous changes (it was too blind) and flagged too many safe changes as risky (it was too paranoid).
The New AI Model: Caught 93% of the dangerous changes (a huge improvement!).
The Trade-off: It did flag a few safe changes as risky (false alarms), but in a bank, it is much better to double-check a safe change than to miss a dangerous one. It's better to check your parachute twice than to jump without checking it at all.

6. Why This Matters for Everyone

This isn't just about banks. This is about trust in technology.

For the Bank: They can stop more crashes before they happen, saving money and keeping customers happy.
For the Engineers: They get a helpful tool that tells them, "Hey, this looks a bit shaky, maybe double-check your work," rather than just blocking them or letting them fly blind.
For the Regulators: They get a system that is fair, explainable, and follows the rules.

The Bottom Line

The paper proves that you don't have to choose between smart technology and human rules. By building a "Smart Co-pilot" that explains its reasoning and learns from the team's history, banks can make their systems safer, faster, and more reliable. It's like upgrading from a paper map to a GPS that not only tells you the route but also warns you about traffic jams before you even hit them.

1. Problem Statement

In highly regulated industries like finance, IT operational reliability is paramount. A significant portion of IT incidents (up to 70% in some large-scale systems) are caused by changes (deployments, modifications, or deletions).

The Challenge: Financial institutions must adhere to strict regulatory frameworks (e.g., DORA, EBA guidelines) requiring auditability, traceability, and explainability in decision-making.
Current Limitations: Existing risk assessment processes at the case company (ING Bank) rely on rule-based systems and human expertise. These static rules often fail to distinguish effectively between safe and risky changes due to data imbalance (incidents are rare) and the inability to capture complex, non-linear patterns in historical data.
The Gap: There is a need for a predictive model that not only outperforms rule-based systems in accuracy but also satisfies regulatory requirements for explainability (avoiding "black-box" models) and integrates organizational context (team performance).

2. Methodology

The authors developed a predictive incident risk scoring system using a one-year real-world dataset from ING Bank (Nov 2022 – Oct 2023).

Data Collection & Preparation

Dataset: 175,000 closed change tickets linked to Priority 1 and 2 incidents (high severity). Only ~2.4% of changes resulted in incidents, creating a highly imbalanced dataset.
Feature Engineering:
- Textual Data: NLP features extracted from change descriptions (Short/Full Description) using CountVectorizer and TruncatedSVD.
- Metadata: Configuration Item (CI) attributes, security ratings (Confidentiality, Integrity, Availability), deployment details, and temporal features (day, quarter, weekend).
- Aggregated Team Metrics: A novel addition where team-level performance data (e.g., success rates of releases, incident counts, change frequency) was aggregated by "IT Product" and linked to individual change tickets.
Labeling: A binary classification task where a change is labeled 1 if it caused at least one high-priority incident, and 0 otherwise.

Modeling Approach

Algorithms: Three gradient-boosted tree classifiers were evaluated:
1. HGBC (HistGradientBoostingClassifier from scikit-learn)
2. LightGBM
3. XGBoost
Interpretability: To meet regulatory constraints, the models were paired with SHAP (SHapley Additive exPlanations) values. This provides feature-level transparency, explaining why a specific change was flagged as high-risk.
Evaluation Strategy:
- Temporal Split: Data was split chronologically (8 months training, 2 months validation, 2 months testing) to simulate real-world deployment.
- Metrics: Due to class imbalance, the study prioritized Weighted Recall (wR) and Weighted F2-measure (wF2) over precision. The F2-measure ( $\beta=2$ ) places higher weight on recall to ensure incident-inducing changes are not missed, even at the cost of false positives.
- Sliding Window: The best model was retrained daily to assess stability over time.

3. Key Contributions

Comparative Evaluation: A rigorous comparison between a production rule-based baseline and three ML classifiers in a regulated financial environment.
Integration of Team Metrics: Demonstrated that enriching change data with aggregated team performance metrics (e.g., release success rates) improves predictive accuracy.
Explainability Framework: Successfully applied SHAP to tree-based models to generate actionable, audit-ready explanations for risk scores, addressing the "black-box" concern in regulated sectors.
Actionable Insights: Distinguished between actionable features (e.g., change description, testing plans) and non-actionable features (e.g., team metadata, specific machines), guiding engineers on how to mitigate risk.

4. Results

Baseline Performance: The existing rule-based approach showed poor discriminative ability (AUC = 0.56) and low precision (0.04), flagging many safe changes as high-risk while missing 44% of actual incident-causing changes (Recall = 0.56).
ML Model Performance:
- LightGBM emerged as the best-performing model.
- With Team Metrics: LightGBM achieved a Weighted Recall (wR) of 0.93 and a Weighted F2-measure (wF2) of 0.93, significantly outperforming the baseline.
- Precision: While still low (0.04) due to the rarity of incidents, the improvement in recall is critical for safety.
Feature Importance (SHAP):
- Top Drivers: Textual content of the change description (Short/Full Description) and Configuration Item (CI) names were the most influential features.
- Contextual Drivers: Team assignment groups, support offerings, and aggregated team metrics (e.g., "Releases Percentage Successful per Week") were highly influential.
- Surprising Findings: Temporal features (Quarter, Weekend) and "Outage Total Duration" were significant, suggesting that organizational "error budgets" or freeze periods influence risk distribution.
Stability: The model maintained stable performance (wF2) over time in a sliding window evaluation, proving robustness in a production-like environment.

5. Significance and Implications

Regulatory Compliance: The study proves that high-performing ML models can be deployed in regulated environments if they are interpretable. SHAP values provide the necessary audit trail for change approval boards.
Operational Efficiency: By shifting from a "one-size-fits-all" rule-based approach to a data-driven risk score, organizations can prioritize human review on truly high-risk changes, reducing alert fatigue and improving deployment velocity for low-risk changes.
Human-in-the-Loop: The system is designed to support, not replace, engineers. It acts as a "guard dog," flagging potential risks and providing explanations (e.g., "High risk due to low team release success rate") to guide better decision-making.
Future Directions: The paper highlights the need for better data quality (linking incidents to changes) and further research into causal reasoning beyond correlation to help engineers manipulate actionable features to reduce risk.

In conclusion, this work demonstrates that LightGBM enriched with team metrics and explained via SHAP offers a superior, compliant, and actionable alternative to traditional rule-based risk assessment in financial IT operations.