Reject Inference in Fintech: An Underappreciated Growth Lever

It’s been a while since I wrote anything, so I thought I’d share a quick note on an important but often overlooked method called reject inference — especially relevant since I’ve been working closely with fintech’s in India.

As these fintech’s scale their unsecured lending portfolios, they often hit the same roadblock: how do you safely approve more customers without taking on extra default risk? Even if your application scorecard looks solid, you probably find it hard to say “yes” to more people without delinquency rates creeping up.

Why is that? The main reason is that your models are usually built only on data from customers you’ve already approved. So, you’re missing out on learning from those who were rejected — and some of them might be good borrowers.

That’s where reject inference comes in. It helps you extract insights from rejected applicants, so you can build smarter, more balanced credit models and safely grow your lending business.

What Is Reject Inference?

When building an application scorecard, you basically have two choices:

1. Use only data from approved customers — those you accepted and have repayment information for.
2. Try to include rejected applicants by estimating how they might have performed if approved — this process is called Reject Inference.

The issue with the first option is that your model learns only from a cleaner, lower-risk group and completely misses the segment you want to understand better: the rejected applicants.

Why Is This a Problem?

Models trained solely on approved customers tend to:

• Overestimate overall credit quality because they’ve never seen defaults from the rejected group
• Miss out on good customers who were wrongly rejected (false negatives, or Type II errors)
• Show good performance on test data but struggle in real-world conditions, especially when approval policies change

Real-World Example:
Imagine a fintech wanting to expand its Buy Now, Pay Later (BNPL) portfolio. The existing scorecard works well but approves only a small percentage of applicants. The business wants to approve more of those previously rejected (higher Swap-Ins). However, since the model only learns from approved data, it tends to be overly cautious — underestimating potential good customers and limiting growth.

What Reject Inference Does

Reject Inference techniques attempt to predict what might have happened if rejected applicants were approved. While the true outcomes are unknown, smart approximations can:

• Reduce bias in the model
• Make the model more generalizable to all applicants
• Identify creditworthy customers who were previously rejected
• Help safely increase approvals (Swap-Ins) without raising risk

 How Is It Done?

Let’s explore a structured approach through a fintech-specific example.
Unlike traditional banks or NBFCs, fintech lenders usually have limited historical lending data. Their target customers often consist of thin-file, credit-new, or subprime individuals, which adds complexity to modelling. This nuance makes reject inference both more difficult and critically important.

Step 1: Establish a Historical View of Applicant Behaviour

Start with the last 24–36 months of application data. Monthly snapshots should include:

• Total number of applications
• Disbursed loans
• Rejections (along with reasons)
• Observed bads (defaults)
• Bad rate calculations

This provides foundational insights into how your applicant distribution — and rejection reasons — evolved over time.

Step 2: Segment Rejection Reasons

Rejected applications typically fall into three broad categories:

• Demographic Rejects (e.g., age, location): Usually non-negotiable; exclude from modelling.
• Derogatory Rejects (e.g., severe bureau flags): High-risk by design; typically excluded.
• Policy Rejects (e.g., score below threshold, DPD cuts): These are the focus for reject inference.

Understanding these categories helps modellers and credit teams assess which rejected populations may become lendable under changed policy or macro conditions.

Step 3: Recognize the Limitation of Approved-Only Modelling

Training a model only on disbursed loans misses the opportunity to learn from historically excluded but potentially lendable customers. Many of these policy rejects might be borderline cases — acceptable in more favourable risk environments or under relaxed internal policies. Excluding them can lead to underfitting and poor generalization — especially if those policies evolve.

Hence, it is recommended to include policy rejects in your model development base and exclude only constant-reject criteria like age or derogatory flags.

Step 4: Define the Target Variable Clearly

If the definition of “bad” is unclear, align on it first. Use vintage curve analysis and roll rate transitions to finalize:

• Month-on-Book (MOB) cutoff (e.g., 3M/6M/9M)
• Delinquency threshold (e.g., 30+ DPD, 60+ DPD)

This ensures consistency in outcome labelling, both for approved loans and rejects.

Step 5: Perform Data Sizing and Bureau Availability Checks

Build a comprehensive view using the following table structure:

Sr. No	Metric	Description
1	Month	Monthly snapshot
2	#Applications	Total applicants
3	#Disbursed	Approved and disbursed loans
4	#Rejects	Applications rejected (focus on policy-based)
5	%Overall Bad Rate	Combined bad rate of disbursed + reject proxies
6	%Disbursed Bad Rate	Bad rate on approved loans based on target definition
7	%Reject Proxy Bad Rate	Bad rate of rejects tracked via bureau tradelines
8	#Bureau Reports (Disbursed)	Bureau data available for approved applicants
9	#Bureau Reports (Rejects)	Bureau data available for rejected applicants

Step 6: Bureau Data Sizing and Scrubbing in Fintech

In the fintech space, managing bureau data comes with unique regulatory and operational challenges. For instance, per RBI guidelines, bureau data can only be retained for up to six months after obtaining customer consent. This restriction impacts how we assess both disbursed and rejected applicants for reject inference modelling.

To gain actionable insights, it’s crucial to verify bureau data availability for each applicant and examine their credit behaviour post-application. Specifically, for rejected applicants, check if they:

• Obtained a loan from another lender within 2 to 3 months after rejection.
• Borrowed within a comparable lending segment, such as BNPL or personal loans.

Based on this, applicants can be segmented into three groups:

• Disbursed: Applicants approved and funded by your institution.
• Reject Proxy: Applicants rejected by you but who secured loans elsewhere, providing observable performance data.
• Reject Non-Proxy: Applicants rejected with bureau data available but without any subsequent borrowing from other lenders.

This segmentation helps identify whether policy-rejected applicants demonstrate positive repayment behaviour elsewhere, offering empirical evidence to support reconsideration of approval criteria.

When analysing bureau data availability for a sample of 100 applications in a given month, the distribution might look like this:

		Bureau Reports Available
	Total Record	Yes	No
Disbursed	20	15	5
Reject	80	60	20
Reject Proxy	–	30	–
Reject non-Proxy	–	30	–
Total	100	75	25

Here, we see bureau data is available for 75% of the applications. While this provides a solid foundation, scrubbing bureau reports—cleaning and aligning the data for modelling—presents distinct challenges for fintech compared to traditional banks or NBFCs:

• Cost: Scrubbing can be expensive both for initial model development and ongoing monitoring.
• Timing: Bureau reports usually reflect the latest pull date, not the original application date, which can introduce data leakage if not handled carefully.
• Consent & API Hit Rate: Scrubbing depends on current customer consent and the success rate of bureau API calls, limiting data completeness.
• Data Relevance: Because reports reflect the latest bureau pull, features like balances or flags might not align with the application timeframe.

Given these constraints, it’s essential to balance the cost and feasibility of bureau scrubbing against the quantity and quality of bureau data available.

For now, we proceed with the working assumption that the available volume of bureau reports is sufficiently representative to estimate bad rates for the rejected population and to support model development efforts.

Step 8: Model Development

This section outlines a high-level, principle-driven approach to model development in a fintech lending context. There is no one-size-fits-all method; the goal here is to provide a flexible framework that can be adapted based on experimentation and results.

1. Constructing the Modelling Base

There are two key options to create the modelling base:

• Approach A: Use only the subset of applicants with available bureau reports.
• Approach B: Apply through-the-door (TTD) weights to the subset to make it representative of the full applicant population—including disbursed, proxy rejects, and non-proxy rejects.

For instance, if there are 20 disbursed applicants in total but bureau data is available for only 15, each record in the modelling dataset would be assigned a weight of 20/15 = 1.33. These weights must be maintained consistently throughout the modelling process. Practitioners are encouraged to try both approaches to evaluate what works best for their context.

2. Feature Mapping and Engineering

• Combine both platform-derived and bureau-derived features to represent borrower behavior comprehensively across thin- and thick-file profiles.
• Bureau reports typically reflect the scrub date, not the application date. To avoid data leakage, it is essential to exclude any tradelines or updates that occurred after the application date.
• Many bureau features (e.g., current balance, write-off flags) are snapshot-based and can inadvertently contain future information. This can be mitigated by:
  • Applying appropriate policy rules, or
  • Designing an application score that uses the last six months of bureau history to predict short-term risk—aligned with regulatory guidelines.

3. Developing the Known Good-Bad (KGB) Model

• Start by using only applicants with known outcomes—i.e., disbursed and proxy rejected customers.
• Train the initial model on this subset. This is referred to as the Known Good-Bad (KGB) model.

4. Simulating Outcomes for Non-Proxy Rejects

• Use the KGB model to score non-proxy rejected applicants (i.e., rejected cases with bureau data but no observed performance).
• For each observation, simulate two synthetic records:
  • One labeled bad (1) with a weight equal to the predicted probability.
  • One labeled good (0) with a weight equal to (1 – predicted probability).
• This enables the model to probabilistically incorporate uncertain outcomes while preserving signal from the rejected base.

These simulated weights are referred to as Through-The-Door (TTD) weights:

• Disbursed: weight = 1
• Proxy rejects: weight = 1
• Non-proxy rejects: weight = model-predicted probability (bad) or 1 – probability (good) 

5. Final Model Training and Sampling Strategy

With the entire dataset now labelled (either actually or probabilistically), you may encounter skewed distribution like below:

Segment	# Sample	# Bad	Bad Rate	% Sample with Total	% Bad with Total
Disbursed	15	2	13%	14%	6%
Proxy Rejects	30	10	33%	29%	31%
Non-Proxy Rejects	60	20	33%	57%	63%
Total	105	32	30%	100%	100%

Training on this raw distribution may cause the model to overfit to the rejected population, overshadowing patterns in the approved (disbursed) segment. To mitigate this, a sampling strategy is recommended. Here is the example:

Segment	Sampling Weights	# Sample	# Bad	Bad Rate	% Sample with Total	% Bad with Total
Disbursed	1	15	2.00	13%	42%	22%
Proxy Rejects	0.5	15	5.00	33%	42%	56%
Non-Proxy Rejects	0.1	6	2.00	33%	17%	22%
Total		36	9	25%	100%	100%

In this strategy:

• Use the full disbursed base
• Sample 50% of proxy rejects
• Sample 10% of non-proxy rejects

Before building the final model, multiply these sampling weights with the previously assigned TTD weights to preserve overall integrity.

You may end up developing two separate scorecards:

• One using bureau data
• Another using platform (on-us) data

These can be combined at underwriting using policy logic to leverage intelligence from both data sources.

When presenting model performance metrics like AUC, Gini, KS, and Gains Table to model governance or risk committees, report them on the full through-the-door population, not just the sampled development base. This ensures a realistic view of model effectiveness in production.

Step 8: Limitations & Constraints of Reject Inference in Fintech

• Data Selection Bias: The availability of bureau reports cannot always be taken as a definitive indicator of credit history. Absence of bureau data doesn’t necessarily imply the customer is new-to-credit, making it challenging to construct an unbiased modelling base.
• Timing Misalignment: Bureau data is typically captured as of the current (scrub) date, not the original application date. Consequently, snapshot variables such as write-off flags, outstanding balances, and current balances may reflect post-application outcomes and are unsuitable for application-time modelling.
• To mitigate these limitations:
• Consider developing early delinquency models that align with regulatory and operational timelines.
• Apply policy overlays to control for potential data leakage.
• Incorporate on-us (platform-based) risk models to strengthen the underwriting decision, especially for thin-file or bureau-dark segments.