The problem I kept running into was not that platforms did not want to offer credit to their users. It was that the credit infrastructure available to them had not been designed for how platform businesses actually work. The tools were built for banks and traditional lenders, ported awkwardly into API form, and sold to platforms with the assumption that a bureau score would do most of the heavy lifting. For a marketplace with two years of behavioral data on every seller, that assumption is spectacularly wasteful.
I spent several years in financial services and consumer lending technology before starting Lendforge in 2023. What I kept seeing was the same pattern: a digital platform with rich, longitudinal data on its users would try to add a credit product, go through the typical integration options, and end up with an underwriting model that ignored nearly everything the platform knew about its own users. The model would pull a bureau score, verify income, check a few standard tradelines, and spit out a decision. The platform's data, the signals that would actually distinguish a good risk from a bad one in that specific context, sat unused.
The Mismatch That Started Everything
The specific example that crystallized this for me was watching a home services marketplace try to launch a working capital product for their sellers. The sellers on this platform had, in some cases, years of transaction history, rating data, repeat customer relationships, and seasonal patterns that were completely predictable. A seller who had been active for eighteen months with consistent volume and no complaints was about as legible a credit risk as you can find. Their bureau score might be mediocre because they carried personal debt, but their ability to service a small business loan tied to their platform revenue was very clear from the platform data.
The credit provider they worked with pulled the bureau score, saw the revolving debt, and declined a meaningful cohort of their best sellers. The approval rate was low enough that the program did not generate enough origination volume to justify the integration cost. The platform shelved the credit product eighteen months after launching it.
That is not a technology failure. It is a decisioning failure. The information needed to make a good credit decision was available; it was just invisible to the model being used.
Why Not Just Build a Better Scoring Model?
When I started thinking about what a purpose-built solution would look like, the obvious instinct was to build a better scoring model. Train a gradient-boosted model on platform transaction data, incorporate the behavioral signals, outperform the bureau-first approach. That part is not actually that hard, technically.
The hard parts are everything else. Connecting to the bank partnership infrastructure so the platform does not need a lending license. Building the adverse action logic so that when you use alternative signals, you can still produce Regulation B-compliant adverse action notices. Maintaining the model audit trail and documentation that a bank partner's examiner will actually look at. Handling the real-time latency requirements of a checkout-embedded decision. None of those are model problems. They are infrastructure problems.
A platform team that wanted to do this themselves would need to hire credit risk talent, compliance counsel, bank partnership relationship management, and devops infrastructure, while simultaneously running their actual product. That combination is not feasible for a marketplace or digital platform at any stage below something quite large. And even large platforms have usually decided that credit infrastructure is not a core competency they want to own.
We built Lendforge as the full stack: the decisioning model that uses platform-native signals, the API layer that fits inside a checkout flow, the compliance infrastructure that satisfies bank partner requirements, and the reporting and documentation that makes the program examinable. The platform provides its data; we handle the credit function.
What Charlotte Has to Do with It
We are based in Charlotte, which matters more than it might seem. Charlotte is the second-largest banking center in the United States by assets. The relationships that a credit infrastructure company needs to function, the bank partnerships, the compliance networks, the regulatory familiarity, are concentrated here in a way that is hard to replicate elsewhere. Starting Lendforge here was a deliberate choice, not just a matter of where I happened to live.
Charlotte is also not a fintech hub in the way that San Francisco or New York are. There are fewer early-stage companies here competing for attention, which means we can build genuine relationships with banking counterparts rather than being one of dozens of startups in a pitch pipeline. The fintech community here is smaller, more collaborative, and more grounded in how traditional financial services actually work. For a company building infrastructure that has to work inside regulated banking structures, that orientation matters.
What We Are and What We Are Not
Lendforge is not a lender. We do not hold loans on our balance sheet and do not bear credit risk directly. We are a decisioning and origination engine that platforms integrate into their credit programs, working within bank-partner structures where the bank remains the lender of record. That distinction is important for how platforms should think about the risk they carry and how they should structure their programs.
We are also not trying to be the platform's compliance department. We build the tooling that makes compliance tractable: the adverse action reason codes, the model documentation, the decision audit trail, the fair lending testing infrastructure. But the platform owns the bank relationship, the program agreement terms, and the final compliance posture. We want to make that compliance work significantly easier, not to substitute for it.
I started Lendforge because I thought there was a genuine gap in what was available to platforms that wanted to build serious credit products, not just staple on a third-party BNPL option. Building real credit infrastructure, with real underwriting, for a specific user population with specific behavioral data, should not require a platform to assemble a credit team from scratch. That is the problem we are here to solve.
What We Have Learned Since Launching
The assumption we validated early: platform operators are underserved by generic credit tooling, and they do have data that improves underwriting. The thing that surprised us: how much compliance readiness varies across platforms evaluating embedded lending. Some platforms come to us having already talked to a bank partner and having a rough program structure in mind. Others come in not knowing what a sponsored-bank arrangement is or why it matters.
Both are fine starting points. We have built the onboarding process to work from wherever the platform is in their understanding of embedded lending. The teams that move fastest are the ones where at least one person on the product or risk side has worked in financial services before and can contextualize the infrastructure we are providing. But deep fintech experience is not a prerequisite for using Lendforge. The product is built to handle the complexity on the back end so that platform teams can focus on their user experience and their credit program goals.
Two years in, the core thesis holds: platforms that know their users well, and whose users have meaningful behavioral histories on the platform, can build much better credit products than what legacy bureau-first decisioning delivers. The infrastructure to do that at a reasonable integration cost and compliance standard is what Lendforge provides. That is why we built it.