A credit model is only as good as its inputs. The feature engineering step, deciding what signals go into the model and in what form, is where most of the real work happens in building a high-performing credit decisioning system. Yet most traditional underwriting infrastructure still defaults to a narrow input set: bureau score, stated income, debt-to-income ratio. For a marketplace or digital platform, those three inputs describe a thin slice of what you actually know about an applicant.
This post covers how we think about feature selection and construction for platform credit risk models. The signals we find most predictive are not exotic; they are behavioral and transactional data that the platform already generates as a byproduct of its normal operations. The challenge is in structuring that data into features that a gradient-boosted model can actually use, and doing it in a way that survives fair lending scrutiny.
Why Bureau-First Models Leave Money on the Table for Platform Lenders
A bureau score is a backward-looking, population-level signal. It tells you what happened to people with similar credit histories in the past, aggregated across millions of consumers who may share nothing else in common with your applicant. For a lender whose borrowers are all users of a specific marketplace, that population-level average may be a poor predictor of default within your specific user base.
Consider a home services marketplace where sellers use a working capital product to buy materials before a job. The seller's bureau score might be a 640 because they had a medical collection three years ago and carry a high revolving balance. But their transaction history on the platform shows twelve completed jobs in the past six months, consistent 5-star ratings, and repeat orders from the same buyers. Their platform-native behavior predicts repayment better than a generic bureau score, because the loan we are underwriting is directly tied to a revenue stream we can observe.
Bureau-only models applied to that population will reject a cohort of creditworthy borrowers who happen to look thin on traditional signals. That is not just a revenue problem; it is a fair lending concern, because the borrowers most likely to be underrepresented in bureau data skew toward specific demographic groups.
Behavioral Features: Transaction Velocity and Recency
Transaction velocity, how many transactions a user has completed in a rolling window, is one of the strongest predictors we have seen for short-term liquidity and business health. We typically construct this across multiple windows: 30-day, 90-day, and trailing-12-month. The ratio between the short window and the longer window captures acceleration and deceleration patterns that point-in-time averages miss entirely.
Recency matters differently for repayment behavior than it might seem. A seller who has not transacted in 45 days on a marketplace is a weaker credit risk not because they are less capable of repaying, but because the platform-observable revenue stream that the loan is tied to may have slowed. Recency-adjusted transaction counts help the model distinguish between a seasonal lull and a structural decline in activity.
We do not count all transactions equally. We weight by gross merchandise value where the platform exposes it, because a single $4,000 job completion is a better liquidity signal than ten $40 gig payments, especially when the loan amount is in the $2,000 to $10,000 range.
Platform Tenure and Stability Features
Time on platform is a proxy for business stability that has no equivalent in bureau data. A seller who has been active for 18 months and maintained consistent monthly volume has demonstrated something that a 3-month-old account with similar recent volume has not: survival through slower periods, seasonal variance, and the natural churn that affects new marketplace participants.
We construct a tenure quality score that combines account age with consistency. Raw tenure is not enough. An account that has been live for two years but had six months of complete inactivity has a different risk profile than an account with continuous two-year activity. The gap detection logic is straightforward to implement: compute the maximum inactivity gap in days within the observation window and include it as a feature. Models trained on platforms with seasonal verticals, like home improvement or event planning, find this signal especially informative.
Merchant Category Mix and Diversification
On multi-category marketplaces, the mix of transaction types carries predictive information. A seller operating across three or four categories of service is typically more resilient to demand shocks in any single category than a seller concentrated in one. We compute a Herfindahl-Hirschman-style concentration index over a seller's transaction category distribution and use it as a diversification feature.
This is admittedly platform-specific. Not all marketplaces have enough category depth to make this signal meaningful. But for platforms with real category breadth, it consistently enters the top fifteen features by importance in our gradient boosted models.
Seasonal Variance and Normalization
Seasonal variance is a feature engineering problem, not just a model problem. If your platform has strong seasonality (as most commerce-adjacent platforms do), a borrower's raw transaction volume at the time of application is not directly comparable to the same raw volume six months later. A $30,000 trailing-90-day GMV in October means something different for a holiday goods seller than for a lawn care provider.
We handle this with seasonal normalization relative to platform-wide cohort medians for the same calendar period. The normalized feature captures whether the borrower is outperforming, matching, or underperforming their peer cohort for that time of year. This matters especially for default prediction models where the training data spans multiple years and multiple seasonal cycles.
Fair Lending Implications of Non-Traditional Features
Using non-traditional features does not exempt you from fair lending obligations. It changes the analysis you need to do. For each feature you add to the model, you need to understand whether it correlates with a protected class in your applicant population and, if so, whether that correlation is justified by predictive validity independent of the protected class variable.
We are not saying you should avoid features that are correlated with protected class attributes. Platform tenure, for example, may correlate with age in some user bases. The question is whether tenure has independent predictive power after controlling for protected class. If it does, it is a defensible feature. If the only reason it predicts default is as a proxy for age, it is not.
In practice, we run disparity testing across all features before including them in production models and document the analysis in a format that a compliance team can review. This is part of the model development lifecycle, not an afterthought. A model that performs well on discrimination metrics but cannot be explained to a compliance officer or bank examiner is not usable in a regulated product context, regardless of its predictive accuracy.
Feature Pipelines in Production
Feature engineering is not a one-time activity. Platform behavior shifts over time, and so does the predictive value of individual features. We maintain rolling validation cadences that monitor feature drift, meaning the change in input distributions over time, separately from model performance monitoring. A feature that drifts significantly can degrade model performance before any change appears in top-line approval rates or vintage default curves.
For platforms we work with, the integration contract includes a data schema specification that defines exactly what events and attributes feed the feature pipeline. That spec is version-controlled and change-managed in the same way you would manage a production API schema. When a platform makes a product change that affects transaction categorization or removes a data point we were ingesting, we need visibility before that change goes live in order to re-validate the affected features.
The alternative, discovering feature drift after it has already affected model performance, is a much more expensive problem to diagnose and fix. Good feature engineering discipline starts with treating the data inputs as a first-class contract, not as a byproduct of whatever the platform happens to log.