Bureau-based credit models are fundamentally backward-looking. They tell you what happened — how many times an account was paid on time, what the current utilization rate is, how long the oldest account has been open. These are states, not trajectories. They describe where a borrower is, not where they're headed.
Cash-flow velocity is the derivative. It describes the rate and direction of change in a borrower's financial position over time. Two applicants can have identical static cash-flow averages — same monthly income, same average balance — but completely different velocity profiles. One is accelerating into stability. One is decelerating toward stress. A model that only looks at the level misses the trajectory entirely.
What velocity means in the context of bank transactions
Velocity features in a credit model are defined over a time dimension. You're computing the slope — or curvature — of a financial variable over the lookback window, rather than its average level. The variables that carry the most predictive signal when expressed as velocity rather than level are:
- Net monthly cash flow trend — is the difference between monthly inflows and outflows increasing, flat, or decreasing over 24 months?
- Month-end balance trajectory — are end-of-period balances trending upward, stable, or declining?
- Income growth rate — is monthly income from identified sources increasing over the window?
- Obligations ratio trend — is the fraction of income consumed by fixed obligations increasing or decreasing?
- Minimum balance trend — is the lowest balance point in each month's cycle trending upward (building cushion) or downward (tightening)?
None of these can be derived from a bureau file. A credit card tradeline tells you the current balance and the payment history, but nothing about whether the cardholder's financial buffer has grown or shrunk over the past two years.
The informational gap in static snapshots
Consider two applicants with identical snapshots: $3,400 average monthly income, $1,200 average checking balance, zero overdrafts, regular rent payment. Bureau file: sparse, unscorable. The static cash-flow features look equivalent.
Applicant A, 24-month trajectory: income grew from $2,800 to $3,800 as they moved from hourly to salaried employment. Average balance grew from $600 to $1,900. Obligations ratio (rent + utilities as fraction of income) declined from 48% to 39%. Minimum pre-deposit balance grew from $120 to $340.
Applicant B, 24-month trajectory: income was $3,700 eighteen months ago, has declined to $3,100 due to reduced hours. Average balance has declined from $1,800 to $700. Obligations ratio has crept upward. Minimum pre-deposit balance has compressed from $400 to $90.
Same snapshot. Different trajectories. Applicant A is accelerating away from financial stress. Applicant B is moving toward it. A model without velocity features will assign these applicants similar scores. A model with velocity features will separate them, and the separation maps to meaningfully different default probabilities on a 12-month repayment horizon.
Feature construction: computing velocity cleanly
Computing velocity features from bank transaction data requires a few engineering decisions that significantly affect data quality.
Period granularity
Velocity is computed over periods. Month is the natural period for most financial behavior. But some applicants have semi-monthly pay cycles, some have weekly, some are irregular. Using calendar months for applicants with non-monthly income patterns introduces artificial volatility into income velocity calculations. A better approach: define periods relative to the detected income cycle for each applicant, then normalize to a monthly basis. This requires reliably detecting the income cycle, which is a prior step in the feature pipeline.
Linear vs. nonlinear trend detection
A simple linear regression slope over the full 24-month window is the most common velocity implementation. It works well when the underlying trend is approximately linear. It works poorly when there's a structural break — a job change, a major expense event, a period of illness — mid-window. An applicant who had declining balances for 18 months and then recovered strongly in the last 6 months will have a weak or negative linear slope despite positive recent momentum.
Better approaches weight the recent period more heavily, or segment the window into quarters and compute velocity direction per segment. A model that uses the slope of the last 6 months heavily in its velocity features is more sensitive to current financial trajectory than one treating all 24 months symmetrically.
At Lendiro, we compute velocity features over multiple windows simultaneously — 3 months, 6 months, 12 months, and 24 months — and let the model learn the appropriate weighting. The interaction between short-window and long-window velocity is itself informative: a positive 3-month velocity combined with a negative 24-month velocity suggests a recent recovery that the long-term trend doesn't yet reflect.
Handling income transitions
A common false velocity signal: an applicant changes jobs mid-window. Their income appears to drop to zero for one month (end of previous job) and then jump back (start of new job). A naive velocity computation reads this as high income volatility. The better feature: detect job transition events, flag the transition months, and compute velocity on the continuous-employment segments rather than across the gap.
This is a specific case of a general principle in cash-flow feature engineering: event detection should precede feature computation. Computing statistical properties on a time series with undetected structural breaks produces misleading features that look informative but aren't.
The KS statistic case for velocity features
When we add velocity features to a static cash-flow feature set on thin-file populations, the improvement in Kolmogorov-Smirnov (KS) statistic — the maximum separation between the cumulative distribution of good and bad performers at any score threshold — is consistently positive across holdout cohorts. The magnitude depends on the population composition: populations with more heterogeneous financial trajectories show larger KS improvement from velocity features than populations where income and balance levels are relatively stable.
The intuition is straightforward: velocity features add predictive signal specifically in the applicants with middling static cash-flow scores — the ambiguous cases where the level alone doesn't discriminate well. An applicant whose static features put them in the 40th-to-60th percentile of the score distribution is where velocity does the most work, separating the ones trending toward the 80th percentile from the ones heading toward the 20th.
A counter-argument: when velocity features hurt
We should be clear about a case where velocity features can reduce model performance rather than improve it: populations with very high income volatility where the volatility is structural rather than a risk signal.
Gig workers and seasonal employees have high income variability by design. A software contractor earning $5,500/month for nine months and $0 for three months while between contracts has large income velocity swings. A model that interprets the three-month zero-income periods as negative velocity signals will systematically under-score this population. If you're underwriting a population with significant gig or seasonal employment, velocity features need to be accompanied by income-type classification that flags high-volatility-but-structural income patterns and adjusts the velocity interpretation accordingly.
This is a feature engineering problem, not a fundamental flaw in velocity as a signal. But it's a reason not to implement velocity features naively and assume they improve performance across all sub-populations. Validate velocity feature contribution separately on gig vs. salaried sub-cohorts before deploying.
Integration with the Lendiro model
The Lendiro credit model uses velocity features computed across the four time windows described above, with gig-flag interaction terms for the income velocity features. We track the marginal AUC contribution of velocity features on each cohort of thin-file decisions and have observed consistent positive contribution of 0.03–0.07 AUC points over the static feature baseline.
That might sound small. At the decision boundary — where approvals and declines are made on the ambiguous middle — a 0.05 AUC improvement translates to a measurable reduction in false declines on creditworthy thin-file applicants. For a lender processing several hundred thin-file applications per day, that improvement in discriminatory accuracy compounds into significant portfolio performance over a quarter.
The bureau models your competitors are using have no access to any of this. They cannot compute a velocity feature because they don't have the data. That's not a claim about our model being better than FICO on bureau-scoreable populations — it isn't, and we don't compete on that terrain. It's a claim about which model is more informative on the 45 million applicants FICO can't score.
