Customer Creditcard Underwriting

Credit Card Underwriting Features

This skill complements the broader banking/card feature playbook in customer-creditcard-features/SKILL.md. It narrows that catalog to the underwriting use case: deciding whether a customer should be approved, how much credit they can bear, and how risky they are using their broader banking relationship, especially checking and deposit behavior.

The canonical row remains (customer_id, cutoff_date). Every feature must be derivable from data available at or before cutoff_date.

This use case is focused on underwriting and affordability. The signal set should emphasize:

• checking and deposit account balances
• direct deposit and recurring inflows
• cash-flow stability and volatility
• overdraft / NSF behavior
• tenure and relationship depth with the bank
• cross-product holdings and usage signals
• repayment capacity proxies and affordability
• bureau and risk profile for the customer

This is not a generic product-usage skill. It is specifically for card approval, limit assignment, and risk segmentation decisions using the customer’s relationship with the institution and broader financial health.

Use-case fit

Use this skill when the model goal is one of the following:

• credit card approval / decline
• limit assignment or limit increase recommendation
• line management / prudent credit exposure
• risk segmentation before offer issuance
• affordability and debt-service coverage assessment
• identifying customers whose external behavior suggests stronger or weaker repayment capacity

It is most relevant when the bank has access to information beyond the credit card itself, especially:

• deposit products
• checking accounts
• recurring payroll and direct deposit history
• cash-flow patterns across accounts
• account tenure and relationship depth
• overdraft and fee behavior
• existing product breadth and loyalty

Relationship to the broader card feature catalog

The broader card feature skill covers many banking and card-aligned variables. This underwriting skill should use that catalog as a starting framework, but it narrows the final feature set to the decision-relevant facets for affordability and risk.

In practice, combine the two ideas as follows:

• use the broad card feature skill for the universe of candidate variables
• retain only the subset relevant to underwriting risk and repayment ability
• validate the subset using a decision-oriented lens: can this feature explain approval risk or repayment capacity?

This keeps the underwriting skill aligned with the rest of the repo while still being opinionated about what matters in a credit decision.

Step 0 — Define the underwriting problem

Before writing code, agree on the exact underwriting target and as-of logic.

1. Decision type. Is the model for approval, limit assignment, risk segmentation, or fraud/abuse screening?
2. Label definition. Examples:
   • approved within 30 days
   • charge-off within 12 months
   • severe delinquency within 180 days
   • limit increase approval within 60 days
3. Observation date. cutoff_date is the last date on which all features can be computed.
4. Allowed source tables. Clarify whether bureau data, transaction data, deposit data, and account activity are allowed.
5. Out-of-time evaluation. Use a recent holdout period to test calibration and performance over time.

If any of these are ambiguous, stop and clarify before engineering features.

Step 1 — Canonical schema

Build a mapping from source warehouse tables to these canonical tables.

Map the actual warehouse names carefully. Do not silently assume identical fields across systems.

Step 2 — Leakage hygiene (non-negotiable)

All underwriting features must be answerable at cutoff_date without future information.

Rules:

1. Filter every event table by timestamp <= cutoff_date before aggregation.
2. Reconstruct account snapshots as-of cutoff_date instead of reading the current table.
3. Use settlement_ts or close_ts for negative events such as chargebacks, reversals, or collections status.
4. Exclude bureau pulls after the cutoff.
5. Exclude applications or account changes happening after the decision date.
6. If variable updates are later-resolved, use the value known at the cutoff, not the eventual corrected value.

Leakage traps in underwriting:

• using post-approval product openings as features for a decision
• reading an updated bureau record that was pulled after the application date
• using future cash-flow events beyond the cutoff
• using a current balance snapshot when the account history should be reconstructed as-of date

Step 3 — Feature groups for underwriting

Build features in families, validate each family before moving to the next. This set should complement the broader card feature catalog, but with underwriting emphasis.

3.1 Customer and relationship context

• customer_age_years
• bank_tenure_days = cutoff_date - customer_signup_ts
• relationship_tenure_days from first deposit/checking account
• n_active_bank_products
• has_checking_account, has_savings_account, has_cd, has_loan, has_credit_card
• primary_product_type (checking heavy / savings heavy / loan heavy)
• days_since_first_bank_product
• days_since_last_product_added

3.2 Checking and deposit balance features

These are often the strongest underwriting signals and are the key distinction from generic card engagement features.

• avg_checking_balance_30d, _90d, _180d
• median_checking_balance_90d
• min_checking_balance_90d
• max_checking_balance_180d
• balance_volatility_90d
• days_with_positive_balance_30d
• days_with_positive_balance_90d
• deposit_balance_to_income_proxy
• liquidity_ratio = avg_monthly_balance / monthly_expense_proxy
• cash_buffer_days = avg_balance / avg_monthly_outflow
• checking_balance_trend_30d_vs_90d
• available_funds_ratio_30d

3.3 Cash-flow and income stability features

This is the most underwriting-critical family. It captures repayment capacity and stability far better than simple card spend history alone.

• monthly_inflow_total_30d, _90d, _180d
• monthly_outflow_total_30d, _90d
• net_cash_flow_30d, _90d
• inflow_outflow_ratio_30d
• paycheck_frequency_90d (count of payroll or direct deposit events)
• payroll_share_of_inflows_90d
• direct_deposit_ratio_90d
• income_stability_score_90d based on monthly inflow variance
• cash_flow_slope_90d
• monthly_inflow_cv_90d
• days_since_last_payroll_deposit
• salary_coverage_ratio = monthly_inflow / monthly_obligations_proxy
• income_reliability_flag if recurring payroll dominates inflows

3.4 Direct deposit, payroll, and recurring inflow features

• avg_direct_deposit_amount_30d, _90d
• n_direct_deposit_events_30d, _90d
• recurring_inflow_share_90d
• payroll_to_total_inflow_ratio_90d
• n_unique_payers_90d
• largest_payroll_amount_90d
• income_consistency_score_90d
• days_since_last_recurring_income

3.5 Overdraft, NSFs, and transaction friction

• nsf_count_30d, _90d, _180d
• nsf_rate_90d = NSF_count / transaction_count
• overdraft_fee_total_90d
• days_since_last_nsf
• average_overdraft_amount_90d
• returned_item_count_90d
• in_sufficient_funds_ratio_90d
• negative_balance_days_30d
• low_cash_buffer_flag

3.6 Transaction pattern and affordability features

• transaction_count_30d, _90d
• avg_daily_debit_amount_30d
• avg_daily_credit_amount_30d
• debit_to_credit_ratio_90d
• essential_spend_share_90d (groceries, utilities, housing, childcare)
• discretionary_spend_share_90d
• merchant_category_entropy_90d
• monthly_fixed_expense_proxy_90d
• debt_service_coverage_proxy = inflow / fixed obligations proxy
• spend_stability_score_90d
• non_recurring_spend_share_90d

3.7 Product depth and breadth features

This is where the customer’s broader banking relationship becomes especially valuable. For underwriting, a customer with multiple active and healthy bank products usually has stronger relationship continuity and lower volatility.

• n_open_accounts_total
• n_active_deposit_accounts
• n_open_credit_lines
• credit_to_deposit_ratio
• loan_payment_to_income_proxy
• wealth_depth_score (number of savings and investment-linked products)
• cross_product_holdings_score
• days_since_last_new_product

3.8 Credit behavior and relationship with the bank

• loan_payment_on_time_rate_90d
• existing_card_utilization_asof
• credit_limit_utilization_all_cards
• paydown_trend_90d
• loan_delinquency_flag_90d
• prior_bank_repayment_history_score
• bank_transaction_reliability_score

3.9 Bureau and risk features

• bureau_score_asof
• delinquency_count_12m
• recent_inquiries_6m
• credit_utilization_total
• open_trade_count
• max_delinquency_age_days
• utilization_trend_90d
• new_credit_inquiry_count_90d

3.10 Digital banking and engagement features

• login_count_30d, _90d
• avg_login_duration_30d
• digital_banking_activity_score_90d
• mobile_vs_web_usage_share
• bill_pay_usage_rate_90d
• transfer_count_90d
• account_alert_engagement_flag

3.11 Trend and comparison features

These are critical for underwriting because they capture deterioration or strengthening financial health. This follows the same principle as the broader card feature skill’s “first vs last period” comparison logic, but the emphasis here is repayment capacity, liquidity, and affordability.

• avg_balance_first_6m, avg_balance_last_6m
• balance_last6m_vs_first6m_ratio
• net_cash_flow_last_30d_vs_prev_30d
• inflow_last_30d_vs_prev_30d
• checking_balance_slope_90d
• cash_flow_decline_pct_30d
• overdraft_event_trend_90d
• income_volatility_change_90d
• product_depth_change_180d

3.12 Interaction features

These should only be used after reviewing the base feature set.

• balance_volatility × bureau_score
• monthly_inflow × overdraft_count
• cash_buffer_days × existing_card_utilization
• salary_coverage_ratio × loan_payment_to_income_proxy
• account_tenure × direct_deposit_ratio
• net_cash_flow × n_active_products
• checking_balance_trend × delinquency_flag

Step 4 — Cash-flow-specific underwriting logic

For card underwriting, the most powerful signal is not just total balance but the customer’s ability to maintain cash flow after recurring obligations.

Use these definitions:

• monthly_inflow_proxy: direct deposits + payroll + recurring credits
• monthly_outflow_proxy: debits + recurring bills + transfers + card payments
• cash_buffer_days = avg_balance / avg_outflow_per_day
• debt_service_coverage_proxy = inflow / obligations_proxy
• income_stability_score = 1 / (1 + CV(inflow)) with smoothing

A customer with high account tenure, stable payroll inflows, healthy balances, and low overdraft behavior is generally stronger than a customer with high current balance but volatile inflows and repeated NSF events.

Step 5 — Feature quality and missingness

• For missing balance history, create a missingness flag and a fallback indicator
• For customers with no checking history, separate them into a new “thin-file bank relationship” bucket
• Record denominator explicitly for all ratios (total_inflow, total_outflow, transaction_count)
• Use days_since_last_* features with a sentinel and companion boolean flags
• Handle low-historical customers carefully; an absence of signals is different from poor financial health

Step 6 — Leakage checklist

• No post-cutoff balance, inflow, or transaction data
• No future bureau pull or updated score beyond the cutoff
• No service outcomes resolved after the underwriting decision
• No future account openings, product changes, or new loan products after the cutoff
• No use of approval/reject outcomes as features in the model sample

Step 7 — Validation and selection

• Check time stability across monthly snapshots
• Compare feature distributions for approved vs declined populations
• Measure feature importance with SHAP or permutation importance
• Remove highly collinear features after checking business interpretability
• Prefer features with clear underwriting meaning over purely statistical “score” features

Step 8 — Testing and reproducibility

• Unit test each feature function for zero denominators, edge cases, and off-by-one errors
• Produce a feature registry with columns:
  • feature_name
  • description
  • source_table
  • window_days
  • type
  • business_use
  • owner
• Save a feature_spec.yaml documenting derivations and assumptions

Step 9 — Monitoring and production use

• Track PSI / drift for top underwriting features
• Monitor null-rate spikes from checking or deposit feeds
• Watch for sudden account-balance shifts caused by seasonality or product migration
• Validate model calibration on recent approval cohorts before redeployment

Example deliverables

• SKILL.md for underwriting design
• feature_spec.yaml for feature contract
• synthetic validation tests for cash-flow and account-balance logic
• a standardized feature registry for approval / limit-assignment use cases

Summary

This underwriting skill is explicitly different from general customer response or inactivity modeling. It focuses on a customer’s ability to support and repay card obligations using:

• deposit and checking balances
• inflow stability and direct deposit quality
• cash-flow resilience
• overdraft and NSFs
• account tenure and relationship depth
• cross-product banking behavior
• affordability proxies and repayment capacity

These are the features that matter most when deciding whether a customer can responsibly carry a credit card and how much they can support.