Vendors First: Payment Risk

Businesses that win government contracts often wait a long time to get paid, and payment delays can put real pressure on their cash flow. Vendors First is a fintech working on exactly that problem for businesses on public contracts. During my iXperience Data Science + AI internship in the summer of 2026, our intern team investigated whether payment-delay risk could be predicted from the characteristics of an award: who is paying, through which program, and for how much.

There was no ready-made modeling table waiting for us. Our team researched publicly available county and federal government award information, focusing on Southern California jurisdictions, and assembled it into an analytical dataset. Each record describes a government award payment: the county, the recipient, the awarding agency, the federal assistance program, the obligated and outlaid amounts, the percentage outlayed, and the processing lag in days. 500 of these records were used in the modeling analysis.

That distinction matters to me: the underlying data came from public sources through our own research, not from a confidential transaction database handed to us.

Working in Databricks, we cleaned and structured the data: normalized the columns, coerced the numeric fields, imputed the few gaps with medians, and explored the distributions. Processing lags ranged from a single day to over a year, with a median of 23 days. We defined "late" as a processing lag above that median, which turns the question into a balanced binary classification problem; it also means "late" here is relative to the dataset's own typical speed, not a contractual deadline.

The assembled sheet also carried precomputed risk rankings that were derived from the processing lag itself, the very thing we were predicting. Letting those columns, or the lag, into the feature set would have produced impressive and meaningless results. I caught that and kept the features to what would genuinely be known in advance: county, agency, program, and the award amounts.

I built two classifiers in scikit-learn on an identical stratified train-test split, so the comparison is fair. The first was a random forest with 500 trees and balanced class weights. The second was a logistic regression on standardized features, also class-balanced: a deliberately simpler, more transparent model to test whether the forest's flexibility was actually buying anything.

The two models performed almost identically: the random forest reached a ROC-AUC of 0.758 and the logistic regression 0.761, both clearly above random guessing. The logistic regression caught 84% of the genuinely late payments, at the cost of more false alarms, a trade-off that makes sense when a missed risky payment costs more than a review that turns out fine. When a simple interpretable model matches a complex one, that is useful knowledge in itself: you can choose the model whose reasoning you can explain.

Reading the logistic regression's coefficients, the share of funds already outlaid was the strongest single risk-raising signal, with particular agencies and assistance programs pushing risk in both directions. The honest caveats: 500 records is a small sample, the median-split target is relative rather than contractual, and public award characteristics are proxies for internal payment processes we could not observe.

My work on this project was practical end to end: researching and assembling public data, cleaning it in a Databricks workflow, building and evaluating the models in scikit-learn, and communicating what the results did and did not mean. The lesson that stuck is that the most valuable thing I did wasn't improving a score. It was noticing when a score would have lied, and keeping the evaluation honest enough that the numbers mean what they say.