AI Tech Inspire

How to Spot Clients Who Never Intended to Pay: Data, Features, and Modeling

Some credit risks look like ghosts: they transact just long enough to blend in, then vanish when it’s time to repay. That’s precisely the scenario drawing interest across risk teams right now—how to detect clients who take credit with no intention to pay from the outset, versus those who become unreceivable later. At AI Tech Inspire, we spotted a thoughtful brief seeking practical guidance: data design, feature engineering, modeling choices, and evaluation under heavy class imbalance. Below is a structured, practitioner-friendly take that developers and data scientists can put to work.

Key facts from the brief

  • The problem targets early detection of clients who take credit without intent to pay, using historical behavior.
  • Available data is split into three buckets: (1) fraudulent transactions for known bad clients, (2) good transactions from those bad clients (periods of normal behavior), and (3) good transactions from all other clients.
  • There are two major “bad” client types: unreceivables (later refused or unable to pay) and fraud-in-origin (never intended to pay).
  • Open questions include: comparing a client’s good vs fraudulent transactions; how to use good transactions from all clients; which behavioral features signal intent not to pay; whether to model unreceivables vs fraud-in-origin together or separately.
  • Requested guidance: ideal dataset structure, feature ideas, best modeling paradigm (classification vs anomaly vs hybrid), and evaluation strategies under severe class imbalance.

Design the dataset for intent, not just outcome

Predicting intent requires careful time-aware structure to avoid leakage. A practical approach:

  • Entity granularity: Treat data at the client and event levels. Aggregate transactional sequences into rolling windows (e.g., 7/14/30 days) to create snapshots before an outcome is known.
  • Labeling strategy: Anchor labels by the first delinquency/default or fraud confirmation. For fraud-in-origin, label clients based on early lifecycle indicators (e.g., first credit line usage). For unreceivables, label windows leading up to default. Never compute features using post-outcome data.
  • Use all three buckets deliberately:
    • Good transactions from bad clients are gold—these represent the “before” period. Use them to engineer early warning features.
    • Good transactions from all other clients form your control group. Stratify by tenure and product to avoid bias (new, low-activity clients can look suspicious simply because of limited history).
    • Fraudulent transactions are positive evidence but skewed toward the end state. Prefer windowed aggregates leading up to them rather than mixing in post-fraud behavior.
  • Time splits: Use chronological train/validation/test splits. Intent changes with seasons, economic cycles, and policy. This guards against overfitting to yesterday’s patterns.
  • Sampling: Undersample negatives to balance training batches, but evaluate on full, imbalanced holdouts. Keep client-level independence across splits.

“If a feature can only be known after someone stops paying, it’s not a feature—it’s a leak.”

Behavioral features that signal intent not to pay

Beyond generic credit scores, intent shows up as volatility, identity stability, and opportunistic patterns. Consider features grouped into themes:

  • Velocity & ramp-up: sudden spikes in credit utilization, purchase frequency, ticket size, and category hopping within a short inception window.
  • Payment behavior micro-signals: minimal payments, erratic payment timing, card-spend right before statement cuts, or repeated grace period exploitation.
  • Identity and device stability: number of devices, device persistence across sessions, IP/geo changes, OS/browser fingerprint churn, mismatch between declared and observed geos. Use ratios like unique_devices / days_active.
  • Network signals: shared phone numbers, emails, addresses, or devices across multiple accounts; graph features like degree, triangles, component size. Graph embeddings (e.g., Node2Vec-style representations) can help—trainable in PyTorch or TensorFlow.
  • Merchant/ MCC risk: high-risk categories, time-of-day concentration, refund/chargeback patterns, and merchant diversity score.
  • Lifecycle markers: distance from onboarding, KYC friction (retries, mismatches), profile edits (email/phone/address changes) before large draws.
  • RFM + variance: Recency, Frequency, Monetary value plus volatility (std/mean), Gini coefficients of spend across categories, and entropy of counterparties.
  • Text or form signals: if permissible, encode application fields (profession, employer, free-text justifications) using lightweight embeddings via Hugging Face models, but beware of privacy constraints.

For tabular baselines, gradient-boosted trees like XGBoost or LightGBM often outperform complex deep models on structured credit data and provide fast iteration cycles.

Should unreceivables and fraud-in-origin be modeled together?

They share symptoms but diverge in mechanics. Three practical patterns:

  • Separate models: One model for fraud_in_origin, another for unreceivable. Pros: tailored thresholds/features. Cons: operational complexity.
  • Multi-task model: Shared backbone with two heads (probabilities for each outcome). Helps when data is limited and behaviors overlap.
  • Two-stage pipeline: Stage 1 flags “bad-risk” broadly; Stage 2 refines into fraud-in-origin vs unreceivable. This mirrors how many risk ops teams triage cases.

As a rule of thumb, start with a unified classifier for bad_intent_or_default to establish signal, then split once data volume and labels justify.

Classification, anomaly detection, or hybrid?

All three can be valuable—at different points:

  • Supervised classification: The workhorse for production. Train on labeled windows. Models: gradient boosting, calibrated logistic regression, or sequence models (e.g., transformer encoders in PyTorch for event streams). Pros: best precision when labels are good.
  • Anomaly detection: Isolation Forest or One-Class SVM from scikit-learn, or autoencoders in TensorFlow. Pros: finds novel fraud patterns. Cons: high false positives unless constrained by business rules.
  • Hybrid: Use anomaly scores as features inside the classifier; or run anomaly detection on high-risk clusters the classifier is uncertain about.

Bonus: for early warning, survival or hazard models estimate the probability of default within T days, giving a tunable lead time for interventions.

Evaluation that respects class imbalance (and money)

Accuracy is meaningless here. Measure what maps to dollars and ops capacity:

  • Metrics: AUCPR, Precision@k, Recall at fixed Precision, and Expected Monetary Value per 1,000 accounts. Calibrate probabilities via isotonic or Platt scaling.
  • Cost-sensitive thresholds: Optimize thresholds on an expected value curve that includes credit loss, recovery cost, and customer friction.
  • Lead time: Measure recall at ≥ X days before default/fraud. A model that gives 10 days of notice with slightly lower precision may be worth it operationally.
  • Stability: Track Population Stability Index (PSI) and feature drift. Revalidate quarterly; macro shifts can invert assumptions fast.
  • Backtesting & temporal CV: Roll forward through time; never shuffle. Evaluate policies as decision systems, not just models.

“Precision@k is useful, but the score the CFO cares about is expected loss avoided.”

Putting it together: a practical baseline pipeline

Here’s a concrete plan that teams can implement with standard tooling:

  • Data windows: build 7/14/30-day rolling snapshots per client leading up to outcomes; exclude post-outcome data.
  • Features: velocity/volatility, device stability, network link counts, RFM, merchant entropy, lifecycle markers.
  • Model: XGBoost baseline; add class weights or focal loss; probability calibration.
  • Anomaly add-on: Isolation Forest score from scikit-learn as an extra feature for novelty.
  • Interpretability: Use SHAP to surface top drivers for reviewers and policy teams.
  • Thresholding: tune for Expected Value; operationalize multiple bands (e.g., deny / manual_review / approve).
  • Monitoring: drift watchers, PSI, alerting. Keep a shadow model for A/B comparisons.

If you need sequence context (e.g., order of actions in the first 10 days), add a lightweight transformer encoder in PyTorch and export to run on GPU with CUDA for real-time scoring.

Why this matters for developers and risk engineers

Intent is a moving target. Bad actors probe systems, learn the rules, and evolve. Engineering teams need pipelines that are:

  • Time-aware: no leakage, chronological validation.
  • Feature-rich: identity, behavior, and network signals—not just credit ratios.
  • Decision-ready: scores that map to actions and queue sizes, not vanity metrics.

Press Shift + Tab on any feature set and ask, “Would this still be available at decision time?” If not, you’re training on hindsight.

Open questions to explore next

  • Reject inference: how to learn from applicants you declined? Techniques like positive-unlabeled learning can help.
  • Fairness and compliance: audit for disparate impact; document which features drive decisions.
  • Human-in-the-loop: active learning from analyst feedback to catch emerging patterns faster.

The short version: use early lifecycle windows, lean on behavioral and identity stability features, start with a calibrated classifier, and augment with anomaly scores for coverage. Separate models for unreceivables vs fraud-in-origin can come later if the data says so. The reward is an intent detector that gives teams the one thing money can’t usually buy in credit risk: time to act.

Recommended Resources

As an Amazon Associate, I earn from qualifying purchases.