Champion / Challenger: testing a new credit policy without risking the portfolio
How to evaluate a new credit policy against the one already in production, measuring its real impact on a slice of live traffic before you adopt it.
Updated July 2026 · 5 min read
In short
Champion / challenger runs the policy in force and a candidate side by side on portions of real traffic, then compares results before you adopt the change. It lets you test new cutoffs, models or pricing against actual delinquency and approval rates, without risking the whole portfolio.
Every new credit policy is a bet: in theory it approves better, declines fewer good customers or reduces delinquency. But rolling it out at once across 100% of traffic means betting the portfolio on a hypothesis. Champion / challenger lets you test it with evidence and without putting the business on the line.
Written byMariano Sokal · COO at uFlow
COO at uFlow. Works with banks, fintechs and retailers across Latin America on how credit policies are governed: who decides, how a change is controlled, and what evidence remains for audit and the regulator.
What champion / challenger testing is
The "champion" is the credit policy in force, the one making decisions today. The "challenger" is a candidate variant you want to evaluate. Instead of replacing one with the other, you route portions of live traffic to each and compare the actual results.
It is the same logic as A/B testing, applied to credit decisions: you decide with data, not with opinions.
Why this matters to a bank
- It measures the real impact of a change (approval rate, risk mix) before committing the whole portfolio.
- It contains the risk of a badly calibrated policy change to a controlled fraction of traffic.
- It produces evidence to defend the decision to adopt — or discard — a new credit policy.
- It lets your risk team iterate on models and rules continuously, with measured learning.
How champion / challenger works in uFlow
uFlow includes a champion / challenger node that splits executions between the policy in force and one or more variants, according to the proportion you define. Because every execution is logged as a transaction, the results of each branch can be compared with the same traceability as any other credit decision.
Good practices
- Start with a small slice of traffic for the challenger and widen it if the results hold up.
- Define upfront which metric decides success (approval rate, expected delinquency, conversion).
- Let the experiment run long enough for credit outcomes to mature.
Technical documentation
How this is implemented in the engine, step by step.
Common questions
Is champion / challenger the same as an A/B test?+
Conceptually yes: two or more variants are compared on real traffic. The difference is that what you compare here are credit decision policies, along with their impact on risk and portfolio quality.
Can I compare the results of each variant?+
Yes. Every execution is logged as a transaction, so champion and challenger results are analyzed with the same traceability as any other decision.
Related topics
Model risk management: governing scoring and ML models in credit decisions
Scoring and ML models sharpen credit decisions but add model risk: bias, drift, weak explainability. Govern them with validation, monitoring and audit trails.
Risk matricesFrom Excel matrix to decision engine: how to digitize credit risk matrices
How to move the risk matrices living in Excel into a decision engine: versioned, testable, auditable lookup tables your risk team edits without writing code.
ProductHow the uFlow decision engine does it
Governance, versioning and traceability built into the engine, without slowing the business down.
Explore all guides or read the glossary.
Would this work for your decisioning process?
Transform your credit assessment process with the decision engine.