# Customer Creditcard Underwriting

> Build leakage-safe underwriting features for credit card approval, credit-limit assignment, and risk segmentation using customer banking relationships, checking/deposit activity, cash-flow performance, and other-product behavior. Covers balance, liquidity, cash-flow stability, overdraft, tenure, and cross-product signals while enforcing as-of-date rules for production modeling.

- Skill: `nageshwarreddyl/customer-creditcard-underwriting` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add nageshwarreddyl/customer-creditcard-underwriting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nageshwarreddyl/customer-creditcard-underwriting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: NageshwarReddyL (https://skillmd.com/u/nageshwarreddyl)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/nageshwarreddyl/customer-creditcard-underwriting

---


# Credit Card Underwriting Features

This skill complements the broader banking/card feature playbook in [customer-creditcard-features/SKILL.md](../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.

| Table | Grain | Key columns |
|---|---|---|
| `customers` | one row per customer | `customer_id`, `dob`, `signup_ts`, `tenure_months`, `kyc_level`, `residency`, `income_band` |
| `deposit_accounts` | one row per deposit product | `customer_id`, `account_id`, `product_type`, `opened_ts`, `closed_ts`, `status` |
| `checking_accounts` | one row per checking account | `customer_id`, `account_id`, `opened_ts`, `status`, `account_type`, `daily_balance_ts` |
| `account_balances` | daily/monthly snapshot | `customer_id`, `account_id`, `snapshot_date`, `available_balance`, `ledger_balance`, `avg_daily_balance`, `minimum_balance` |
| `transactions` | one row per banking transaction | `customer_id`, `account_id`, `txn_ts`, `amount`, `direction`, `merchant_category`, `channel`, `merchant_id`, `txn_type`, `is_debit`, `is_credit` |
| `direct_deposits` | one row per payroll or recurring inflow | `customer_id`, `account_id`, `deposit_ts`, `amount`, `payer_type`, `source_name` |
| `overdraft_events` | one row per NSF / overdraft event | `customer_id`, `account_id`, `event_ts`, `amount`, `fee_amount`, `result` |
| `cards` | one row per card account | `customer_id`, `card_id`, `opened_ts`, `status`, `credit_limit`, `utilization`, `product_type` |
| `loan_accounts` | one row per loan product | `customer_id`, `loan_id`, `product_type`, `opened_ts`, `status`, `current_balance`, `monthly_payment` |
| `applications` | one row per application | `customer_id`, `application_id`, `submitted_ts`, `decision_ts`, `status`, `requested_limit` |
| `bureau` | one row per bureau pull | `customer_id`, `pull_ts`, `score`, `utilization`, `delinquency_count`, `open_trades`, `recent_inquiries` |
| `digi` | app / online banking activity | `customer_id`, `session_ts`, `channel`, `event_type`, `session_duration` |

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.