Banking Product Next-Best-Offer Ranking | Dataford Interview Questions

Business Context

You’re interviewing with NorthRiver Bank, a top-15 retail bank in the US with 18M active digital customers and ~220M card and ACH transactions/day. The bank wants to launch a “Next Best Offer” module in its mobile app and online banking portal to recommend products such as cashback credit cards, high-yield savings, personal loans, auto loans, mortgage refinance, and overdraft protection.

The business goal is to increase product adoption without harming customer trust or violating regulatory requirements (e.g., ECOA/FCRA, fair lending, adverse action considerations). Offers are shown in a carousel with 3 slots on the home screen; the bank can only contact a customer with at most 1 proactive offer per week.

Dataset

You have historical logged data from the last 12 months. Each row represents a customer-week snapshot with features computed up to the start of the week, and labels derived from what the customer did in the following 28 days.

Component	Scale / Count	Examples
Entities	18M customers	customer_id, tenure_days, region
Training rows	~520M customer-weeks	52 weeks × active customers
Candidate products	9 products	credit_card, HYSA, personal_loan, auto_loan, mortgage_refi, CD, brokerage, overdraft, BNPL
Numerical features	~60	avg_balance_30d, paycheck_amount_p50, utilization_pct, txn_count_7d, revolving_interest_paid
Categorical features	~25	segment, channel_preference, employer_industry, risk_band
Temporal/behavioral	~30	balance_trend_90d, paycheck_regularity, billpay_adoption, travel_spend_share
Missingness	5–25% depending on feature	employer_industry missing for 22%, income_proxy missing for 18%

Labeling: For each (customer, week), you have:

accepted_product (one of 9 products or none) based on whether the customer applied/opened within 28 days.
revenue_90d (continuous) estimated incremental profit over 90 days if accepted (can be negative for some products due to acquisition costs).

Class balance: Highly imbalanced. In a typical week, only ~1.2% of customer-weeks lead to any product acceptance; per-product acceptance ranges from 0.03% to 0.6%.

Success Criteria

Ranking quality: Improve Precision@3 for accepted products by +25% relative to the current rule-based system.
Business value: Increase expected incremental profit per 1,000 impressions by ≥ 10% while keeping complaint rate flat.
Risk/compliance: Provide an explanation framework and monitoring to detect disparate impact across protected classes (note: you may not use protected attributes directly for targeting).

Constraints

Latency: p95 < 60 ms per request for online scoring (features are precomputed in a feature store).
Serving: Must support ~3K QPS peak during morning logins.
Training: Nightly batch training allowed; full retrain must finish in < 3 hours on a small GPU-less cluster.
Leakage: Strict time-based splits; no using post-week outcomes.
Policy constraints: Eligibility rules (e.g., credit score band, existing product holdings) must be enforced before ranking.

Deliverables

Propose a modeling approach for next-best-offer ranking (not just “predict acceptance”).
Define the training labels and negative sampling strategy given extreme imbalance and exposure bias.
Specify your feature engineering plan and leakage safeguards.
Provide an evaluation plan: offline ranking metrics, calibration checks, and an online A/B test design.
Describe how you would deploy and monitor the model in production (drift, fairness, stability, and business KPIs).

Problem

Business Context

Dataset

Component	Scale / Count	Examples
Entities	18M customers	customer_id, tenure_days, region
Training rows	~520M customer-weeks	52 weeks × active customers
Candidate products	9 products	credit_card, HYSA, personal_loan, auto_loan, mortgage_refi, CD, brokerage, overdraft, BNPL
Numerical features	~60	avg_balance_30d, paycheck_amount_p50, utilization_pct, txn_count_7d, revolving_interest_paid
Categorical features	~25	segment, channel_preference, employer_industry, risk_band
Temporal/behavioral	~30	balance_trend_90d, paycheck_regularity, billpay_adoption, travel_spend_share
Missingness	5–25% depending on feature	employer_industry missing for 22%, income_proxy missing for 18%

Labeling: For each (customer, week), you have:

accepted_product (one of 9 products or none) based on whether the customer applied/opened within 28 days.
revenue_90d (continuous) estimated incremental profit over 90 days if accepted (can be negative for some products due to acquisition costs).

Class balance: Highly imbalanced. In a typical week, only ~1.2% of customer-weeks lead to any product acceptance; per-product acceptance ranges from 0.03% to 0.6%.

Success Criteria

Ranking quality: Improve Precision@3 for accepted products by +25% relative to the current rule-based system.
Business value: Increase expected incremental profit per 1,000 impressions by ≥ 10% while keeping complaint rate flat.
Risk/compliance: Provide an explanation framework and monitoring to detect disparate impact across protected classes (note: you may not use protected attributes directly for targeting).

Constraints

Latency: p95 < 60 ms per request for online scoring (features are precomputed in a feature store).
Serving: Must support ~3K QPS peak during morning logins.
Training: Nightly batch training allowed; full retrain must finish in < 3 hours on a small GPU-less cluster.
Leakage: Strict time-based splits; no using post-week outcomes.
Policy constraints: Eligibility rules (e.g., credit score band, existing product holdings) must be enforced before ranking.

Deliverables

Propose a modeling approach for next-best-offer ranking (not just “predict acceptance”).
Define the training labels and negative sampling strategy given extreme imbalance and exposure bias.
Specify your feature engineering plan and leakage safeguards.
Provide an evaluation plan: offline ranking metrics, calibration checks, and an online A/B test design.
Describe how you would deploy and monitor the model in production (drift, fairness, stability, and business KPIs).

Problem

Business Context

Dataset

Component	Scale / Count	Examples
Entities	18M customers	customer_id, tenure_days, region
Training rows	~520M customer-weeks	52 weeks × active customers
Candidate products	9 products	credit_card, HYSA, personal_loan, auto_loan, mortgage_refi, CD, brokerage, overdraft, BNPL
Numerical features	~60	avg_balance_30d, paycheck_amount_p50, utilization_pct, txn_count_7d, revolving_interest_paid
Categorical features	~25	segment, channel_preference, employer_industry, risk_band
Temporal/behavioral	~30	balance_trend_90d, paycheck_regularity, billpay_adoption, travel_spend_share
Missingness	5–25% depending on feature	employer_industry missing for 22%, income_proxy missing for 18%

Labeling: For each (customer, week), you have:

accepted_product (one of 9 products or none) based on whether the customer applied/opened within 28 days.
revenue_90d (continuous) estimated incremental profit over 90 days if accepted (can be negative for some products due to acquisition costs).

Class balance: Highly imbalanced. In a typical week, only ~1.2% of customer-weeks lead to any product acceptance; per-product acceptance ranges from 0.03% to 0.6%.

Success Criteria

Ranking quality: Improve Precision@3 for accepted products by +25% relative to the current rule-based system.
Business value: Increase expected incremental profit per 1,000 impressions by ≥ 10% while keeping complaint rate flat.
Risk/compliance: Provide an explanation framework and monitoring to detect disparate impact across protected classes (note: you may not use protected attributes directly for targeting).

Constraints

Latency: p95 < 60 ms per request for online scoring (features are precomputed in a feature store).
Serving: Must support ~3K QPS peak during morning logins.
Training: Nightly batch training allowed; full retrain must finish in < 3 hours on a small GPU-less cluster.
Leakage: Strict time-based splits; no using post-week outcomes.
Policy constraints: Eligibility rules (e.g., credit score band, existing product holdings) must be enforced before ranking.

Deliverables

Propose a modeling approach for next-best-offer ranking (not just “predict acceptance”).
Define the training labels and negative sampling strategy given extreme imbalance and exposure bias.
Specify your feature engineering plan and leakage safeguards.
Provide an evaluation plan: offline ranking metrics, calibration checks, and an online A/B test design.
Describe how you would deploy and monitor the model in production (drift, fairness, stability, and business KPIs).

Problem

Business Context

Dataset

Component	Scale / Count	Examples
Entities	18M customers	customer_id, tenure_days, region
Training rows	~520M customer-weeks	52 weeks × active customers
Candidate products	9 products	credit_card, HYSA, personal_loan, auto_loan, mortgage_refi, CD, brokerage, overdraft, BNPL
Numerical features	~60	avg_balance_30d, paycheck_amount_p50, utilization_pct, txn_count_7d, revolving_interest_paid
Categorical features	~25	segment, channel_preference, employer_industry, risk_band
Temporal/behavioral	~30	balance_trend_90d, paycheck_regularity, billpay_adoption, travel_spend_share
Missingness	5–25% depending on feature	employer_industry missing for 22%, income_proxy missing for 18%

Labeling: For each (customer, week), you have:

accepted_product (one of 9 products or none) based on whether the customer applied/opened within 28 days.
revenue_90d (continuous) estimated incremental profit over 90 days if accepted (can be negative for some products due to acquisition costs).

Class balance: Highly imbalanced. In a typical week, only ~1.2% of customer-weeks lead to any product acceptance; per-product acceptance ranges from 0.03% to 0.6%.

Success Criteria

Ranking quality: Improve Precision@3 for accepted products by +25% relative to the current rule-based system.
Business value: Increase expected incremental profit per 1,000 impressions by ≥ 10% while keeping complaint rate flat.
Risk/compliance: Provide an explanation framework and monitoring to detect disparate impact across protected classes (note: you may not use protected attributes directly for targeting).

Constraints

Latency: p95 < 60 ms per request for online scoring (features are precomputed in a feature store).
Serving: Must support ~3K QPS peak during morning logins.
Training: Nightly batch training allowed; full retrain must finish in < 3 hours on a small GPU-less cluster.
Leakage: Strict time-based splits; no using post-week outcomes.
Policy constraints: Eligibility rules (e.g., credit score band, existing product holdings) must be enforced before ranking.

Deliverables

Propose a modeling approach for next-best-offer ranking (not just “predict acceptance”).
Define the training labels and negative sampling strategy given extreme imbalance and exposure bias.
Specify your feature engineering plan and leakage safeguards.
Provide an evaluation plan: offline ranking metrics, calibration checks, and an online A/B test design.
Describe how you would deploy and monitor the model in production (drift, fairness, stability, and business KPIs).