When a platform operator first asks us about credit, the conversation usually starts the same way: "We pull bureau scores and that tells us what we need to know." That premise is the problem. A bureau score represents a snapshot of someone's credit history as reported to Equifax, Experian, or TransUnion. It reflects yesterday's data, yesterday's relationships, and yesterday's economic context. For a marketplace or vertical SaaS platform that already has months of behavioral data on this customer, starting with a bureau score means ignoring the most current signal you have.
This is not a small informational gap. It is a structural disadvantage that bureau-first platforms build into every underwriting decision they make.
What "Alternative Data" Actually Means in a Platform Context
The term "alternative data" gets used loosely in fintech, so it is worth being specific about what it means when you are operating a marketplace, vertical SaaS, or commerce platform. We are not talking about scraping social media or pulling rental payment histories from third-party aggregators. We are talking about signals that your platform already generates naturally through normal user activity.
Transaction velocity is the most direct example. If a buyer on your platform has completed 40 purchases in the past 90 days with zero disputes, that behavioral pattern is informative in a way that a bureau score cannot be. The bureau score might show limited history because this person is young, recently immigrated, or simply prefers cash and debit. Your platform data shows consistent, low-friction transaction behavior at meaningful volume. That is a credit signal your competitors cannot access because it lives on your platform.
Merchant category mix matters similarly. A buyer who consistently transacts with professional services vendors, B2B software subscriptions, and industry tools looks different from a buyer whose spend is concentrated in single-purchase consumer goods. Both might carry the same FICO band, but their default risk profiles over a 6-month loan term differ substantially. Your data can distinguish them. A bureau score cannot.
The Thin-File Problem Is Bigger Than You Think
The Consumer Financial Protection Bureau has published research estimating that roughly 26 million Americans have no usable credit file and another 19 million have files that cannot be reliably scored using traditional bureau methods. That is a large excluded population. But for platforms serving specific verticals, the problem is often more concentrated.
Consider a B2B marketplace serving independent contractors and freelancers. A significant fraction of that user base may run their business finances through a personal account, have irregular income, and have thin bureau files despite being financially stable, cash-generating operators. A bureau-first underwriting engine will either reject them outright or price them at the top of the risk band. Your platform data, which might include years of on-time invoice completion, consistent monthly transaction counts, and seasonal income spikes that correlate with their industry cycle, tells a much more accurate story.
We built the Lendforge scoring layer specifically around this problem. The model ingests platform-native signals alongside any bureau data you choose to pull, weights them through a gradient-boosted model trained on marketplace default outcomes rather than generic consumer credit, and produces a composite credit score alongside individual factor contributions. When a bureau file is thin, the model shifts weight toward platform signals automatically rather than defaulting to a rejection.
Merchant Category Mix as a Forward Signal
One pattern we see repeatedly that surprises platform teams: merchant category mix is often more predictive of near-term default than the applicant's own credit history. Here is the intuition. If a buyer's transaction history on your platform shows an abrupt shift from recurring business purchases to one-off high-value consumer goods, that shift frequently precedes a financial stress event. The behavior changes before any credit bureau data reflects it because bureau data requires a delinquency to occur, get reported, and then age into the score calculation. That process takes months. Platform behavioral data is current to the moment of application.
We are not saying merchant category mix is a silver bullet, and we are not saying bureau scores are worthless. Bureau scores remain highly predictive for borrowers with long, stable credit histories and diversified trade lines. The argument here is narrower: for the populations that platforms naturally attract, especially thin-file, new-to-credit, and gig-economy users, bureau scores leave significant predictive information on the table. Platform-native signals recover much of it.
How Lendforge Ingests Platform Data
The practical implementation question is how you get platform data into the underwriting model without creating a custom integration project that takes six months. Our approach is API-first with a structured event schema. You send us a transaction log: timestamps, transaction amounts, counterparty categories, completion outcomes, dispute flags. We normalize it and derive features on our side. Your engineering team does not need to think about what features to compute; they just need to send us the raw event stream in the format we specify.
The Lendforge data pipeline handles feature derivation, including trailing velocity windows at 7, 30, and 90-day intervals, merchant category entropy calculations, dispute-to-completion ratios, and seasonal deviation from individual user baselines. These are the signals that distinguish a temporarily quiet user from one who is actually declining in activity. Your platform engineers do not need to implement this logic; we run it on the ingested event stream before the model scores.
One detail worth flagging for technical teams: the event timestamp matters. If you send us events without accurate timestamps, we cannot compute velocity windows properly and the feature quality degrades. This is a common gotcha during initial integration. The Lendforge schema documentation covers timestamp handling, including how to handle timezone normalization and how to flag retroactively submitted events.
What This Means for Approval Rates and Pricing
Platform teams typically come to us with one of two goals: increase approval rates for creditworthy applicants who are being rejected, or improve risk pricing accuracy to reduce loss rates. Alternative data helps with both, but through different mechanisms.
On the approval rate side, the gain comes primarily from thin-file applicants who have strong platform behavioral history. These are users your bureau-first model is currently declining or sending through to a manual review queue. The Lendforge model can price these applicants into the right risk tier rather than treating "no bureau history" as equivalent to "bad risk."
On the pricing accuracy side, the gain comes from distinguishing within bureau score bands. Two applicants at the same FICO score are not identically risky when one has 3 years of dense, clean platform transaction history and the other opened their account 30 days ago. The model separates them. This separation lets you offer better pricing to the low-risk segment of any bureau band, which improves conversion without proportionally increasing default exposure.
A growing marketplace in the SMB equipment category integrated Lendforge in Q1 2025 and ran an internal holdout comparison against their legacy bureau-only model over 90 days. The most meaningful finding was not a single approval-rate number; it was the distribution shift in declined applicants. A measurable portion of the legacy model's declines had platform behavioral profiles that the Lendforge model scored into the middle risk band. Those users were creditworthy by platform-native evidence; the bureau model had simply not seen them.
The Limits of Platform Data
Fairness and accuracy go together when the training data is well-constructed, but platform data can introduce its own biases. If your platform historically served a narrow geographic or demographic segment, your transaction-based features will reflect that population's behavior patterns. A model trained on that data may not generalize well to new user segments. We handle this through population monitoring at the feature distribution level, with alerts that fire when applicant cohorts start deviating from training-data distributions. It is not a fully automated solution to data drift, but it surfaces the issue before it silently degrades model performance.
There is also a temporal limitation. Platform-native signals are only informative for users who have history on your platform. First-time applicants, by definition, have no transaction velocity, no merchant category history, no completion rate. For this population, bureau data carries more weight in the Lendforge model, not less. The model does not treat platform history as a requirement; it treats it as additional signal that increases confidence when present.
If you are running an underwriting process today that leans entirely on bureau pulls, the question worth asking is not whether alternative data can help in theory. The question is what specific applicant population in your funnel is currently being priced incorrectly because your model cannot see what is in your own transaction logs. That is the gap Lendforge was built to close.