Fintech’s aim is to create real economic productivity by reducing the cost of human labor in payments, creating faster settlements, and expanding the financial access pool to underserved groups.
These are all visionary goals. In vertical software, often what this boils down to is a pretty pragmatic case on monetization: payments adoption is really good for the bottom line.
Some of the best vertical tech companies have been built off transactional volume within the B2C payments space. The question - with trillions of payments volume on the line - is how to build the same sorts of verticalized payments within B2B.
And it turns out that most of the problems in B2B payments stem from vertical-specific challenges revolving around coordination.
B2C
B2C vSaaS companies operate in a world where raw payments coordination issues - how does money get from a consumer to a merchant - have been solved. We’ve developed a whole network of issuers and acquirers to increase speed, reduce fraud risk, and guarantee settlement. This network makes two things possible:
It allows new startups to tap into the network without worrying all too much about these coordination issues.
It allows merchants never think about payments. If a credit card gets swiped, that money is going to show up in their bank account down the road. A merchant views payments as a commodity offering vs. something worth tons of brainpower.
These two factors mean that vSaaS startups are able to tap into payments infrastructure while still prioritizing software that improves the consumer experience or makes operations more efficient. In exchange for great software, merchants are happy to hand over their payments volume. This arrangement only exists because nobody has to think all too much about payments.
B2B offers an entirely different set of coordination issues.
B2B
In B2B, we have both infrastructural gaps and coordination challenges.
Payments aren’t often digitized, speed is still a secondary concern (FedNow and RTP might change this), and we have plenty of human capital spending time auditing bank statements and invoices.
The space will enjoy productivity gains from incremental improvements in the rails, but unlike B2C, entering the flow of funds and facilitating payments does not de facto solve the actual efficiency issues in B2B payments.1
As I’ve written about in the past, we are dealing with larger value transfers with payment often locked at the contractual level in net-30, 60, 90 day terms.
A house gets built, a trucker hauls across the continent, an insurance policy is sold, or a line of credit is established.
These value transfers involve coordination issues not only with the delivery of the actual good or service, but with the delivery of payment itself.
Problem number one: We’ve built inherent lag in payments via contractual payment terms to account for the variability in the real world. Other contractual terms often add even more opacity.
Problem number two: Workflows around the payment impact the payment more than the speed of the rail.
In almost every industry, we are dealing with complex webs full of lenders, servicers, distributors/brokers, and more. These payments value chains are often opaque, industry specific, and highly dependent upon other counterparties.
What this practically means is that the most impressive vertical B2B fintechs often are not busying themselves initially with payments faciliation ie the actual money movement, but instead with the workflows around payments coordination.
In other words, they look a lot more like software.
Built
In construction, funds get released according to milestones. That sounds simple enough, at least until you look at the full value chain of lenders, developers, builders, GCs, and various subcontractors. And while payments flow top-down from this chain, delays and milestone requirements flow bottoms-up.
This makes coordination incredibly difficult and projects not only stall over real delays, but over late payments as well.2
That’s the problem Built set out to solve. They focus upon two groups at different points in the payments chain: lenders and general contractors. Lenders need to vet projects and ingest draw requests to move money to borrowers. That implies several different workflows that their software side can speed up. This creates real productivity value within the payment chain without even necessarily moving the money themselves.
That’s not the only point in the value chain they’re tackling. Built also works with GCs to facilitate payments via better invoicing and payout processes for subcontractors. But much like with the lenders, their focus is far more upon the compliance obligations, lien filings, and more that precipitate an invoice being paid.
Their next large opportunity (and what they are already working on) is to connect the entire payments ecosystem together with software aimed at every participant in the value chain to help streamline the processes surrounding payments.
And if they do that, why not ultimately just build the construction payments clearing house connecting supply (lenders) to demand (builders) and everything in between?
Finley
Finley is best viewed as a diagonal SaaS company laser-focused on the ops implications of massive debt facilities. Private credit is eating the world. The banks have fled much of the debt scene. And these debt facilities are increasingly packaged inside of SPVs.
Every industry is implicated in this trend, but private credit is an industry all of its own. These SPVs come bundled with contractual terms, monitoring requirements, and plenty of implications on draw requests and more. Again, these are large payment transfers comprising increasingly vast swaths of the economy.
All these terms and monitoring requirements add up to real costs in debt facilitation. And in the same way, Carta and others significantly decreased the financial operations involved in equity raises, Finley is looking to do the same for debt. The result could be a Carta-esque platform that not only acts as the system of record for much of the SPV debt space, but a workflow tool that decreases the operational complexity in leveraging debt altogether. That in turn will directly increase the velocity of B2B transfers in the space.
Procurement Generally
A massive benefit of the rise in B2B payments infrastructure is the opportunity for new sorts of payments networks.3
The next generation of procurement platforms are already looking to solve complexities involved in fragmented supply and demand functions within an industry and often esoteric workflows around the procurement process.
Because of this, they are set to become hotbeds for B2B payments activity.
In effect, by streamlining the coordination issues around the payment itself, either via better ordering, supplier aggregation, or some other value-add, their next evolution is to build closed-loop payment networks.
Does this simply resemble a B2B marketplace? Sorta, but not entirely.
B2B marketplaces seek to primarily aggregate supply and demand. Procurement layers rewire an entire organization’s purchasing workflow and seek to solve back-office pain points vs simply focusing on the flow of goods or services.
That creates lock-in and means that many sorts of procurement layers can evolve into closed-loop payments networks.
Closed Loop
Closed-loop payment networks aim to create networks that advantage participants if they keep money within the network.
The easy examples here are Cash App or Starbucks.4
Starbucks allows you to load a wallet up with funds and transact with their coffee shops to gain rewards. Cash App internalizes similarly internalizes peer-to-peer transactions - payments somewhat stay within their ecosystem.
The vertical example of this is Wex - a fleet card company whom built a network of gas stations partners with incentives for fleet card use at these stops. All of these gas stations want more traffic and giving incentives to increase traffic from truckers via fuel discounts and more is a no brainer. And while the rewards and fuel discounts are valuable and incentivized card adoption amongst the fleets, simultaneously the closed-loop ecosystem allowed Wex to build robust analytics tools on fuel spend and more.
A similar future awaits procurement. Once you substantially aggregate suppliers and demand into a common procurement layer, you can begin to gain meaningful payments adoption by developing wallet functionality, rewards programs, and more. The model between each vertical may look a bit different - cards, wallets, or a mix. But by incentivizing customers to pay their suppliers through you in exchange for rewards and analytics, you can enter the flow of funds and successfully drive a closed-payments ecosystem. You solved myriad coordination issues, now you can benefit from software revenue on the procurement and analytics layer and take over payments as well.
https://www.constructiondive.com/news/late-payments-cost-construction-industry-208b-in-2022-report/636224/
This next section is going to be a somewhat generalized overview of what I think is possible but I will probably do a more precise and extensive writeup.