Despite the barely-shared vocabulary, I kept hearing the same language. Lots of talk about the SaaSpocalypse and why it’s overblown. How AI is an accelerant when you own the system of record. How much room embedded payments still have to run. And more. Here’s a recap of what I learned.

What SaaSpocalypse?

The AI discourse has been writing SaaS off for months. Seat compression. Zero-marginal-cost competitors. Vertical was supposed to be especially exposed because it’s “just” workflow software.

The strongest AI work in vertical isn’t being marketed as AI. A vertical ERP that parses every unstructured customer email into the CRM is sold as a better ERP. A field service platform that generates quotes from a voicemail is sold as a faster estimator. The software gets smarter around the customer, and the customer uses more of it, not less. Nobody I talked to was seeing AI drive churn, and many were seeing it drive acceleration.

Trust is the new taste

Horizontal software loves to talk about taste as the differentiator. In vertical, it’s trust. These customers have been sold software for years by vendors who over-promised and under-delivered, and the new wave of agentic point solutions is hitting the same wall of skepticism.

Trust looks different than taste. It’s the vertical-specific brand that tells an HVAC owner you understand HVAC, rather than a generic tech logo that happens to serve field service. It’s showing up at the industry’s trade shows, ride-alongs, and shop floors rather than waiting for customers to come to you. It’s training everyone in your company (especially customer support and sales reps) on the customer’s industry, not just on your product. Taste wins the demo. Trust wins the renewal, the referral, and the second product line.

Embedded payments is huge (and just getting started)

The conventional wisdom on embedded payments has hardened. Most platforms have shipped it, take rates are compressing, and the easy money is behind us. Vertex was a useful corrective on all three. The founders who have been at it longest were the most bullish, not the least. Payments has a lot of room left. Most platforms aren’t close to their ceiling.

Start with take rates. The “compressing to zero” narrative is overstated. Nearly half of companies in Rainforest’s 2026 embedded payments benchmark report take rates above 90 bps. And when a platform grows from less than $50M processing volume to $250M+ volume, the median take rate doubles (0.46-0.60% below, 0.91%-1.05% above). Payments is a game of scale, and the thresholds where the economics inflect are closer than most platforms realize.

Then look at how much room is left even at maturity. Median share of revenue from payments peaks at 3-4 years after launch (35%) and dips slightly at 5+ years (30%). The tempting read is natural maturation. But split the 5+ year cohort into “Scaling” versus “Optimized” and the dip is concentrated in the Scaling group. The Optimized cohort keeps compounding past year five. The long-tail dropoff isn’t gravity. It’s the companies that quietly reallocated attention somewhere else.

The leadership data tells the same story. Companies with a C-suite payments leader post almost 2x the take rates of those with a no-leader. Take rate, attach, and revenue share don’t drift upward on their own. They respond to scale, focus, and ownership. The platforms that keep treating payments as a serious product line will keep finding growth in it long after everyone else has moved on.

The winning AI is less agentic than you think

The AI discourse assumes the endpoint is full automation. The founders selling to contractors, clinics, and shop owners don’t agree. The teams winning here are designing for a spectrum. An AI voice answering service that routes to a human on the first hint of complexity. An agentic AP workflow that auto-posts low-risk vendor bills and kicks medium-risk ones to an accounting clerk. A scheduling tool that drafts the reply and makes the owner hit send.

What makes these products work isn’t how much they automate, but how cleanly they hand off when they shouldn’t. Customers choose their comfort level, and the trust compounds every time the product respects the choice. The calibration is doing the work, not the autonomy itself.

Context graphs are the moat vertical software already built

Every AI product is chasing context, and vertical software has been quietly building vertical-specific context graphs for years. The schema of a restaurant’s menu, modifiers, kitchen stations, and labor model. The workflow of a law firm’s matter, phases, timekeepers, and trust ledger. The relationships on a construction project between job, cost codes, change orders, and retainage.

That structured data is the substrate AI needs to be useful, and vertical software already owns it. AI makes software itself cheaper to build, which pushes the moats toward the hard things AI can’t touch. Proprietary context. Regulatory relationships. Hardware integration. The messy physical world these companies live in.

Embedded grows up

A couple of years ago, the embedded narrative was peak hype. Platforms were integrating embedded providers left and right on the assumption that anything embedded would compound. That first wave underdelivered: integrations underperformed, embedded products were thinner than they looked, and many ended in awkward unwinds.

Platforms got pickier. The bar is higher, vetting is tighter, and second-tier partners are getting displaced. The embedded providers themselves have used those years to grow up. The new generation is more honest about what it does and doesn’t solve, and more valuable to platform customers. Established categories are maturing (e.g., accounting with Tight and Layer, lending with Kanmon, payroll with Check and Salsa), and emerging categories are getting serious heat (e.g., embedded marketing with Reach, embedded voice with Dialstack).

And the surface area is still largely unbuilt. 52% of vertical software companies in the study have no embedded fintech beyond payments at all. The ones that do cluster in capital/lending, payroll, and bill pay. Plenty of runway, just not for anyone showing up with a checklist.

Vertical software has developed its own gravity. The businesses differ wildly on the surface. Restaurants don’t look much like law firms, and neither looks much like a wellness studio or a construction GC. But the playbook is shared, and shared freely. At most conferences, every conversation is competitive. At Vertex, most conversations were comparative. The category is still early enough that the pie is growing faster than the fight for it.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you’re building something interesting in fintech or vertical software, I’d love to chat: mb@matrix.vc

For decades, this was the operating assumption. Humans were the cheapest general-purpose computers available. Hire them, give them tools, let them process information and make decisions.

In the 1970s, an Air Force Colonel named John Boyd formalized what that 150-pound computer does. He called it the OODA loop: Observe, Orient, Decide, Act. A decision cycle built for fighter pilots. Cycle faster than your opponent and you win. It proved far more universal than Boyd intended.1

Every time you hire someone and hand them a set of tools and a set of problems, you’re paying a 150-pound computer to run an OODA loop.

The OODA loop is everywhere. But let’s take insurance underwriting as an example. Submissions land on an underwriter’s desk. She reads the submission, matches it against her carrier’s appetite, decides whether to bind or decline, and issues the quote. Observe, Orient, Decide, Act. Dozens of times a week.

Software ate the edges. AI enters the middle.

Software made parts of that loop faster, particularly Observe and Act. Data warehouses and submission intake tools on the Observe side. Policy admin systems and workflow automation on the Act side. Rating engines and risk scores nibbled at Orient and Decide, but the core of both (judgment, context, the actual call) stayed human. You can only cycle as fast as the slowest step allows.

Now AI enters the middle of the loop. The prevailing assumption is that it completes the job software started: automate the whole cycle, remove the human entirely.

For some roles, that’s right. But for most of the interesting ones, it’s a fundamental misunderstanding of what the human was actually doing in Orient and Decide.

Orient and Decide are bundles, not functions

The underwriter wasn’t performing one function. Orient and Decide are each bundles of distinct sub-functions, packaged into a single role because they came free with every hire. We never had to decompose the bundle because there was no reason to. Now there is.

AI absorbs some of these functions today, will absorb others as it matures, and will probably never absorb the rest. Automate the wrong ones and you’ve built a system nobody trusts. Leave the wrong ones to humans and you’re paying for work a model should handle. Here are some of the critical parts of those bundles:

Orient: building the picture

The pattern matcher. Recognizing what kind of thing you’re looking at by matching against known categories. Enough examples exist that AI classifies faster and more consistently than any human. In underwriting, this can mean reading a submission and recognizing it as a standard mid-market GL risk the carrier has seen ten thousand times. Once matched, guidelines prescribe the response. This is the first function AI absorbs end to end.

The context adapter. Every organization accumulates unwritten rules and institutional knowledge that never make it into any system. This function translates that tacit knowledge into judgment on a specific case. In underwriting: knowing that a contractor class is fine in Texas but toxic in Florida, or that this agency’s “preferred” submissions mean the agent’s brother-in-law. LLMs with access to historical data already do this better than any individual. They don’t forget, and they don’t walk out the door with ten years of institutional knowledge.

The loop connector. Bridging decision loops the org chart never connected, i.e., someone in one process notices a signal that matters to a different process. The underwriter who flags a claims trend to the actuarial team. The valuable part isn’t the communication, but noticing it was relevant to someone else’s problem. AI today runs one loop well. Connecting loops means recognizing what matters outside your own process. This is still largely unsolved and enormously valuable.

Decide: committing to action

The circuit breaker. Human slowness was a feature. The underwriter who sleeps on a borderline case isn’t necessarily being slow, but running a second, slower loop. AI doesn’t have that instinct. The hard problem isn’t implementing confidence thresholds. It’s knowing which decisions need the overnight hold and which don’t. Fraud detection should run at machine speed, while underwriting authority on a novel risk class probably shouldn’t. Choosing the right clock speed is itself a judgment call about the nature of the decision.

The exception decider. The case that doesn’t fit the guidelines: not deciding within the rules but whether to change them. In underwriting: two carriers with identical models and data diverge entirely based on how they handle exceptions, because that’s where underwriting philosophy lives. AI optimizes for the objective you give it. It doesn’t question the objective.

The decision owner. Someone’s name is on the file, not just for blame, but for iteration: the person who feels feedback from outcomes and adjusts. Regulators require a human in the chain, reinsurers demand it, etc. This isn’t a cognitive limitation. It’s a structural requirement that changes at the speed of law, not tech.

These aren’t the only functions in the bundle, but they illustrate the gradient. AI is already better at the first two. It will likely absorb the third and fourth as agentic systems mature. The last two are probably irreducible. Not because AI can’t get smart enough, but because exception-deciding is an act of authority, and decision-ownership is a social and legal prerequisite for the transaction to exist.

The same decomposition applies wherever humans orient and decide at scale. In contract law, AI agents already draft standard redlines and learn each client’s preferences, but “commercially reasonable” and “reasonable” look identical to a model and mean entirely different things in court. The lawyer decides whether to push back, and the lawyer’s name is on the opinion.

In procurement, an autopilot benchmarks supplier pricing and handles standard reorders. But staying with a vendor at 20% above market because they alone can deliver by your launch date? That’s exception-deciding. And when that vendor misses a delivery, the relationship that resolves it is human. The labels change but the decomposition doesn’t.

Where value accrues

If your product’s primary value is executing routine decisions, you’re competing with every AI wrapper that can ingest inputs and produce outputs. The moat moves in two directions.

1. Down to the data layer: the system that has seen ten years of submissions, outcomes, and exception decisions has a better-oriented model than any new entrant. That advantage compounds with every cycle.

2. Up to the exception-handling layer: the product that makes the exception decider and the decision owner more effective (better context, tighter feedback loops, smarter routing) owns the part of the workflow that can’t be commoditized.

The exception-to-routine flywheel

AI surfaces a genuinely novel case. A human makes a judgment call. That judgment gets fed back into the system so next time it’s routine, not exceptional. The exception pool shrinks, the system compounds, and a competitor starting fresh has to build that history one judgment call at a time.

But the exception pool doesn’t shrink to zero. The frontier moves. Automate today’s exceptions and you can take on risk classes you couldn’t touch before. That generates new exceptions at a higher level of complexity. The human doesn’t become unnecessary. The human operates on increasingly valuable problems.

Building for the human functions

In practice this means surfacing exceptions with full context, not just “this case is unusual” but why it’s unusual, what similar cases looked like, and what happened when someone decided differently. Tightening the decision owner’s feedback loop means connecting outcomes back to the specific decisions that produced them, in real time, not in a quarterly report. The trick is engineering productive friction: confidence scores, mandatory holds on high-stakes decisions, escalation paths that route the right cases to the right humans.

Products that dump 500 AI-flagged items on a human are treating the human as a pattern matcher, a function AI should handle. Products that surface five genuine exceptions with full context are routing work to the exception decider and the decision owner, the functions where humans are irreplaceable. That’s the design problem worth solving and where the real value will accrue.

The unbundling

The 150-pound computer isn’t being replaced. It’s being unbundled. Every company that employs humans to orient and decide is now answering the same question, whether it knows it or not: which functions in the bundle are you absorbing, which are you augmenting, and which are you designing around as permanently human?

Get that decomposition wrong and you’ve built a fast system nobody trusts, or an expensive human doing work a model should handle. Get it right and you’ve found something better than automation: a system that converts today’s exceptions into tomorrow’s routine, freeing the 150-pound computer to work on problems it couldn’t reach before.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you’re building something interesting in fintech or vertical software, I’d love to chat: mb@matrix.vc

The “fin” implied lots of emails from .gov domains, months-long audits, compliance officers who know your SAR filing history better than your product roadtmap, and mid-week flights to Charlotte or DC. The “tech” is a slick mobile app, a 10x user experience, and investor coffees at Blue Bottle.

“Fin” and “tech” were always a spectrum, but the market generally rewarded fintechs for being as much “tech” as possible and as little “fin” as they could get away with.

And that’s understandable. In 2021, software had a gross profit pool of roughly $0.7 trillion, valued at a steep premium. Financial services had a gross profit pool an order of magnitude larger, valued far more conservatively.1 Fintech let you arbitrage both: financial services economics with a software multiple.

That gap in profit pools also tells you where the real money is. Financial services generates more gross profit than any other sector globally. The “fin” side of fintech isn’t just more defensible. It’s a far larger market.

Then AI arrived and the arbitrage broke. Software valuations compressed as investors re-priced what code was worth in a world where code is getting cheaper. Fintechs got caught in the downdraft because the market had categorized them as software companies.

But the market has the category wrong. Fintech’s costs, and its moats, were never in the code, and look increasingly antifragile to AI disruption.

A tale of two cost structures

Software had one of the best business models in history: code was expensive to produce, but once written, it could be distributed for almost nothing. The gap between “expensive to build” and “free to distribute” was the margin. If you’re a SaaS company spending 22-25% of revenue on R&D, that spend is also your barrier to entry. Competitors couldn’t easily replicate what took years and tens of millions to build.

AI closes that gap from the top. If code is cheap to build and cheap to distribute, the margin compresses. The wall that kept competitors out gets shorter, more players get in, and pricing power erodes.

That’s a real problem if your business is software. But fintech’s expenses aren’t engineering expenses. Follow the money and the distinction gets obvious fast.

PayPal spends 9% of revenue on R&D. Block spends 12%. That’s not because fintech engineering doesn’t matter. Stripe’s engineering is world-class and a real competitive advantage. It’s that engineering isn’t where the majority of the money goes.

It goes to the fin. And unlike R&D spend, these costs don’t just produce a product, they produce moats:

Credit losses buy underwriting data.

Affirm spends 35% of revenue on credit losses and cost of capital, before a single engineer is paid. Every dollar lost to defaults is a dollar of repayment data a competitor doesn’t have. A new entrant training on synthetic data has no ground truth. You can’t build reliable loss history on synthetic data alone.

Compliance spend buys regulatory permission.

Wise dedicates a third of its workforce to compliance and financial crime prevention across 65+ regulatory licences. Money transmission licenses across 50 states. BSA/AML programs. Bank charter requirements. These aren’t advantages you build. They’re permissions you earn, continuously. You can’t vibe-code a banking license.

Transaction volume buys proprietary data.

Toast’s payments segment runs at 22% gross margins versus 70% for its SaaS segment, yet generates nearly twice the gross profit. Those costs buy merchant-level transaction data that feeds Toast Capital, which has originated over $1 billion in loans. Adyen’s risk models are trained on transaction patterns across 30+ markets.

Fintech’s margins were never high in the first place, and that’s the point

A payments company runs at 20-50% gross margins, not 80%. But lower margins aren’t the same as weaker businesses. Fintech margins are lower because many of those costs generate compounding advantages. And even the ones that don’t still exist outside the blast radius of AI-driven cost compression.

And AI makes every one of these moats stronger. Better models tighten loss rates. Better fraud detection reduces chargebacks. Better compliance tooling lets smaller teams hold more licenses. AI doesn’t replace the moat. It rewards the companies that chose to build in the hard parts of fintech: money movement, risk, proprietary data, and regulation.

So the real argument is not just “AI helps fintech.” It’s that AI shifts value away from product surface area and toward proprietary data, risk-bearing capacity, regulatory permission, and distribution embedded in real money movement. If you’re building in those areas, AI is compounding in your favor. If your differentiation is in the code, it’s compounding against you.

And the demand side keeps growing. Every vibe-coded checkout is a new fraud vector. Every AI agent transacting autonomously is a chargeback risk. The more that gets built on top of fintech’s rails, the more essential the rails become.

Fin for the win

This realization is already forcing smart fintech founders to re-think where they sit along the “fin” and “tech” spectrum:

• Do we underwrite and price risk ourselves, or pass it to a partner who keeps the margin?

• Do we own the regulatory relationship, or rent it from someone who does?

• Does every transaction make our risk models sharper, or are we training someone else’s?

• Is our ledger the source of truth, or an imperfect mirror of someone else’s?

This distinction cuts the fintech landscape in two. The companies that own the regulatory relationship, eat the credit losses, and accumulate the transaction data are building moats that AI deepens. The ones that rent the fin, wrapping a partner bank’s license, a BaaS provider’s ledger, someone else’s risk models in a better UI, have exactly the same problem as SaaS companies. Their differentiation is in the code, and the code just got cheaper.

The old arbitrage of financial services economics with a software multiple is dead. The new one is simpler: own the fin.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you’re building something interesting in fintech or vertical software, I’d love to chat: mb@matrix.vc

What’s a context graph & why does it matter for agents?

A context graph is a queryable record of business logic: the reasoning, precedents, and decision traces that explain why things happened, not just what happened. Every company has one in theory. It’s the accumulated knowledge of how the business operates: the exceptions that get approved, the precedents that govern decisions, the tribal knowledge in people’s heads.

Agents need this to move from automation to autonomy. An agent can run a workflow, but it can’t handle exceptions or apply precedent without access to the reasoning behind past decisions. The context graph separates an agent that follows rules from one that exercises judgment.

In most companies and products, the context graph exists in theory but not in practice. It’s scattered, implicit, and inaccessible because:

• No one logs the reasoning behind decisions. The VP approved the exception on a Zoom call but never recorded why.

• Systems capture outcomes, not context. The CRM shows the final discount, not the service outages or churn threat behind it.

• What context exists is siloed. It’s scattered across tools that don’t share a worldview.

These aren’t product bugs. They’re structural features of horizontal SaaS. Generic platforms use flexible abstractions that can model any business, which means they model no business precisely. Humans must bridge the gap between “what the system captures” and “how decisions get made.” But humans don’t leave audit trails.

The trillion-dollar question: who fixes this? The prevailing thesis is that agent startups have a structural advantage. They sit in the execution path at decision time, so they can capture context that systems of record never see. The assumption is that the context graph needs to be built from scratch. But that’s not entirely true.

Vertical software has been quietly building context graphs for decades

The debate has a blind spot: it focuses entirely on horizontal enterprise software.

Think about the workflows and software stack of a typical company. It’s a patchwork of horizontal tools, each built for a broad use case, and none designed to really work together. Sure they have APIs and integrations, but even the best integrations drop tons of context as data and actions move through them. The context graph fragments because the tools don’t share a worldview.

But vertical software is different. The difference starts with something I’ve written about before: the data model.

Horizontal platforms like Salesforce use generic abstractions (”accounts,” “contacts,” “opportunities”) that can model almost any business. That flexibility helps breadth but hurts depth. The ontology doesn’t map to how any particular industry works. It’s a blank canvas customers must configure into meaning.

Vertical software starts from the opposite premise. The data model isn’t flexible. It’s opinionated, purpose-built, and mapped to that industry’s reality.

Look at Toast’s data model. You’ll see objects like Order, MenuItem, Customer, PrepStation, etc. These aren’t generic transactions dressed up with custom fields. They’re first-class entities with built-in relationships: orders connect to customers, menu items, locations, and payments as native concepts. The ontology is the domain.

Compare that to Salesforce’s data model: Account, Opportunity, Lead, Contact, etc. Powerful abstractions, but they describe a law firm, restaurant, or rocket manufacturer equally well. They describe none of them well. Configuration, integrations, and human memory must bridge the gap.

Opinionated data models bootstrap context graphs

In vertical software:

The reasoning gets recorded because the system is built around actual business decisions. When a construction platform tracks change orders, it captures why the change happened (weather delay, subcontractor default, scope change) as structured data, not notes in a generic “activity” field.

The context isn’t siloed because vertical platforms consolidate functions into one system. The construction platform isn’t just project management; it’s also scheduling, procurement, billing, and field operations. One system, one data model, one view of reality.

The full decision trace is reconstructible because the ontology supports it. When everything from estimate to invoice lives in a system built around menu items or job sites or patient treatments, you can trace how a price changed, why a timeline slipped, or what drove a discount.

Inferential density: a different way to capture “why”

There’s a deeper point about how context graphs work. The original context graph thesis assumes decision traces need explicit capture: an agent logs “I did X because of Y” at the moment of decision. But there’s another way the “why” becomes accessible: through inferential density. When the graph is sufficiently rich, the reasoning can be reconstructed from relationships between nodes.

Consider an order in Toast. Alone, it’s just a transaction with attributes. Connect it to inventory and you know which items are selling faster than expected and what needs restocking. Connect it to customer data and you know who your most valuable customers are, what they order, and when. Connect it to payments and you know revenue by payment method and which orders are outstanding.

Now when you see a spike in refunds, you don’t need someone to log what went wrong. You can see that the spike correlates with a specific menu item, the inventory system shows that ingredient was substituted due to a stockout, and the affected customers skew toward your highest-value segment. The reasoning is embedded in the relationships.

Each new function adds inferential power to everything already in the graph. Inventory data makes orders more meaningful. Customer data makes inventory decisions more meaningful. Payment data makes customer relationships more meaningful. The context graph doesn’t just get wider; it gets denser. Density makes the “why” reconstructible without explicit capture.

This is the structural advantage vertical platforms carry into the age of agents.

How vertical software is extending the context graph at the edges

Vertical software companies didn’t build these context graphs by accident. They were forced to go deep because they couldn’t go broad. A construction platform or dental practice system faces a ceiling: there are only so many construction companies, only so many dental practices. If you can’t grow by adding customers across industries, you grow by capturing more value from each customer within your industry.

Embedded payments was the proof point. When a vertical platform embeds payments, such as with Rainforest, it isn’t just adding a monetization layer. It’s extending the context graph into new categories. The platform knows not just what transactions happened, but the full economic reality: payment velocity, cash flow patterns, default rates. Every transaction adds to the accumulated knowledge.

The same logic now drives the next wave. Vertical platforms have spent a decade consolidating the operational core. But activity at the edges (customer acquisition, purchasing, workforce management) still happens outside the platform. Marketing in Mailchimp. Procurement in email threads. Accounting in QuickBooks. Each represents a gap in the graph.

Why vertical platforms can now absorb more edge functions

The foundation exists. Vertical platforms have domain-specific ontologies, core operational modules, and deep customer relationships. They understand what a job site is, what a patient treatment plan looks like, what a menu item costs. This is the precise business logic edge functions need to plug into.

The financial layer is in place. Embedded payments gave vertical platforms visibility into the money moving through their customers’ businesses. That financial context is essential for procurement and accounting, which live at the intersection of operations and money.

AI changes the economics. Marketing, procurement, and bookkeeping require labor. They’re judgment-intensive and context-dependent. AI can now handle workflows that previously required humans. The vertical platform, with its deep context graph, is the ideal substrate.

A few categories we’re tracking here:

• Marketing pulls customer acquisition into the graph. Reach routes customer communications and other marketing data through the vertical platform itself, connecting acquisition cost to the customers it produced.

• Accounting pulls financial categorization into the graph. With Layer or Tight, transactions get categorized within the platform rather than exported to QuickBooks, closing the loop between operations and the books.

• Procurement pulls purchasing into the graph. Companies like Sticker and Faliam bring supplier relationships out of email threads and into the system of record, making spend visible alongside operations.

Each follows the same pattern: absorb an adjacent function, blend context with financial data, deploy AI, and deepen the graph.

So what?

Horizontal SaaS will lose ground. These companies have brand equity, data gravity, and deep workflow integration. But they’ll lose share to agent-first startups smart about bootstrapping context graphs, and to vertical incumbents picking off customers tired of stitching together horizontal solutions.

Agent-first startups face a cold start problem. The context graph thesis is right that agents can capture decision traces. But vertical software already owns the workflow for millions of businesses. An agent startup building for restaurants competes with Toast’s distribution, data, and decade of accumulated context. A hard gap to close.

Vertical software incumbents are undervalued. The market prices vertical software on revenue and growth. It doesn’t price the context graph. As horizontal SaaS struggles and agent startups face distribution challenges, vertical platforms with dense context graphs have a structural advantage the market undervalues.

Embedded service providers are an emerging category worth watching. Not every vertical platform will build the graph extensions in house. Embedded solutions will be more attractive. marketing, procurement, and accounting in-house. Their growth is complementary to vertical software’s expansion. As vertical platforms absorb more functions, the infrastructure providers that enable it become more valuable.

The trillion-dollar context graph opportunity is real. But it won’t be captured by whoever builds the best agent. It will be captured by whoever already has the deepest graph and knows how to extend it.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you’re building something interesting in fintech or vertical software, I’d love to chat: mb@matrix.vc

Every financial transaction involves risk: uncertain exposure that someone must bear. A loan might not be repaid. A payment might be fraudulent. A counterparty might fail. Someone is always holding this exposure.

Risk is balanced by cost. Interest rates on loans. Interchange fees on payments. Spread on foreign exchange. You take the risk, you get paid for it.

Risk is also balanced by friction. The three-day settlement window. The paper application. The in-branch visit. These delays make risk more manageable. Friction is another form of cost (implicit rather than explicit, paid in time and conversion rather than dollars).

Fintechs reduce both cost and friction. Lower fees. Faster approvals. Seamless onboarding. The pitch is simple: same product, better experience.

But reducing cost and friction doesn’t reduce risk. That’s the thermodynamics at work. The risk remains, conserved in the system. The friction you removed was managing something. Where does that exposure land?

Risk takes many forms, including:

Each requires different capabilities to manage. Being good at credit risk doesn’t make you good at fraud risk. Operational excellence doesn’t help with concentration.

This creates an opportunity. A process change, a new data source, or a different product structure can shift risk from one form to another. A company with a specific edge in data, technology, or operational discipline can deliberately transform risk into a form they’re better equipped to manage. The goal isn’t to avoid risk. It’s to hold the right risk.

The difference between success and failure is whether this transformation is intentional. Reducing cost and friction without understanding the new risk you’re holding is how fintechs blow up. The ones who win recognize the transformation and build specific capabilities to handle it.

In each of these examples, notice the trade: what friction came out, what risk moved in, and what capability the winner built.

Square (underwriting risk → fraud and chargeback risk)

Traditional payment processors manage risk through friction: site visits, reserve accounts, manual underwriting. The merchant is vetted before they ever process a transaction. Square removed that friction, letting anyone accept payments instantly. But the risk didn’t disappear; it transformed. They won because they built real-time detection systems designed for fraud and chargebacks. They deliberately traded a risk managed through slow process for a risk they could manage through technology.

Toast (credit risk → operational and concentration risk)

Traditional lenders manage credit risk through friction and cost: lengthy applications, document collection, credit checks, high interest rates. Toast removes that friction for restaurants on their platform. A restaurant can get capital with minimal paperwork, underwritten on real-time transaction data flowing through its point-of-sale system. Concentration risk cuts both ways: their entire loan book is restaurants, so when COVID hit, the whole portfolio was correlated. But focusing on a single sector means deeper knowledge, purpose-built software, and better underwriting for that specific business. They win when depth of insight outweighs concentration exposure.

Buy now, pay later (consumer credit cost → provider credit risk)

Traditional card payments balance risk through cost: merchants pay interchange, consumers pay high APRs if they revolve. BNPL changes the equation. Merchants pay a higher fee (4-8% vs 1.5-3%) but shed chargeback exposure and gain conversion lift. Consumers get interest-free financing. The BNPL provider absorbs credit risk that was previously managed with high APRs. Companies like Affirm and Klarna are betting they can manage this through short durations, transaction-level underwriting, and merchant-funded economics. They win when underwriting keeps losses below the merchant fee. They lose when credit losses spike and the math stops working.

If you’re building a fintech that reduces cost or friction, ask yourself: what risk are you now holding? The friction you removed was managing something. Do you have data, technology, or expertise that makes you better at managing the new form? Or are you just hoping it doesn’t materialize?

Risk can’t be destroyed. But it can be transformed, and the best fintechs turn that transformation into their advantage.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you’re building something interesting in fintech or vertical software, I’d love to chat: mb@matrix.vc

“Data model” refers to what a startup emphasizes in its product, i.e., which parts of reality matter most in how the product represents the world. It’s the core concepts or objects a startup prioritizes and builds around, the load-bearing assumptions at the heart of their strategy and worldview. It’s partially captured in the database architecture (hence the name), but it shapes everything from the UI/UX to the product marketing, pricing model, and GTM strategy.

This shows up differently depending on the layer. In the database, it’s which tables are central and how they relate. In the product, it’s which UI elements dominate and what actions are easiest. In pricing, it’s what you charge by. In GTM, it’s the workflow or pain point you lead with. But they all stem from the same choice about what deserves to be the center of gravity.

Every founder has a data model, whether they realize it or not. Either you choose it explicitly or it gets inherited from whatever you’re copying. Most founders never articulate it. By the time the architecture solidifies around these implicit choices, it’s nearly impossible to change.

And that’s generally fine, because most companies shouldn’t innovate on their data model. Customers have existing mental models and workflows built around incumbent tools. Fighting that is expensive and slow. But at the extreme ends of markets—where you’re toppling multi-billion-dollar incumbents or creating entirely new categories—a distinctive data model becomes a critical and non-obvious edge.

The biggest breakout companies of the last decade often trace their success to an early, non-obvious data model choice that seemed minor at the time but proved decisive. Consider:

Slack’s persistent channels vs 1:1/group messages: While Yammer and HipChat replicated email’s ephemeral group messages, Slack made persistent, searchable channels the atomic unit. This created organizational memory—every decision, discussion, and document lives forever in context. Incumbents couldn’t match this without rebuilding from scratch.

Toast’s menu-item-centric architecture vs generic POS SKUs: Toast makes menu items first-class objects with embedded restaurant logic—prep times, kitchen routing, and modifier hierarchies built in. Generic point-of-sale systems treat menu items as retail SKUs, requiring third-party integrations for kitchen workflows. Toast’s model enables native order routing and real-time kitchen management, plus natural extensions like ingredient-level inventory and prep-based labor scheduling—creating a locked-in ecosystem that becomes the restaurant’s operational backbone.

Notion’s blocks vs Google’s documents: Google Docs gives you documents; Notion gives you Lego blocks. Every piece of content can be rearranged, nested, or transformed into databases, kanban boards, or wikis. This modularity collapses entire tool categories into one system. Traditional tools can’t compete without abandoning their document-centric architecture.

Figma’s canvas vs files: Photoshop and Sketch are built on local files. Figma is built on a shared web canvas where everyone sees changes instantly. This eliminates version conflicts and “final_final_v2” chaos. Adobe couldn’t respond without deprecating their entire desktop-first ecosystem.

Rippling’s employee data model vs siloed tools: Rippling treats the employee record as the lynchpin connecting HR, IT, payroll, and finance. Not separate products sharing data, but one product with multiple views. Each new product module is automatically more powerful than standalone alternatives because it inherits full employee context. Competitors remain trapped in single categories or attempt inferior integrations.

Klaviyo’s order-centric data model vs email-centric tools: MailChimp optimizes for email campaigns. Klaviyo optimizes for customer lifetime value by making order data a first-class citizen alongside emails. This lets e-commerce brands segment by purchase behavior, not just email engagement. Generic email tools can’t match this without rebuilding for vertical-specific data.

ServiceNow’s connected services vs standalone tickets: Traditional help desks treat tickets like isolated emails. ServiceNow links every ticket to a service map—showing which system is down, who owns it, and what it affects downstream. This transforms IT from ticket-closing to problem-preventing, making ServiceNow irreplaceable once companies reorganize operations around this model.

Data models matter more than ever now

The importance of a differentiated data model is rising dramatically. AI is commoditizing code. Technical execution is table stakes rather than a competitive advantage. AI can generate code, but it can’t refactor the organizational reality customers have built around your architecture—the workflows, integrations, and institutional muscle memory that compound over time.

Meanwhile, many markets have become so crowded that single-product companies can’t survive. This is particularly true in vertical markets, where companies are expanding into adjacent software products, embedding payments and other financial products, and even competing with their customers’ labor and supply chains with AI and managed marketplaces.

This all points to the same conclusion: when code is cheap, competition is fierce, and vertical depth matters, your data model is the foundation of your moat. The companies that win won’t be those with the most or even the best features. AI will democratize those. The winners will be built on a data model that captures something true about their market, which in turn creates compounding advantages competitors can’t replicate.

Consider how this plays out. Rippling’s employee-centric model made it trivial to add payments, benefits, and spend management. Each new product inherits rich context, making it instantly more powerful than standalone alternatives. Toast’s menu-item architecture naturally extended to inventory, labor, and supplier management. The data model wasn’t just their first product decision. It was their platform destiny.

Designing the right data model

The path to a differentiated data model depends on your market. The more horizontal you go, the more your moat comes from technical and interface innovation. The more vertical you go, the more your moat comes from elevating the right domain objects with the right attributes.

Horizontal tools serve broad use cases where underlying concepts are already familiar. Leverage comes from changing how the product is built or experienced. Notion reimagined documents as composable blocks. Figma rebuilt the foundation entirely as a multiplayer web canvas.

Vertical tools serve specific industries with deep domain complexity. Leverage comes from what you choose to emphasize. Toast elevated menu items—not transactions—with prep times and kitchen routing as first-class data. Klaviyo promoted order data to equal status alongside email metrics.

A good place to start is by looking for model mismatches in existing successful products. Where are incumbent products forcing an incorrect or outdated model on their customers? Where are customers using workarounds—spreadsheets, low/no code tools, extensive in-product configuration—to make the product match how they think and work?

Despite all the emphasis on data models, start with the workflow, not the technical implementation. Don’t ask “what data do we need to store?” Ask “what’s the atomic unit of work in this domain?” For restaurants it’s the menu item. For design it’s the canvas. For employee operations it’s the human.

If you’ve already built a product, you can audit how powerful and correct your data model is. Open your database schema and see which table has the most foreign keys pointing to it. Is that the atomic unit your customers actually think in? List your product’s core actions. Do they all strengthen one central object, or are you building a feature buffet? What would break if you deleted your second-most important table? If the answer is “not much,” you probably have the wrong data model.

Test whether your data model creates compound advantages. When you add a new feature or product, does it automatically become more powerful because of data you’re already capturing? If your answer is “we’d need to build that feature from scratch with no inherited context,” you don’t have a compounding data model—you have a product suite. The right model creates natural expansion paths that feel obvious in retrospect but were invisible to competitors.

Conclusion

Your data model is your destiny. The paradox is that this choice happens when you know the least about your market, but that’s also why it’s so powerful when you get it right. Competitors who’ve already built on different foundations can’t simply copy your insight. They’d have to start over, and by then, you’ve compounded your advantage.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you’re building something interesting in fintech or vertical software, I’d love to chat: mb@matrix.vc

Airlines represent an increasingly common pattern: X is just a [bank/lender/issuer] that sells [unrelated, non-financial product].

Examples include auto and equipment manufacturers like Toyota and John Deere, which have extensive financing arms, homebuilders like D.R. Horton, which offer vertically integrated mortgage origination, and wireless carriers like AT&T, which earn hefty fees from device insurance and financing.

Why embedded fintech wins

Modern software platforms have transformed this pattern into a powerful strategy that’s upending financial services and software alike. Restaurant owners no longer go to Wells Fargo for their card payments, they go to Toast. Landlords no longer wait in line at Chase to deposit checks or get loans, they use Yardi, etc.

These platforms—from the multi-billion-dollar pioneers like Toast, Shopify, and ServiceTitan to the crop of upcoming challengers—all represent the new strategy of embedded fintech, or when a non-financial company offers financial products that are highly contextual, curated, and customized for the company’s existing customers.

To appreciate the power of embedded fintech, consider the contrast between customers in line at the airport and those at the bank. Airline passengers may be very different from each other—different ages, different income levels, different reasons for traveling, different travel frequencies, and so on. But they all have one thing in common: a need to fly. Meeting that need is the airline’s main job, and they spend aggressively to fill seats on their planes. But airlines are notoriously low-margin businesses, and now that they have a captive audience, they see a cross-sales opportunity too good to miss. Airline credit card and loyalty schemes are designed to cross-sell relevant, complementary products to this captive audience.

Contrast the airport line with the line at your local bank. The people here are more diverse than at the airport, as are the services they’re waiting for. You may be next to a restaurateur setting up card payments, a construction company owner applying for a loan, new parents opening a 529 account, and a local lawyer opening a checking account. To appreciate the diversity, just look at the online product offering from Chase: everything from checking accounts to Disney Visa Cards and private banking to home mortgages and cross-border payments.

Both airlines and financial services are highly competitive industries. Both spend aggressively to acquire new customers, and both try to sell new customers as many products as possible to cover their acquisition costs and increase retention. The difference is that bank customers are so diverse that it’s impossible to customize an experience for them. Airline customers, by contrast, have just enough in common that it’s possible for airlines to customize experiences for them. That ability to customize is what gives embedded fintech its power.

How embedded fintech works

Platforms with embedded financial services (PEFS) have been at the forefront of refining embedded fintech. PEFS like Shopify ($190B market cap), Toast ($25B), and ServiceTitan ($10B) are nominally software companies that serve well-defined customer segments or needs: Shopify is the one-stop shop for ecommerce merchants, Toast for restaurateurs, ServiceTitan for field service businesses, etc.2

But all earn 25% to 50%+ of revenue from financial services—everything from payments and lending, to payroll, spend management, and more. The revenue share is even higher for newer PEFS that are more deliberate about their financial product strategy. Let’s discuss some of the ways they’ve refined their product strategies.

PEFS target well-defined customer segments or needs, rather than serving a wide range of customers. They don’t try to be everything to everyone; they instead try to be everything to one type of customer. Contrast the generic, impersonal experience a lawyer, restaurateur, and plumber will get from a Chase branch with the highly customized, trusted experience they will get from a Clio, Toast, and ServiceTitan, respectively.

Targeting a specific audience enables PEFS to solve—and monetize—multiple problems for that one audience. Call this focus on being everything to one type of customer a maximalist product approach. The maximalist approach is best described by Parker Conrad's Compound Startup strategy, which leverages a single platform and shared infrastructure to launch a compelling bundle of products quickly to increase LTV and retention.

The maximalist approach and the compound strategy both extend to financial products, which PEFS treat as strategic priorities rather than afterthoughts. The compound strategy naturally complements many B2B workflows (see “B2B payments aren’t payments, they’re workflows”). Financial products have the added benefit of transactional business models rather than SaaS, which lowers the platform’s nominal usage cost for customers.

These financial products are deeply integrated from the start, so they create a unique flywheel that increases adoption and reduces risk. Beyond the benefits of zero CAC and high cross-sell rates, risk is an underappreciated benefit of embedded fintech. Most financial products require some risk assessment and underwriting. This is much easier when underwriting a specific type of user and business, and when you have a broader, longitudinal view of their activity via software.3

The critical role of embedded fintech vendors

PEFS play a critical role in acquiring users and customizing both financial and non-financial products for their specific customers. But financial products come with onerous regulatory, compliance, risk, and capital requirements. Those requirements are why PEFS rely on a rising number of embedded fintech vendors (EFV) to embed and monetize financial products. Examples include Rainforest for payments and Unit for banking.

EFVs serve as a critical abstraction layer between software platforms and financial infrastructure providers like sponsor banks, card issuers, and lenders. Those providers don’t have the technical chops or embedded expertise to support fast-moving software platforms, and the individual platforms are unlikely to have the scale or expertise to work directly with a financial infra provider.4

EFVs meet the challenge of making financial infrastructure easy to embed, customize, and use across diverse platforms and use cases. Their success depends on mastering both the financial primitives they're built on and the unique requirements of each vertical market they serve. Most importantly, they need to deliver an exceptional experience both for the developers who integrate their solutions and for the end users who interact with them.

EFVs have made the wide array of financial products and services that banks offer embeddable within software platforms. Major categories like payments and lending have existed for a while, with companies like Stripe and Fundbox, but modern challengers like Rainforest, Unit, and Pipe have extended and accelerated adoption. Now nearly every product category has an embedded option:

Although EFV is a broad and fast-moving model, there are a few noticeable trends. EFVs are supporting a broader sliding scale of integration options, from fully built-out white-label components to raw APIs and platform ownership of critical functions like risk and underwriting.

Many PEFS are launching multiple embedded products and want the ability to pick and choose the best vendors for different functions like payments and lending. This development is leading EFVs to be more composable and interoperable—witness the integration of Rainforest with Unit. Many scaled EFVs are themselves going multi-product in an attempt to capture multiple financial use cases.

Finally, many EFVs are taking a cue from the platforms they serve and providing tools that complement their financial primitives. Think, for instance, of a card issuer providing embedded spend-management tools. Embedded tools like these offer higher margins and increase adoption.

Embedded fintech is so powerful because it changes the way consumers and businesses access financial services. It reflects the broader trend of offering more convenient, customized, and contextually relevant products and experiences enabled by software and the internet. Giants like Stripe and Toast have shown the power of embedded fintech. But we're only at the end of the beginning. New waves of natively embedded companies, particularly in vertical software, are building even larger and more ambitious companies with the model.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: mb@matrix.vc

Imagine you’re the world’s most entrepreneurial dentist, the Mark Zuckerberg of molars. You’re great at cleaning teeth, but you’re also great at running a practice. You have your own playbook for the dental business.

Thanks to your playbook, your practice is larger and more profitable than the market average. You’ve surveyed your dentist friends. You’ve learned that you’re the best at acquiring patients, running your back office, configuring your CRM to minimize cancellations, and getting paid quickly. But you aren’t satisfied with cleaning teeth all day. You want to build a dental empire. The gap between the average business and what’s possible with your playbook is your opportunity.

Software engineering vs. financial engineering

How do you start your empire? Until recently, there were two broad and distinct paths: private equity (PE) and venture capital (VC).

In the PE model, you’d raise money to acquire a controlling stake in one or more practices. Then you would have full control to implement your playbook and manage those practices day-to-day.

In the VC model for B2B software, you’d raise money to start a company that builds software that codifies your playbook for any practice to implement. Maybe it’s a suite of CRM, scheduling, and billing tools, with opinionated workflows and design choices specifically for dental practices. You wouldn’t own or manage any practices directly, but your software would help them run better.

Both models start with the same principles: (1) the average company in a given vertical isn’t run as effectively as it could be, and (2) you have the insights and playbooks to run the average company more effectively. You believe you can close the gap between the blue and green dots, and get paid handsomely for it:

However, the PE and VC models take very different approaches to point #2. The tradeoffs of each model are most obvious in their approaches to control, concentration, and value capture.

The PE model is high control, high concentration, and high value capture. It says, “This specific business can be run better, and so it’s likely undervalued. I’m going to buy and run it, applying my playbook. As the business grows and becomes more efficient, it will become more valuable. I’ll benefit from the increased equity value.”

The VC model (at least within B2B software) is low control, low concentration, low value capture relative to an individual business. It says “There are lots of businesses in this market, and most of them could be run better. I’m going to build software that helps them do that. I’ll charge a small fee, but will sell it to many businesses.”

The PE and VC models are extreme ends of a spectrum, rather than distinct models. PE and VC firms are both in the business of generating returns for their investors. They take capital, combine it with their belief in the superiority of their playbook, and then implement their strategies and playbooks in a given vertical. This may involve buying businesses or building tools to enhance their performance, generating profits, and returning the profits to their investors.

Until recently, you’d be forgiven for thinking PE and VC are effectively distinct entities. However, headlines like these are making it more apparent that they’re just a spectrum of strategies and that there’s a lot of white space in between them:

Why are VCs (and the companies they fund) adopting PE-like strategies? Let’s explore.

Pushing toward and pulling from the messy middle

In seeking outsized returns, VCs and venture-funded startups are venturing beyond their previously narrowly defined model. They’re getting more creative and aggressive in exploring the messy middle, the whitespace between the previously distinct PE and VC ends of the spectrum.

Several factors are behind this move towards the messy middle. Some are pushes from the traditional VC model: the classic, almost boutique approach of minority investments in asset-light, high-growth, all-or-nothing, power-law-seeking, software-first-and-only startups. As this model gets more competitive, smart founders and investors realize they must try something different. At the same time, several powerful factors are pulling toward these new models: new technologies and business models seem to enable venture-like returns from traditionally non-venture-type businesses.

The push side is well-documented: the traditional VC asset class has become saturated, especially in B2B SaaS. Nearly a trillion dollars have flowed into the venture industry in the last decade. This has led to a proliferation of companies serving every vertical and every niche. Some market maps are so crowded that you need a microscope to make out a single logo:

At the same time, AI promises to further reduce the cost of software development. That isn’t to say that the B2B SaaS market is going to zero, or that there won’t be another generational B2B SaaS business. But the noise and saturation make it harder for these companies to grow quickly while retaining customers and high margins. There aren’t many land grab opportunities in pure SaaS like there were in the 2010s.

Even for companies with great products, it’s getting harder to sell to businesses with SaaS fatigue. To return to the original dental example: suppose you (the entrepreneurial dentist) build the best vertical software for dental practices. Your target customers are already inundated with such pitches. The same is true if you’re pitching the most well-oiled acquisition strategy for underperforming practices. It’s hard to sell them a genuinely better product, and it’s also hard to convince them to sell their businesses.

That brings us to the pull factors. What makes the non-pure-software approach so attractive? First, new tech and business models enable startups to monetize more than just software subscriptions. I talked about this in “Invisible asymptotes in vertical software”. Products like embedded payments with Rainforest* or embedded marketing with Reach* allow software companies to capture a variable portion of their customers’ success, upside that grows as their customers grow, and not just a fixed fee for software.

Another is the rise of AI as a credible substitute for certain types of work. This has two direct effects:

First, it allows significant costs to be taken out of a business and/or for labor to be added to places where it previously wasn’t economical. For example, an accounting firm that previously needed a large back office team for mundane, repetitive tasks can offload more of that to AI and reduce headcount. A small field services business can now use voice agents to answer the phone at a fraction of the cost of a full-time employee.

Second, AI allows companies to implement a broader, more consistent, and more scalable version of playbooks. If PE involves implementing playbooks for teams to follow, while VC involves building software that encodes playbooks into workflows and data models for teams to follow — both are vulnerable to human error. In both cases, the people involved need to actually follow and implement the playbooks. AI takes that out of human hands.

So, VC funds and venture-backed companies can and must explore strategies in the messy middle. They both (1) must move away from old and less effective models, and (2) can adopt new models with higher expected returns. That’s why seemingly unconventional company structures have emerged.

The yin and yang of code and capital

To improve businesses and generate returns, the VC model uses code as its primary source of leverage, while the PE model uses capital. The new models mix code and capital in unique ways to achieve the same result: improve how a set of businesses operates, then harvest upside. The latest mixtures of code and capital allow investors and entrepreneurs to work with more businesses. They also make it possible to create and capture more value than was previously possible in a pure VC or PE model.

The new models seem to fall into three categories: the crown jewel, the roll up, and business-in-a-box.

In the crown jewel model, a VC firm or VC-funded company acquires a one-off, large, strategic, and non-tech asset. The crown jewel might be a hospital or health system, a professional service firm in law or accounting, a call center or BPO, or a parking lot operator. The acquirer doesn’t simply acquire and run a business marginally better (as in traditional PE). The acquirer may already have a proprietary tech stack or strategy that it’s applying to the crown jewel asset. Or the acquirer may build such technology as it operates the new business, with the crown jewel asset as its ideal and captive first customer. Under this model, the acquirer applies proprietary tech to an already at-scale business where it will have the greatest and fastest ROI. Crown jewel examples include the AI-powered parking software company Metropolis acquiring a century-old, publicly-listed parking lot operator SP Plus for $1.5 billion, or General Catalyst acquiring a large healthcare system in Ohio for $500 million.

In a venture roll-up, a company acquires multiple non-tech assets and then applies its proprietary technology and strategies. Think of a roll-up in contrast with the opportunistic, often one-off, and strategic M&A of the crown jewel model. In the venture roll-up model, the M&A is continual and applied to multiple businesses. Traditional PE often involves a low-tech roll-up approach. The venture roll-up model differs from the PE roll-up because it involves applying a full stack of proprietary, purpose-built software for that vertical. The venture roll-up may also build in-house technology to assist and scale the M&A process, such as proprietary data and underwriting to identify, underwrite, and value the best acquisition targets. Examples include Cabana, Pipe Dream, and Long Lake in field services, as well as OLarry and Multiplier in professional services.

In the last model, business-in-a-box, the company actually helps create and start new businesses in a vertical. Like the roll-up model, it brings proprietary technology and works with multiple end businesses in parallel. But it creates these businesses rather than acquires them. It can create businesses under unique individual brands (business-in-a-box) or under a common brand (modern franchising). These can include purely digital services offered at least partly through a managed marketplace. Examples include Fora for travel agents or Headway for therapists, as well as brick-and-mortar businesses, such as Moxie for med spas. Sam Gerstenzang, the founder of Moxie and Boulton & Watt, is the expert on the model and wrote a great piece on which markets are most amenable to it.

These models are evolving quickly and aren’t mutually exclusive. For example, biz-in-a-box vendors may execute some opportunistic roll-ups or vice versa. Similarly, incumbent vertical software companies may begin adopting these new models. To return to the PG tweet above, if a vertical software provider finds its market or margins tapped by just selling software and services, it may be compelled to start operating businesses in their verticals. Alongside the list of products vertical SaaS companies offer, such as CRM and payments, it’s increasingly common to see an option to “Start your business with us” or even “Sell your business to us.” For example, Slice (“Start your pizzeria”) or MoeGo Care. This creates some interesting territory to navigate — including the potential for channel conflict and competing with existing customers.

The biggest companies are built and the best investments made when things are in flux, when generally accepted models have been exhausted, but no obvious replacement has risen. That flux is happening in VC and PE. The classic VC/PE investment model, as well as the traditional strategy of VC-backed, SaaS-centric, B2B software companies, is approaching a saturation point. It’s still early as funds and companies explore new combinations of code and capital, of software and financial engineering, in this messy middle. Interestingly, it isn’t just a game for new funds or companies. Some of the earliest examples of this trend are established investors (e.g., General Catalyst / Summa) and software companies (e.g., Metropolis / SP Plus). But the model is evolving, and there will be many new opportunities to build generational companies by creatively mixing code and capital.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: mb@matrix.vc

The loud debates over “AI versus software” frame the choices poorly. They obscure the right strategy for each player in the emerging stack: incumbent vertical software, emerging vertical AI, and general model companies. Let’s look at how that stack started and is evolving.

The evolving software stack

The classic software stack has three layers:

This architecture applies to single software products and companies' broader software stack. Businesses need reliable sources for important data like customers, expenses, and revenue. Employees generate this data in fragmented and sometimes conflicting ways. For example, information about a customer may be spread between the teams and tooling in sales, implementation, and billing—but it must ultimately be synthesized and reconciled into a single place.

The relative value of these layers has changed as software has evolved. In the early software age, only a handful of vendors existed. The winning ones developed all-in-one solutions and systems of record. They centered on vital business resources: employees (human capital management, HCM), customers (customer relationship management, CRM), and revenue/expenses (enterprise resource management, ERP). In this model, most of the value accrued to databases like Oracle, SAP, and Salesforce.

SaaS made software cheaper to create and distribute. This broke down interaction systems into many specialized apps. During this time, there were notable SOR IPOs like Workday, ServiceNow, and Veeva. However, SOE companies like Docusign, Box, Zoom, Slack, and Smartsheet really defined the era. They created value by digitizing and streamlining employee workflows.

The latest evolution of this stack is vertical software (vSaaS). It combines the SOI and SOR into one product designed for a specific vertical. For example, Clio for lawyers, Housecallpro for field services, Brightwheel for schools.

A single product in a vSaaS bundle is likely weaker than a general option. For example, Clio’s CRM isn’t as strong as Salesforce’s. However, lawyers still prefer Clio because it’s purpose-built for them and integrates with all the other modules that Clio provides. For example, a prospect in Clio’s CRM can be turned into a client, so lawyers on Clio can track time, assign work, bill hours, and get paid.

Enter AI

Vertical AI is shaking up the stack again. It comes in many flavors. Co-pilots augment labor and workflows. Agents offer a more invisible “do it for me” value proposition. AI is also making software easier and cheaper to build.

Intelligence is becoming cheaper. The software for interacting with it is also more affordable. Everyone thinks this means every business will build their own software. Or that they won’t need to build software per se because the intelligence at the interaction layer will be nearly free.

What becomes more valuable if intelligence is cheaper and the interactions with it are cheaper? It’s the data model for a vertical, the data for a specific business that fits its vertical data model, and the workflows and controls necessary to use that data to fit that specific business or industry. Or—put another way—a system of record.

AI rock and a hard place

Let’s take a hypothetical example in the roofing market. “ShingleSoft” is a vSaaS for roofing companies. It has a full suite of software products: CRM, estimates, scheduling, project management, inventory management, time tracking, payroll, billing and payments, accounting, etc.

“RoofGPT” is an AI-focused startup. It knows that many roofing companies can't hire full-time sales, marketing, and operations employees. Many sales calls to roofers go to voicemail while the employees are up on roofs. So RoofGPT offers a voice agent. It picks up on the first ring and qualifies customers. It’s the equivalent of having infinite smart and polite salespeople ready near a phone 24/7.

The problem is that these “salespeople,” no matter how smart or skilled, are disconnected from the business. They’re perfectly capable of requesting numbers for a callback, and answering deterministic questions about operating hours. But they struggle when they’re asked about something that an employee sitting in the roofer’s office would know.

• “Can I reschedule my inspection?” requires access to the roofer’s CRM to look up the customer record and the employee schedule.

• “Can I pay my bill over the phone and can you send me a receipt?” also requires access to the CRM, invoicing, and payments system.

If all the roofing companies use a fragmented suite of tools (e.g., CRM from Hubspot, scheduling from Calendly), RoofGPT could build API integrations with all of them. However, for many verticals, these functions have been consolidated into a single vSaaS, like ShingleSoft. This is a double-edged sword for RoofGPT. They can interact with a single platform to create and update records across multiple functions. But they’re also beholden to that single vendor. Suppose they choose not to integrate. Suppose they focus on providing excellent voice functionality without direct access to the SOR. In that case, they’ll face commoditizing pressure from increasingly capable horizontal AI tools (e.g., OpenAI’s Operator).

So RoofGPT is facing two pressures. First, the pressure of increasingly capable and commoditized intelligence. Second, the pressure of increasingly centralized, rare, and controlled data and interaction with the vSaaS providers.

ShingleSoft isn’t an AI-native company, so they may be slower to build AI features. They may already have a robust API and partner ecosystem, so they may support RoofGPT initially. However, the core strategy of vSaaS is clear: bundle, bundle, bundle. The more products they offer, the more roofers they can acquire and the more they can charge. As outlined in “Invisible asymptotes in vertical software”, successful vSaaS know they need to (1) solve as many problems as possible and (2) find monetization models beyond SaaS that both drive growth/success of their customers and capture more of that upside and growth.

“Pretty good” products that are deeply embedded into the core vSaaS product are likely to beat “Excellent” products that lack deep integration and lack platform distribution.

Put another way, if I’m a roofer, which of these options would I prefer?

• (A) the world’s best salesperson, but they’re stuck in a room alone with no access to live info about my business

• (B) a decent salesperson who is deeply familiar with business, services, schedule, and employees

Most would probably choose (B). That’s especially true if the gap between the quality of the salespeoples’ standalone skills keeps shrinking every month.

Choose your wrapper wisely

Every business is a wrapper. To be flippant, SaaS companies just wrap cloud providers, which wrap cloud hardware providers, which wrap semiconductor foundries. Being a wrapper is not in itself a bad thing. What you wrap and how you wrap it makes it bad or good.

Especially if you’re wrapping a commodity, you must give customers a reason to buy from you versus going direct. You can do this with product (by improving or adding value to it). You can also do it with distribution (selling it cheaper and/or more effectively than customers could get it themselves). Having one is good, having both is better.1

Today vertical AI agents are primarily wrapping product, building something novel enough that it’s getting them powerful distribution. However, there’s a limit to how much value they can add without owning or accessing the SOR. At the same time, “good enough” intelligence is being commoditized. I doubt intelligence will ever be so commoditized that the end B2B user relies exclusively on agents. But I think it will be sufficiently commoditized enough to seep into adjacent software products. It’s already happening. Successful vSaaS companies are expert bundlers. They’ve mastered multi-product motion. They also have existing distribution through their install base. And because they are the SOR, they can build an integrated experience much better.

So what’s the right strategy here? Will vAI or vSaaS win?

Emerging vAI companies have a harder path to success than they thought. Early fast growth will taper off as they, their customers, and vSaaS partners realize the value of integrating with the SOR (and limits of not being integrated with it). vAI companies should ignore the FUD around the “end of software” and have a clear plan to displace the SOR. This may apply less to vAI companies in verticals without a modern vSaaS incumbent. They’ll have an easier time starting with an AI wedge and building out the SOR rather than displacing another one.

Existing vSaaS companies are net beneficiaries of AI commoditization. It’s likely a sustaining rather than disruptive innovation to them. They have more time to make strategic moves in offering their customers AI products, whether by building, buying, or partnering.

Embedded AI for vSaaS is a newer category, empowering vSaaS to add vAI features faster and more successfully. This is different than simply embedding AI. It involves configuring AI to help vertical-specific workflows, such as marketing and customer support (e.g., Reach). Think how companies like Rainforest or Stripe enable vSaaS to embed payments rather than become payfacs themselves.

The dynamic between vAI and vSaaS is reminiscent of the early days of the streaming wars. There was competition between Netflix (a streaming platform that licensed content) and HBO (a content company without a streaming platform). In 2013, a Netflix exec famously said, "The goal is to become HBO faster than HBO can become us." The right answer wasn’t streaming or content but both together.

It’s worth noting that most of the major streaming services today are “full stack.” They own the content production and tech. They’re about evenly split. Around half started with streaming and got into content production (Netflix, Amazon Prime Video, Hulu, Apple TV). The other half started as content producers and got into streaming (HBO, Disney, Paramount, Peacock). I expect something similar will play out in B2B software, where the winners in vSaaS will own the IP (customer data and workflows), not to mention existing brand and distribution, and layer on the new tech.

The dichotomy of AI versus software is a false one, especially in B2B verticals. They complement each other, and each vertical’s winner will thoughtfully combine both.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: mb@matrix.vc

Many countries have different tracks, either by design or historical accident, so many trains require different wheel assemblies to cross borders. Most passengers later woke up in the same carriage they fell asleep in, now traveling through a different country on different rails and wheels.

There’s more to money than money

I thought of that Mongolian railyard often as I started learning about stablecoins1. Before that trip, I thought rail cars and their wheels were all the same, all purpose-built for the tracks they ride on, which are more or less the same globally. But that’s not true. Carriages, wheels, and tracks are separate but related elements, are designed and built with various priorities2, and are different worldwide.

The same is true of money and the financial infrastructure it’s built on. Neither is valuable without the other, so each is designed symbiotically, resulting in benefits and trade-offs.

Fiat currencies like US Dollars (USD) and Euros (EUR) are issued and managed by central banks and governments, who also help create and regulate their underlying rails. This centralization makes these currencies stable and useful, but it also restricts how the rails can be used and who can use them. Think of fiat currencies as safe, comfortable, and highly desirable railway cars that ride on rails that can be slow, opaque, and inaccessible to many. There are some differences between the rail systems of different countries, but they’re generally interoperable if you have enough time and money.

The blockchain and associated decentralized infrastructure gave rise to thousands of cryptocurrencies. While the infra was fast, global, permissionless, and transparent, the currencies themselves were often too volatile to pass the major tests of money. There’s plenty of value and utility in various cryptocurrencies. Still, none of them could be used as a day-to-day transactional currency – like there’s value and utility in assets like gold, but you still wouldn’t use it for transactions daily.

If fiat currency is an old-school railway system, blockchain is a magnetic levitation (meglev) train. It was open source, permissionless, and globally available, so anyone could build their own tracks and cars. This led to many valuable and interesting new vehicles and lines. Still, few wanted to ride them regularly or on long journeys since they weren’t comfortable, reliable, or safe at first.

Because this maglev system was so new, sometimes dangerous, and certainly long-term competitive, the older rail systems made interoperability difficult. They didn’t want maglev trains riding their rails.

But it was easy enough to retrofit the older but safer and more comfortable carriages to the fast, futuristic, and global rails. That’s effectively what stablecoins are: the best of both worlds. They are reliable cars that can ride on traditional or futuristic rails, switching easily between the two and connecting different rail systems.

Between and within financial systems

Stablecoins have several valuable use cases between and within different financial systems.

The first is as a bridge between the fiat and crypto worlds. In this case, the value was more in the currency itself (and its stability) than in the infra. Stablecoins allow crypto users to store and exchange a stable form of value on chain3. Access to a global, nearly permissionless form of stable digital currency also helped people in countries without a stable local currency.

The second emerging use case is parallel infra within a fiat system or between different fiat systems. In this case, the value is in the stablecoin infra as much if not more than the currency itself. Because stablecoins are fast, cheap, global, and programmable, they’re promising complements or substitutes to traditional money movement products like cross-border payments, treasury management, and settlement. In this use case, the end users might not even know they’re using stablecoins, but they’re attracted to product benefits like speed and cost.

The third emerging use case is in building de novo stablecoin products that exist within the fiat world, where the value is in both stablecoins themselves and their infra. The idea is to offer the benefit of stability without the downsides of centralization. With fewer intermediaries and more transparency, money can move faster, cheaper, and more securely. This is still evolving, but interesting applications are appearing, such as stablecoin-only banks.

Making and moving stablecoins

The most common type of stablecoin is fiat-collateralized: one stablecoin represents and can be redeemed for one unit of fiat currency – i.e., 1 stablecoin (USDT, USDC) = 1 USD. Other variations include asset-collateralized (e.g., gold), crypto-collateralized, and algorithmic stablecoins. We’ll focus on fiat-collateralized since it’s the most common and straightforward to understand.

Stablecoins are created by issuers, who create (“mint”) or destroy (“burn”) stablecoins in exchange for fiat, and partner with others to facilitate this exchange, increasing the use and indirectly the value of their stablecoin. Issuers monetize the float on these deposits.

Issuers mint stablecoins onto various blockchains, third-party (e.g., Ethereum) or first-party (e.g., Ripple). Different blockchains offer different features and benefits, such as increased throughput or security, and many stablecoins are compatible with multiple blockchains.

For example, say Alice wants to buy $100 of USDC. She sends $100 USD to Circle, which stores the fiat in their trust account at a bank. Circle then mints 100 USDC coins on the blockchain and sends them to Alice’s on-chain wallet.

Alice can send the USDC from her Circle wallet to Bob, who sends it to Carol. These are all nearly free and instant transfers since all three make transfers on the blockchain. However, each person treats the 100 USDC as if they were $100 USD, since they effectively are a claim on the $100 USD stored with the issuer. Let’s say Carol needs to convert her 100 USDC to USD: she sends it back to the issuer, who destroys the stablecoins and releases the equivalent in fiat to Carol.

It’s inefficient for end users to interact with issuers for every transaction, so they’ll partner explicitly or rely implicitly on liquidity providers, such as exchanges, OTC desks, financial institutions, or other market makers. These maintain pools of fiat and cryptocurrencies, often exchanging them for a spread on each transaction. This can be as simple as buying small amounts of USDC with fiat from Coinbase rather than from Circle, or more complex, like cross-border use cases where stablecoins are exchanged for an exotic local fiat.

Some stablecoin use cases, such as payments and remittances, are more complex. For example, say a company wanted to allow its users to send USD to various Latin American countries. It would need to support on- and off-ramps in different countries, maintain various first- and last-mile fiat infra, do KYC on senders and recipients, and manage liquidity pools for several currencies. It could also work with orchestrators, like Bridge, which handle the complexities of these funds flows and regulatory requirements.

Other players are beginning to emerge, such as businesses that look like more traditional merchant gateways, but for crypto (e.g., Transak, MoonPay), as well as stablecoin-native applications, such as Zarpay and Dakota.

The multi-billion dollar question is: Where does value accrue in the rapidly evolving stablecoin stack? The lines between these categories are already blurred. Some applications are building their own orchestration (e.g., Sling Money) and some liquidity providers are deeply partnering on issuance (e.g. Coinbase, Circle). The lines between these stablecoin layers are also blurring with the fiat world, whether it’s through building (Visa’s Tokenized Asset Platform), buying (Stripe + Bridge), or partnering (OKX and Singapore’s DBS). Although the end state of stablecoins is uncertain, the journey will be exciting!

As a reminder, I’m a partner at Matrix, an early-stage VC firm that invests in fintech and areas like AI, B2B, infrastructure, healthcare, and frontier tech.‍ I focus on fintech and vertical software and am particularly interested in stablecoins. If you’re building or interested in the space, I’d love to hear from you: mb at matrix.vc

"Cross-border payments" are payments made between parties in different countries. While the concept is straightforward, the systems that move >$45 trillion annually across borders are anything but. That’s because cross-border payments (XBP) must account for things domestic payments take for granted.

Say I want to send $100 USD to a friend in Japan. Those funds need to somehow move between two banks that may not have a direct relationship with one another across different payment rails and regulatory regimes and eventually land as Japanese Yen (JPY) in an account around the world.

The various solutions to this involve two common parts: (1) acquiring and supporting local users on both ends of the transaction, including first/last mile of money movement and local regulatory compliance, and (2) the “middle mile” of moving money or value across borders, converting currencies, and managing FX and liquidity risks:

This note covers four XBP methods: correspondent banking, money transmission, payment aggregation, and stablecoins. I’ll discuss the trade-offs inherent in each solution, as well as the factors that affect the product and business strategies of XBP companies.

Correspondent banking

Correspondent banking is a long-standing and still dominant XBP method. It describes how banks establish arrangements and accounts with banks in other countries and then work together to provide services like XBP. For example, an American bank like Chase will maintain an account in a Japanese bank like SMBC funded with JPY.1 Banks use SWIFT to coordinate payments. SWIFT isn’t a payment rail but a secure messaging system. The money movement is accomplished by netting the local accounts and/or with settlement systems like CHIPS (US) or TARGET2 (Europe).

Say I wanted to send $100 to that Japanese friend. If Chase and SMBC have an existing relationship, they’d coordinate using SWIFT, net the JPY from Chase’s account at SMBC, and credit it to the recipient’s JPY account:

If the sender and recipient’s banks don’t have a pre-existing relationship, they’d use correspondent banks as intermediaries. In this case, Correspondent Bank A has the JPY nostro account with Correspondent Bank B:

Correspondent banking can involve multiple intermediaries, including in third countries, to complete transfers:

The benefit of this method is wide coverage: the network can eventually connect almost any two banks. However, this comes at the expense of speed and cost, as each intermediary takes time and a fee to process the funds through the network.

Money transmitters

Money transmitters (MTs) such as Western Union and Moneygram are another long-standing and popular XBP method. They’re popular among the un/underbanked since the sender and/or receiver can transact in cash. MTs operate a global network of agents – physical storefronts such as conscience stores or currency exchange stalls – that offer MT services. Senders deposit cash with an agent and leave instructions for who can retrieve it elsewhere on the MT’s network.

For example, say I deposit $100 at a Western Union location in San Francisco and list my Japanese friend as the recipient. The agent verifies my request and then sends the funds to Western Union.

Western Union credits them to my friend in Japan and nets the funds between its USD and JPY accounts minus a fee. My friend can then pick up the equivalent in JPY at a Japanese Western Union agent by showing their ID or a confirmation code:

Correspondent banking and money transmitters are often critiqued for being slow and expensive. This cost and slowness are the downsides of their broad geographic coverage, resulting from their reliance on intermediaries. Because many MT users lack formal banking, an agent network is necessary for first/last mile distribution. In contrast, the lack of 1:1 global banking connectivity necessitates the correspondent banking network for the middle mile. Now let’s discuss two newer XBP models, which use technology to minimize intermediaries.

Payment aggregation

Payment aggregators like Wise can be considered digital-first money transmitters, with apps instead of agent networks. These companies maintain bank accounts in the countries they support, pre-funded with local currency, and the infrastructure to pay in from and out to local users on each end. The actual “cross border” transactions are often internal net transfers, similar to correspondent banking, but the fintech orchestrates the transaction.

Let’s return to the example above, but use Wise to send money to Japan. Initiating the transfer, I’ll send $100 from my bank account to Wise’s USD account:

Wise will then transfer the equivalent amount from its JPY account in Japan to my friend’s SMBC account. No USD leaves the US and no JPY enters Japan.

This is faster and cheaper than correspondent banking and money transmitters because there are fewer intermediaries. Because Wise is the intermediary, it has more control over everything from the UX to the costs. This benefit does not come easily though. Beyond maintaining the local accounts, Wise must acquire and support users, comply with local regulations like KYC, manage liquidity and FX risk across countries, and more. Wise users are also limited to countries where Wise has established on/off ramps.

Stablecoins

The newest kid on the XBP block is the stablecoin, which offers several improvements on all other XBP methods. A stablecoin is a digital currency backed 1:1 by fiat currency like USD, so its value is constant, and it’s tradable instantly and globally. Since the blockchain and exchanges never close, stablecoins can be converted almost instantly to/from fiat. When combined with burgeoning 24/7 fiat real-time payment networks, stablecoins enable near-instant fiat > stablecoin > fiat transactions.

Taking the USD to JPY example again: once the sender initiates a transfer via Bridge or a platform that’s integrated it, USD moves over local fiat rails to Bridge’s local USD account:

Bridge then exchanges the USD for a stablecoin such as Tether (USDT), and transfers it to a wallet linked to its bank account in the recipient’s country. The USDT is then converted to JPY in Bridge’s local Japanese bank account and moved over local rails to the recipient’s account:

Like payment aggregators, stablecoin infra providers must maintain local accounts, follow local regulations and compliance, such as KYC/B senders and recipients, and more. 

Cost, speed, coverage: the XBP trade-off

All XBP systems must solve the core problem that a sender and recipient, as well as their respective banks, may not be directly connected. The solutions to this problem create trade-offs in speed, cost, and coverage of supported countries/currencies. 

Correspondent banking and money transmitters were pioneered in the pre-digital era2, so their models use networks of intermediaries in different ways to solve the same problem. They generally optimize for coverage at the expense of speed/cost. Payment aggregators and stablecoins use technology (e.g., better onboarding and servicing via mobile apps, faster/cheaper pay in/out via emerging RTP rails) to reduce or eliminate intermediaries:

Interestingly, some new players offer embedded models, either as a pure play (e.g., Airwallex, Nium, Bridge) or as a complement to their existing direct business (e.g., Wise Platform).

XBP economics and product strategy

Beyond the mechanics of how money moves across borders, it’s important to understand how factors like sender/recipient and country/currency mix determine the strategy and economics of XBP companies.

The sender/recipient mix (C2C, B2C, C2B, B2B) determines distribution strategy, regulatory and compliance burden, product adjacencies, etc. Because businesses generally send and receive more payments more frequently than consumers, they have more pricing leverage and see lower take rates than mixes involving consumers. For example, Remitly (C2C) has a gross take rate of >200 bps versus Corpay (B2B)’s <60 bps.

The corridor is another important determinant of take rate. Generally corridors with larger volumes, more stable currencies, more balanced flows, modern banking infrastructures, and complementary regulatory regimes are more competitive and therefore have lower take rates. Inversely, there’s typically less competition and higher take rates with more volatile currencies, unbalanced and low/inconsistent flows, and antiquated financial infra. The take rate is up to 25x greater for the least competitive corridors.

Many XBP companies follow the general fintech trend of complementing low-margin transactional revenue with other complementary financial products and/or higher-margin software products. For example, Wise offers interest-bearing deposit accounts while Flywire offers vertical software for its key industries, like education and healthcare. Embedding for distribution is another popular strategy, with companies that were initially direct-to-consumer offering products like Wise’s Platform and Airwallex’s embedded solution.

That’s XBP in ~1,000 words! If you’re building in this space, email me: mb at matrix.vc

I call this the “embedded payments iceberg”. Many companies think that a few lines of code and hours of work will yield a whole new monetization model. However, integrating payments is just the tip of the iceberg, and real success requires more than product and engineering work. One of the most important yet least appreciated aspects of a successful payment strategy is pricing.

It’s not as simple as slapping a 2.9% + $0.30 fee on card transactions and calling it a day. There are many levers to pull in pricing payments. The right set of levers depend a lot on the vertical software platform’s market, its existing product suite and pricing strategy, and more. Seemingly small decisions on payment pricing can mean the difference between no adoption on one hand or lots of adoption but low or negative revenue on the other. It’s challenging to find the right balance and strategy.

Rainforest1, which offers embedded payments to vertical software platforms, recently released a free guide on payments pricing that should be required reading for anyone who has or is considering embedded payments. It’s available for free, with no registration required:

Get the VSaaS Payments Pricing Guide

I suggest you download and read it, but I’ll summarize some of the most important points below.

Start by learning as much as possible about how your end customers accept payments today

The ideal payments pricing strategy for your platform hinges on the mix of payments your customers receive. Are they typically large or small? There’s a big difference between a coffee shop with an average order value of $5 and a B2B marketplace with order values of $5,000. The former should care more about the per-item fee, while the latter should care more about the volume fee component:

How do your customers’ customers pay? Even if it’s mostly through card, what kind of card? There are key differences between debit and credit cards, personal and business cards, domestic and international, Mastercard/Visa versus Amex. understanding this will help set a strategy for interchange plus, flat, or blended pricing:

Understand how comprehensive and specific your solution is, and how competitive and well-defined your market is to determine price ceilings

While many think 2.9% + $0.30 is the payment market rate, some platforms have more pricing power. To understand that power, consider factors like how comprehensive and critical the base software platform is, how narrowly defined your ICP is, and how unique embedded payments are in your vertical:

The implementation and pricing of payments allows for different ways of recognizing payments revenue, which affects a company’s valuation

There are a couple of ways to recognize payment revenue, which will affect your finances differently. If your company plans to raise money or be acquired, it’s critical to understand how investors or acquirers will evaluate your payments revenue and its effect on your margins.

I won’t spoil the rest of the guide, but it’s worth a read for anyone who cares about succeeding in embedded payments:

Get the VSaaS Payments Pricing Guide

And if you’re considering adding or improving payments, it’s worth chatting with Rainforest. They have decades of combined expertise in payments and vertical software. The platform is excellent, but their service and guidance in navigating that “embedded payments iceberg” makes them the new secret weapon for vertical software companies. You can find there here: Rainforest.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: mb@matrix.vc

An earlier generation of companies, like Toast and Mindbody, demonstrated the power of combining vertical-specific software with financial products like payments. This led to the explosion of vertical software across industries and the evolution of the model into a more vertically focused, multi-product, and multi-business-model approach I call “Vertical X.”

I’ve kept a list of these companies over the last few years as they’ve proliferated across verticals, from agriculture to auto-body shops, self-storage to security businesses, marinas to medispas, parking to pet care.

This list has helped me map trends in vertical software, like the adoption of different embedded financial products across these verticals:

I’ve expanded and cleaned up that list of vertical software companies and am making it available as a resource to anyone interested in these markets.

The goal is for verticalsoftware.fyi to be a resource for founders, operators, and investors interested in the space.

Visit verticalsoftware.fyi

Click here to access the full list of companies.

It’s certainly not exhaustive, although I hope to keep it as updated as possible. If you think a company is missing or miscategorized, please let me know here.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: mb@matrix.vc

• Vertical software experiences regular evolutions, where the winning companies offer a broader and more complex product suite for the vertical. For example, the first generation of vertical software was primarily verticalized point solutions (e.g., project management for construction), but today’s vertical winners bundle multiple software products (e.g., CRM, workflow management, billing) with multiple embedded fintech products (e.g., payments, lending, payroll).

• This broadening of the product strategy has two benefits: (1) it helps startups differentiate against incumbents, and (2) it helps expand the addressable market by increasing the revenue each customer can generate. 

• However, even this model will hit decreasing returns. Even if a startup supplies 100% of the software and financial services to companies in a vertical, it will only capture a fraction of that vertical’s overall value.

• So, a new model is emerging: startups are not just offering bundled software and embedded payments, but more importantly, some other product or service that helps new businesses start and existing businesses grow. And most importantly, these startups have found ways to capture more of the growth from this upside than previous models ever could.

The Red Queen dynamic, named after the character from Lewis Carroll's "Through the Looking-Glass," is an evolutionary concept that describes the arms race between competing species. Species must continuously adapt and evolve to survive in a changing environment. It’s like what the Red Queen tells Alice: "It takes all the running you can do to keep in the same place."

Investing in fintech and software, I sense that the Red Queen dynamic in these markets is ratcheting up in a way that may not be widely apparent yet. To understand where the dynamic is going, let’s understand where it started.

Subscribe now

Software is dead, long live software

Established markets like software and fintech often have a dominant strategy at a given time. That strategy combines technology, business or pricing models, and product shapes, all of which are interrelated and exert a push-pull effect on one another.

This dominant strategy changes over time. As strategy X dominates a market, startups will often use a new strategy Y that’s more complex, expensive, or difficult in some way but gives them an edge in displacing incumbents using strategy X. Eventually, the challengers become incumbents. All the survivors have adopted strategy Y. The cycle starts again with new challengers adopting strategy Z, which is even more complex, expensive, and expansive than X or Y. This is the Red Queen dynamic.

Starting in the 2000s, the dominant strategy for most B2B categories was to build a single product, target a horizontal or at least a broad market, and monetize through SaaS. Think of the companies founded in 1995-2010, many of which are now public, like Salesforce, Docusign, Zendesk. I call this “SaaS 1.0”.

As those companies grew and dominated their categories, the Red Queen dynamic ratcheted up. Startups needed to do something different, more, and better to compete.

2005-2015 represents the era of “vertical software” or “vertical SaaS.” These companies targeted specific verticals but also monetized via SaaS. Their vertical focus was the common denominator. Some focused on a single product for a vertical (e.g., Gorgias doing support or Klayvio marketing for ecommerce). Others embraced a multi-product approach, often including non-software financial products, like payments (e.g., Mindbody doing scheduling and payments and more for fitness studios). 

Starting in the late 2010s, there was a variation to vertical software that I think is significant enough to warrant its own label, which I called “vertical ERPs.” These focus on a specific vertical, are multi-product with both software and embedded financial products like payments, and, most critically, attempt to become that vertical’s system of record by orienting their multiple products to create, capture, and expose the core data for that business. These companies will often describe themselves as the “operating system for <<vertical>>” or “all-in-one <<vertical>> management platform.” Some examples of this include Cents (”One system powering your entire laundry business”) and Clio (”Everything your law firm needs. All in one place.”).

To recap, in software and adjacent fintech spaces, there’s been this accelerating evolution of dominant strategies:

One important note: One era’s incumbents will adopt the new era’s dominant strategy once it’s eventually proven. Some do it slower and reluctantly, while others are faster and more proactive in adapting. For example, Shopify launched its software product in 2006 and then Shopify Payments in 2013, solidifying it as a pioneer in embedded payments monetization. Clio launched in 2008 and focused on multi-product software for many years until launching Clio Payments in 2021, which were critical to doubling their revenue ahead of their recent fundraise. So this constant adaptation to the currently dominant model is a vital part of what keeps the Red Queen dynamic going.

There’s still a lot of upside and growth for companies running the Vertical ERP strategy. I’m constantly surprised at how much more software businesses are willing to adopt and move even critical parts of their financial stack into software via embedded products.

However, I’m also seeing the Red Queen dynamic ratcheting up again—with the emergence of a new, more expansive, complex, and lucrative strategy. 

Subscribe now

Expand the model, expand the market

New strategies are competitive not only because they’re differentiating from the incumbents but also because they greatly expand the vertical’s total addressable market (TAM). These points are critically linked: to justify increasingly expensive and vertical-specific investments necessary to compete, each new vertical software model must generate more revenue from the same customers than the older model could.

Let’s see how market sizing evolves with each new strategy using an example from the legal services market. To simplify the math, say there are 100,000 small to mid-sized law firms in the US, with an average of 10 employees each and average top-line revenue of $1M.

Horizontal and vertical software 1.0 models often charged a fixed monthly fee per user (e.g., $49/user/month). So the TAM equation for these models would be the following: Price per seat * Number of seats. So that’s $49/month * 12 months * 10 users * 100,000 firms, or a TAM of $588 million. A big number, but not venture scale. Even if you doubled or tripled the price per seat, the market is still limited by the number of seats and price per seat.

The Vertical ERP model builds on and breaks this limitation by embedding financial products. Payments is often the first financial product embedded. Most importantly, in the case of payments, this monetization is not fixed by the number of seats but is variable with the revenue each customer generates. Vertical software companies have a low take rate in payments (i.e., 0.5-1.0% of incoming payments), but this number is large when applied to the entire market. 

Returning to our example, under the vertical software model, you could expect each law firm to generate $5,880 of annual revenue ($49 / seat * 12 months * 10 seats). By monetizing payments, that same firm represents an additional $5,000 annual revenue ($1M * 0.50% take rate). This doubles the potential revenue per customer, which justifies the increased scope and complexity of the product.

This is the current dominant strategy in vertical software. Many companies are adding multiple software products and increasing per-seat prices, as well as adding payments and other embedded financial products, like banking. Each additional product differentiates them from incumbent companies without that scope and increases the amount they can generate from each customer. That, in itself, is a big competitive advantage.

Eugene Wei wrote an article on "invisible asymptotes", which are the unseen barriers that limit the growth of a product, company, or market. These are the factors that, regardless of effort or investment, prevent further progress. For example, in the early days of Amazon, Jeff Bezos identified shipping costs as a potential invisible asymptote. He realized that no matter how much they improved their website or expanded their product range, high shipping costs would always limit their growth. This insight led to the creation of Amazon Prime, a program that offered free shipping and effectively removed this invisible asymptote.

Vertical software models have their own asymptotes. For SaaS-focused ones, it was the number of potential seats in a company and the amount that could be charged per seat. Even if they captured 100% of the seats in a company and charged a high SaaS fee, the overall spend on software would still be a small fraction of the expenses or revenue of the business. This product and pricing model was the asymptote. 

So the next-generation vertical software companies embedded payments and other financial products, where they captured a portion of the revenue (via embedded payments) and expenses (via embedded issuing and banking). This greatly expanded the TAM, but it’s still limited by the number of companies in the market and their revenue. These models push the limit out a bit, but there’s only so much revenue you can generate from existing businesses by making them incrementally more efficient.

This model still has a long way to go and will be competitive for a while. Recent data I put together showed that embedded fintech adoption in vertical software was relatively low. However, just like the fixed per-seat model set a ceiling for the TAM of earlier strategies, the number of companies in a market and their topline revenue set a ceiling for the transactional model of Vertical ERPs. 

However, a new model is emerging. The new model could challenge the currently dominant one. Like the previous evolutions, this new model differentiates itself by solving a broader set of challenges with a more comprehensive product offering, which opens more monetization opportunities in each market and thus expands the TAM further.

While previous strategies made existing businesses more efficient, these emerging models do that, plus help create new businesses and grow existing ones. How they accomplish this varies by vertical. But the net effect is that they expand their markets, and capture a more significant share of upside in that newly expanded market.

It’s early, but the Red Queen dynamic is in effect again. Companies need to do more to differentiate from incumbents, expand the capture, and then capture a more significant share of what they capture:

Subscribe now

Vertical X, or variations of vertical software

This next generation of vertical software is exciting because it’s much more “vertical” and much less “software” than anything that’s come before. What does that mean? 

Previous generations of vertical software companies solved horizontal problems in a verticalized way. They offered many of the same fundamental products but with tweaks to data models and workflows. For example, Procore offers project management and field productivity tools for construction companies, and Clio does the same for law firms, it’s just called case management and time & expense tracking. They look different and are called different things, but many of these features and products “feel” the same across verticals today.

That’s why I call this new model “Vertical X.” It’s not only or even mainly software, but it’s also not just one thing. It’s inaccurate to call them “vertical marketplaces” or “vertical payments.” Many have those components and everything you’d recognize in vertical software 2.0 or Vertical ERP models. But this next generation sells something more: solutions to vertical-specific problems.

This next generation is anchored around solving vertical-specific problems in vertical-specific ways. These vertical-specific problems vary widely, but they all relate to some limit to growth in that vertical. The solutions to the invisible asymptote of growth in these markets typically fall into one of three categories:

• Reduce barriers to starting new businesses

• Wrangle and retain fragmented demand

• Make “at scale” pricing or products accessible

All of these are fundamentally about solving the question of scale. In a fragmented market, what advantages do the largest companies have that the smaller ones cannot access because they’re too small? For example, how can a local restaurant owner run a version of the McDonald’s franchisee playbook for greater efficiency? How can a small coffee shop get a version of Starbucks’ loyalty app and bulk pricing? How can a solo medical practitioner get a larger medical group's insurance coverage and back-office support?

Examples of “Vertical X”

I’m going to list a bunch of examples of companies that are using this new strategy. There’s a high-level pattern across all these new solutions. They differ from previous vertical software strategies in two meaningful ways: 

First, this newer generation of solutions focuses more on external relationships (e.g., with suppliers, customers, and regulators) than on internal processes (e.g., project management expense tracking). 

Second, the solutions to these problems are more than just software. They involve a mix of modalities, including marketplaces, content and education, regulatory constructs, and novel financial products.

Reducing barriers to starting new businesses

There are markets where demand far outstrips supply. In the long run, the market balances this out, but supply bottlenecks can still exist that smart founders are finding ways to unlock and monetize. The cause of these bottlenecks (and thus the solution to them) varies widely by industry.

In some markets, the bottleneck is specialized knowledge, training, or a honed industry playbook. For example, companies like Moxie help people start medspas. They offer verticalized software and payments, but they differentiate by providing 1:1 guidance from a Launch Director and Medical Director and ongoing guidance and coaching. Other companies offer lighter versions of this, such as MoeGo’s offering for new pet care businesses, discounted software, and dedicated coaching and content to help them succeed. 

In other markets, the bottleneck is credentialing and/or approval from critical partners, such as regulators or insurance providers. For example, it’s onerous for newer or small medical practices to get “in network” with various insurance providers. However, the more insurance plans they accept, the more patients they can take. Companies like Headway in mental health and Berry for dieticians help medical professionals get credentialed and in network. The folks at Slow Ventures have published great stuff on this as it applies to medical verticals.

Last, other markets face the bottleneck of upfront capital requirements for otherwise lower-risk businesses. In another take on the medical market, companies like Provide help doctors, dentists, and veterinarians get access to the capital to acquire an existing practice or start a new one. They even offer “dedicated project managers with loan closing and construction management experience” for ground-up construction of new medical facilities.

Acquiring, converting, and retaining fragmented demand

Demand is fragmented in many verticals. Even though customer acquisition is critical to any business, owners often don’t have the time, resources, or expertise to focus on it. In many verticals, owners would happily pay for incremental customers from sources other than paid search or social.

There are several ways that vertical software companies help their customers acquire and retain new customers. In the past, these strategies have been add-ons for companies at scale, but younger companies are starting to offer these services sooner, too.

One strategy is for the vertical software company to develop a buyer-facing brand and product, add value to that buyer-facing product, and then drive that demand to their customers. One example is Mindbody, which started as a vertical software company for fitness businesses and has since launched a consumer-facing brand for consumers to find and book classes. Shopify’s consumer-facing Shop App, which has a store directory, along with deals and shipment tracking, is another example. 

A lightweight version of this is to build buyer-facing products that facilitate conversion but are less branded and don’t try to capture users at the top of the funnel. For example, few consumers would start looking for take-out food on Toast, as they don’t have a marketplace as far as I know, but once they pay with Toast Payments, it’ll save that consumer’s payment details for easier checkout next time. A very different example comes from Hearth, software for home contractors that leads with embedded financing. A major constraint on home improvement projects is the homeowners’ ability to pay. Contractors can reduce that friction and increase conversion by offering financing directly to the homeowner through Hearth.

In addition to vertical software companies with unique acquisition and conversion products, many now embed everything from “do it yourself” to “do it for me” marketing tools into their broader suites. Features to build SEO-optimized websites, capture customer interest, and market to customers are increasingly common. Others, like Topline Pro, will go further and manage paid search and even print ads for local home services businesses. Companies like Hoist use AI to qualify and price leads for home painting businesses, while Supermove provides an “AI Sales Copilot” for moving companies to close and upsell more customers.

Make “at scale” pricing or products accessible

This is a particularly exciting category because it can have the most disproportionate effect on a market’s TAM and the opportunity for a vertical software company to capture it. The idea is that there are things that larger companies can do because of their size that give them some advantage, but these have been inaccessible to smaller companies – until now. 

One underappreciated but critical aspect of businesses with a physical component is their procurement of physical goods. Businesses at scale have much more leverage to negotiate better prices from their suppliers. Starbucks pays much less for the same pound of coffee beans than your local independent coffee shop, just like the regional healthcare system pays much less for bandages than your local doctor’s office. Companies like Gather and Faliam offer procurement and group buying discounts in medical, while Odeko handles the entire procurement system for coffee shops.

Another emerging trend is enabling sub-scale businesses to offer competitive services and lucrative products previously accessible only with scale. For example, having a dedicated sales team that can immediately answer, qualify, and convert customer calls is a big advantage but comes with high fixed headcount costs. Companies like Drillbit offer AI lead answering, qualification, and follow-up that make the top-of-funnel experience for smaller companies indistinguishable from that of larger ones. Other companies focus on offering entirely new products, like Dandy, which offers outsourced dental lab services to smaller dental offices, or Cents, which enables local laundry businesses to offer pickup and delivery.

The benefits of extreme vertical focus

Many “Vertical X” companies start with one differentiating solution, but the best compound the benefit of their vertical focus by layering on multiple over time.

Returning to our first example of Moxie. In addition to the deeply vertical software and fintech products, they offer the training, playbook, and ongoing support to help businesses start and grow. However, they also have deep relationships with pharma companies, whose products account for ~40% of a medspa’s COGS. A single medspa operator wouldn’t have the scale or time to build those relationships and get bulk discounts, but Moxie does and can. It passes those savings onto its customers to further invest in their businesses.

Similarly, Moxie is directly involved in acquiring, converting, and retaining customer demand. Moxie runs the entire marketing function for these businesses, from top of funnel down to lead management. They can amortize their learnings and strategies across multiple medspas, generating better results than a part-time local marketer could alone. 

Moxie is a pioneer of this model and executing it well. It requires deep product and operational expertise. However, as the benefit of this more full-stack approach becomes apparent, it will become more common among the winners in each vertical. 

Own the businesses

There’s another evolution of vertical software that I think is fascinating but is different enough from the categories above that it deserves a separate mention. The idea is that rather than sell software and services to businesses, you actually own the businesses and operate them more effectively with proprietary tools. 

This is best articulated by Slow Ventures’ excellent “growth buyouts” thesis, which is worth a read. The idea is that the ideal way to monetize certain verticals is to build vertical software that gives you an edge in that market, buy an operating company, apply that product to the company to help it grow, and then repeat. Tidemark’s Michael Tan has a great take on this as well, “Are Tech-Enabled Vertical Roll-Ups the Future or the Past?”.

For example, Metropolis, a parking software provider, raised $1.7B to acquire a national parking lot operator. The idea is that it could get a greater return by having free rein to apply its technology to those physical assets than by selling it as software. Others are trying this with smaller transactions and more service-based verticals, such as Splash in pool servicing and OLarry in accounting. 

Conclusion

The most successful startups are founded when there’s some shift – in technology, business models, distribution, or ideally all – that allows them to quickly displace incumbents and capture a greater share of a growing market. Vertical software has undergone several such shifts over the past decades, with new models emerging that solve more problems in each vertical and expand its TAM. We’re in the early stages of another such shift, and likely one of the largest expansions of TAM yet, as the creative use of new models helps grow and capture more upside of these verticals than ever before.

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: mb@matrix.vc

It’s a tweet I quote often. On the one hand, financial services is one of the largest, oldest, most efficient, and most competitive markets. Incumbents have immense competitive advantages. There is a lot of money left on the table. Financial services has the largest gross profit pool of any sector, almost 10x the entire software industry:

On the other, fintechs are some of the largest and fastest-growing companies. 

How do you reconcile the two realities? More importantly, why do so many fintech founders run headlong into a brick wall attempting to win those profits? It’s because they mistakenly believe they’re selling a product or service, when in fact they’re selling money. Understanding this distinction is the difference between success and failure.

Subscribe now

It’s easy to make something people want… when you’re selling money

YC knows a thing or two about building valuable companies. They’ve funded 5,000 companies worth >$600 billion, including 900+ worth >$100M and 90+ worth >$1 billion.

YC’s motto is “make something people want”. They print it on posters and t-shirts, and mention it three times on their homepage:

Most (non-fintech) startups fail because they build something that no one wants (market risk). Others fail because even though people want what they’re building, they can’t build it (technical risk). So, working backwards from “something people want” is great advice for most startups.  

However, “make something people want” is incomplete at best and dangerous at worst for fintechs, because much of financial services involves selling money (or access to it). If most other startups need to think about market risk and/or technical risk, most fintech startups need to think about “risk risk”. Payments infrastructure allows for money to be sent and received. Banking for it to be stored. Lending for it to be borrowed. Investing for it to grow. Insurance for it to be protected. All of these activities involve real downside risk unique to financial services: bad actors can process fraudulent payments, borrowers can not repay loans, and policyholders can make more and greater insurance claims than expected. There are innumerable ways to lose money.

Traditional financial services is so big and profitable because it’s good at selling money… but more importantly, at getting it back. Selling money is easy. Getting paid back is difficult. It’s about understanding and pricing risk.

Many fintechs mistakenly just focus on the “selling” part. They often have clever approaches that make it easier to sell money, but don’t much improve the likelihood of it getting paid back. 

So, the motto for fintechs isn’t “Make something people want”. It’s not even “Get good at selling money” or “build a great product” or “be great at user acquisition”. All of those are necessary but not sufficient. The wordy but correct motto for fintechs should be “Price and shape risk that others can’t or won’t”.

• “Price risk” means deciding which customers to serve and what terms to offer them. Terms vary by product, but simple examples include the interest rate and duration in lending or the required reserves and settlement timing in payments.

• “Shape risk” is what you do after you’ve sold a product to increase the odds of getting paid back. This also varies widely, but can include a bank providing tools or education to help its business customers grow and expand, or a lender sitting in a funds flow, such as a payment processor or payroll provider, to ensure they’re paid back first.

“That others can’t or won’t” is the critical part of the motto. That’s because traditional financial institutions are pretty good at pricing and shaping risk for most customers and most products. They often excel in acquiring the most attractive customers (high value, low risk) and then pricing and shaping risk to sell them financial products profitably. The shortcomings of traditional financial service product surfaces (mobile apps, websites, customer support) are a big red herring, as those often have minimal bearing on what matters: evaluating the risk needed to sell money.

This is the result of significant advantages in brand trust and marketing spend, historical data and processes to underwrite, and more. So the deck is heavily stacked against challenger fintechs.  The way to win this brutal game of “selling money” is not simply to take more risk, but to take different and smarter risk.

Subscribe now

How to lose money selling money

To understand how and why fintechs misunderstand risk, let’s start with the classic risk versus return chart. The more risk you take, the more return you get. For example, across asset classes:

The same trade-off applies to company strategy in fintech, although with a slightly different curve:

The gray circle in the curve’s middle, where you get ever-greater returns for relatively smaller amounts of risk, is dominated by the traditional financial institutions described in the tweet above. That’s the massive, ruthlessly competitive, highly profitable space that fintechs try to break into.

Fintechs that misunderstand or under-appreciate risk fall on three places along the curve, which I call “Gun-shy”, “So what?”, and “YOLO”:

If you remember the motto – “Price and shape risk that others can’t or won’t” – you’ll find that each of these company personas fails to do it in a different way.

(1) “Gun-shy”: They may realize they’re in the risk business, but don’t take enough risk to complete. This is an uncommon profile, but it does happen. To protect against risk, they have very stringent onboarding, or strict underwriting, or narrow risk profiles they’ll accept, or price products above market to compensate for risk. These all lead to a slow demise because the financial sector is so competitive. They won’t lose any money, but they also won’t have enough customers to make much of it, so few will survive.

(2) “So what?”: They realize they’re in the risk business, and take the bare minimum of risk, but are insufficiently differentiated, so they’re indistinguishable from the broader crowded market.  Fintechs who don’t understand this but are good at acquisition end up becoming effectively lead gen or referral partners. They’re thin wrappers around traditional financial institutions that ultimately control the UX and economics. Often though not always, these companies appear as thin wrappers around a more competitive company or product, such as the legion of neobanks and card issuers in the late 2010s or the ISOs in the generation before. These businesses may survive, but few will achieve venture scale.

(3) “YOLO”: Whether or not they realize they’re in the risk business, they act as if they’re not. The end of these businesses is best summed by the Hemingway quote: “How did you go bankrupt? Slowly, then quickly.” If you recognize you’re in a risk business, but deliberately loosen controls like onboarding, KYC/B, or underwriting, or deliberately underprice, you can grow quickly for a time, hoping that growth covers all sins and eventually you can “fix” it.  It’s easy to grow when you drop prices, play fast and loose with KYC/B, etc. Alternatively, you can just be blind to the risks in the market, grow nicely, and one day realize you’ve been hit by fatal risks.

Notice what’s not mentioned in any of the descriptions above: acquisition strategy and its effectiveness, product quality, etc. None of those matter without an insight into or differentiated approach to risk. As we’ll see below, risk insights often express themselves in marketing or product decisions, but it’s all downstream of that insight or differentiated approach. 

Subscribe now

How to actually make money selling money

So how do you make money selling money? You need to care about and build against your risk. To make a lot of money selling money, especially when you’re competing against the world’s “smartest and most ruthless people in a 500 year old industry”, you need to have a novel insight into risk and build a product and company around it. 

What does that mean for fintechs? They must have an overarching insight into pricing and shaping risk that others can’t or won’t, and orient most of all of the company (product, marketing, etc) around it. It comes back to the motto for fintechs mentioned earlier:  “Price and shape risk that others can’t or won’t”. 

This can mean many different things. You can serve customers who seem high risk, but only you can determine that they’re actually not. Or you can serve customers that actually are high risk, but that you can manage and reduce that risk better than others can. Let’s look at a few examples.

BREX

Before Brex, it was difficult for startups to open business bank accounts. This was especially difficult when the startup’s founders weren’t US citizens. While “brand new business plus non-US citizen” may seem like a risky category to traditional financial institutions, in fact these companies were actually lower risk, especially if they had been vetted and funded by accelerators and VCs. Not only were they lower risk than traditional SMBs, but they had higher upside because successful startups go on to raise millions in funding. This gap between perceived and actual risk was recognized and exploited by Brex to get started. 

EMBEDDED FINTECH

Another example here is the entire category of embedded financial products, like payments (Rainforest) and lending (Kanmon). I’ve written extensively about the embedded strategy before, but the summary is that embedded financial services can draft off the software platforms they’re embedded into, using their positive selection of users plus existing platform data to acquire and underwrite customers better and cheaper than a traditional financial institution. They can also build vertical or even platform-specific risk models to better price risk.

AFTERPAY

Installment payments, point-of-sale financing, and private-label credit cards had existed for decades before BNPL. Afterpay’s powerful insight was combining the best of several trends (ecommerce adoption, limited traditional credit use among younger consumers, etc) with a deliberate choice of customer segments (fashion and beauty) that reinforced its competitiveness in a space that was somewhere between excruciatingly competitive (consumer credit) and minimal (consumer credit for 18-36 year olds). By focusing on fashion and beauty – where buyers and sellers naturally had a high frequency of lower-value transactions – you could be more flexible in assessing and pricing risk (because the downside the low, especially if 25% was paid upfront) and have leverage in shaping consumer outcomes because you needed to be in good standing to continue using the network as a consumer.

Afterpay is a good example of a series of product choices that may seem odd from the outside, but are deliberate and powerful when viewed through the lens of the risk insight. Risk insights and secrets are, well, secrets. Some publicize them, but most successful companies don’t. And it can be even harder to discern what they are when they’re expressed in non-obvious ways.

I’ve found the deeper and more powerful a risk insight is, the more confusing its manifestations in product and marketing can initially seem. This can be an “ugly” product. Seemingly weird ICP or product messaging. Features that should be there but aren’t, or that seemingly shouldn’t be but are. That’s because the company isn’t oriented around a traditional and observable approach to company building, but around an insight into risk that manifests in non-obvious ways. 

This non-obviousness is what makes it so dangerous to copycat and cargo cult successful fintechs, without understanding their risk insight and the series of interlocking product and marketing choices that amplify it. For example, Brex had a genuine insight and arbitrage (seem high risk, actually low risk and high value) in banking, but the multitude of other neobanks that started around the same time did not.

Simply focusing on a specific affinity group or customer segment is insufficient if that selection doesn’t make you better off in risk in some way. The same applies for the multitude of companies that tried to do BNPL for different sectors. They copied what they could see superficially of Afterpay’s company and strategy, without understanding the foundational importance of customer selection and risk orientation.

Startups are an exhilarating but brutal game. Fintech founders play that game on hard mode because they’re competing against large, ruthless, and efficient incumbents who generally know what they’re doing and have been playing the game for decades. To win any game, you need to know the rules and where you have an edge. Successful companies require a million things to go right, a lot of luck, and a ton of hard work, but in fintech, they also require a deliberate appreciation of and insight into risk.

There’s a famous saying from the 2000s: "Advertising is the business model of the Internet.” In a few years, we’ll look back and say that payments is the business model of software — and that Rainforest powered much of those software-embedded payments.

Successful B2B software is increasingly all-in-one and vertical-specific. I call these companies “vertical ERPs.” Classic examples include Shopify for e-commerce stores and Mindbody for fitness studios.

Thousands of fast-growing vertical software companies today serve every niche—law and architecture firms, pool cleaners, pet groomers, churches, non-profits, and more. These platforms’ products are as unique as the verticals they serve, but they all share one thing: they enable their businesses to accept payments.

These platforms, otherwise unknown outside their niche, process hundreds of millions, if not billions, in payments on behalf of their customers. So it’s unsurprising that embedded payments are a critical monetization strategy, often accounting for >50% of revenue.

But the bar for execution is high. Platforms expect a seamless, flexible, and beautiful payment experience. They want all the benefits of deeply embedded payments without headcount, expertise, and costs. This requires a combination of deep payments expertise with an understanding of SaaS products, platform growth, and product risk.

This is where Rainforest and its founder Joshua Silver come in. He co-founded a healthcare software and payments company that was acquired for over $450M and then started advising other platforms on their payments. From that position, he realized that existing providers all failed platforms in one way or another. So he decided to build the payments platform he always wished he had: Rainforest.

Everything Rainforest does—from its infrastructure choices (direct to banking partners) to its GTM motion (very focused on software platforms) to pricing (transparent and platform-friendly) to its post-sales success motion (hands-on and outcome-oriented)—is deeply intentional.

It’s clearly been designed by someone who has bought and implemented payments dozens of times, which Joshua has. That thoughtfulness appears in the impressive traction and customer satisfaction that Rainforest has earned in just a few months.

I’m excited to partner with Joshua and the rest of the Rainforest team as they help shift trillions of payments online and into software platforms.

Learn more on Techcrunch or rainforestpay.com

“Real-time payments” (RTP)1 is a simple term for a complex topic. The “what” is straightforward: RTP allow users to send and receive funds in seconds, any time of day and day of the year. How it works and why it’s a relatively recent phenomenon is another story. 

There are 70+ real-time payment networks (RTPN) globally. Most launched in the last decade. Collectively they’ve reached impressive scale (266 billion transactions in 2023) and sustained impressive growth (42% y/y). This note explains how RTP work, what catalyzed their recent growth, and why some RTPN are more successful than others.

A brief intro to payment schemes and networks

To understand RTP, it helps to understand why most payments weren’t real-time. That requires a quick recap of payment schemes and networks— terms often used interchangeably but with subtle and important differences.

A payment scheme is a bundle of technology, rules, and regulations that moves money. Payment schemes have limited value in isolation. That’s because payments have network effects. The more buyers and sellers use a payment method, the more valuable it becomes. Payment schemes – which can be run by for-profit companies like Visa, government entities like central banks, or hybrids – often rely on third-party intermediaries like banks.

A payment network combines a payment scheme with the intermediaries (often banks and other financial institutions) required to onboard and support end users (i.e., buyers and sellers). Take card payments, for example. Visa operates a card payment scheme that supports the Visa network. Buyers and sellers rarely interact directly with Visa; instead, the bank interacts with the scheme on their behalf.

The important takeaway is that payments are more than tech, rules, and regulations (i.e., the scheme) that move money, but require intermediaries to connect end users to and through the scheme (i.e., the network). 

Non-real-time payments: efficient but slow

Most payment networks started in the pre-digital era of the mid-20th century. Everything from the first card networks to the check system and equivalents were paper-based, human-powered, and manual.

Early payment networks used batch processing to remain efficient. Rather than processing payments individually, networks broke them into tasks, let the tasks accumulate at various steps, and moved them through the steps in batches. 

Imagine a postal system. You drop a letter in a mailbox, which is picked up every few hours. At pickup, all mail goes to a central post office, accumulating until it’s sorted. Then, once daily, the mail truck delivers the sorted mail.

This is inefficient for individual letters. For example, in the diagram, the yellow envelope is dropped off shortly after the blue envelope. But it’s delivered much later— it doesn’t even make it onto the truck on the same day. However, this batch system is much more efficient for the average and majority of letters and makes the system’s cost manageable.

In payments, the processes needed to keep the system efficient, safe, and trustworthy coalesced roughly around the ones many would recognize today, in initiation, authorization, processing and clearing, and settlement:

Even after batch processing wasn’t technically necessary, the networks found it difficult to change because they had built so much of their businesses and processes around it (managing fraud and risk, staffing and customer support, liquidity, etc).

This led to some interesting historical quirks. For example, even into the 1990s, the Federal Reserve paid $35 million+ annually for a fleet of 47 airplanes to fly physical checks nationwide each night.

To recap, the 20th-century payment networks (card, ACH, wire, etc.) relied on intermediaries for scale and batch processing for efficiency at the expense of speed. Digital tech was necessary but not sufficient for RTP. Schemes moved as fast as the networks allowed, and the networks were often locked into the assumptions of batch processing.

Real-time payments: efficient and fast

RTP, then, are a scheme-plus-network purpose-built for real-time (i.e., parallel) processing rather than batch processing. Payments still follow the same broad auth, clearing, and settlement steps—enabled by the scheme and, critically, supported by the network.

Once new technology enabled it, several factors catalyzed real-time payment networks (RTPN). One is consumer demand. When consumers began to see their money 24/7 on the internet, they began demanding to be able to move it 24/7 too.

Governments were another big catalyst. Especially in less developed economies like Brazil and India, governments promoted RTPN to help citizens access financial services for the first time. RTPN and increasing digitization had the added benefit of making more transactions visible to and taxable by governments.

Today there are 70+ RTPN. Some countries have one; some have multiple. Some are decades old, but most launched in the last few years. 

The global growth is impressive – 266 billion transactions and 42% y/y growth in 2023. However, 80% of real-time transactions occur in a handful of countries:

Two interesting points jump out from the chart. First, 4 of 6 networks are less than a decade old. Second and related, 5 of 6 networks were created by governments, which also mandated private financial institutions' adoption.

This explains why RTPN took so long to launch but saw rapid adoption once launched. The bottleneck wasn’t technology or demand but the coordination to jumpstart a network. In most cases, only a government mandate could provide such a catalyst. Regions with a market-driven approach or a government-sponsored but not mandated approach typically have lower adoption.

The government-mandated approach to RTPN is a double-edged sword: it allows rapid domestic adoption but focuses the networks domestically, unlike the more international focus of market-driven networks, such as in card payments. The next few years will see much interesting work stitching together domestic RTPN to support cross-border RTP.

A few last thoughts on the implications of RTPN: 

First, tech wasn’t sufficient for RTPN, but many networks leverage their modern tech to enable powerful and/or novel features not found in traditional payment networks, such as Pix’s multiple portable aliases or RTP’s messaging. These open new areas for startups to innovate in.

Second, the market clearly prefers fast payments. So many non-real-time networks have launched real-time features to compete, like Visa’s push-to-card or SEPA Instant. Speed will go from a differentiator to a commodity—something consumers expect for low or no cost. 

RTP is an exciting global phenomenon for consumers, fintechs, and financial institutions alike. It’s also an interesting lesson in how technology enables new behaviors, shifts consumer expectations, and forces areas like financial services to respond to those shifts. 

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: mb@matrix.vc

A growing number of fintechs rely on stars. Not movie stars or sports stars. Thanks to the increasing popularity of open source in fintech, these are Github Stars. It’s worth understanding why this is happening and what it means for the industry. But before getting to fintech, let’s recap the open source model and the lessons from the last several decades.

The closed-source model is more typical in software. It means the company’s source code is proprietary and not shared publicly. It’s often monetized directly through licenses or subscriptions. 

The open-source model takes the opposite approach: the source code is publicly available. Anyone can see, fork, modify, and run it on their own. There may be some limits on how the code can be used, but generally, anyone is free to do what they want with it.

While some open-source projects are explicitly not-for-profit, others have built large and successful for-profit companies around an open-source product. In this case, a company makes the core product (or at least its source code) freely available, then monetizes products and services adjacent to it, such as:

• Cloud hosting: a hosted version of the software through a traditional SaaS model for companies that don’t want to deal with setting up and maintaining the source code themselves.

• Enterprise management: a non-open source enterprise offering with additional management features and capabilities.

• Services & support: services relevant to a company that is implementing the software, such as implementation support and ongoing support.

For example, the popular open-source company MongoDB allows anyone to copy, customize, and use their code for free. But this means they’d have to set up their own hosting, figure out how best to implement it, and continue to maintain it. On the other hand, they could pay MongoDB to use Atlas, their fully managed cloud service. And in fact, 64 of Fortune 100 companies, along with 40,000+ other companies prefer to do this. As of mid-2023, they had more than 1,600 companies paying more than $100,000 annually for this otherwise “free” product.

Why even bother with open source? It’s certainly not a fit for every product and category. But in certain cases, it offers significant advantages:

• distribution and adoption: especially in crowded markets, it can increase adoption and usage faster than a closed-source model. Developers will play with and use the open-source version, and some will eventually pay some other way (more on this below). This is not that dissimilar from the freemium playbook.

• transparency and trust: since anyone can see the code, anyone can understand how it works and ensure it does nothing nefarious. Similarly, since the code can be self-hosted, users can feel safe knowing that even if the company goes out of business, they can continue using the software.

So open source is a powerful strategy, but it’s not equally powerful in all categories. The history of open source offers many lessons on where and how it’s best applied.

Where open source does and doesn’t work

The modern computing stack (app, platform, infra) contains multiple examples of open- and closed-source products in many areas (such as web browsers, operating systems, web servers, etc.).

While the open/closed source dichotomy dates to the early days of computing in the 1950s and 1960s, its modern and more commercial form arose in the 1980s and hit its stride in the 1990s. While companies like Microsoft popularized closed-source versions of products like operating systems, databases, web servers, and programming languages, others like Red Hat, MySQL, Apache, and Sun Microsystems built businesses around open-source products in each of those categories.

Billions of users today use open and closed-source products, whether they know it or not. This includes products like web browsers (Firefox is open source, Safari is closed, Chrome is a mix) and mobile operating systems (Android is open source, iOS is closed), as well as entire companies built on the open-source model.

So, after decades of investment and development, the market has given some indications of where open source works well (or not). To understand those implications, you need the concept of a category’s “connectedness”, or how reliant a product is on third-party commercial arrangements to deliver value. A good rule of thumb here is: if a product could run entirely within a computer or company and still be valuable without significant reliance on third parties to deliver value, then it has low connectedness. The more it relies on third parties to deliver value, the more connected it is.

For example, a database has a very low degree of connectedness, because it can be run inside a company. Typically all the data is generated, read, and modified from within the company itself. On the other hand, a communications orchestration platform, such as Twilio, has high connectedness. It relies on a patchwork of global telecom deals to function and deliver value. Other categories are somewhere in the middle, where they may or may not benefit from significant connectedness.

Many (but not all) application categories have high connectedness, while most (but not all) platforms and infra categories have low connectedness.

Getting back to open source, the last few decades have shown that categories with less connectedness are more likely to be successful with open source. That doesn’t mean that categories with low connectedness will only be successful with open source, or that open source will necessarily be the most successful in those categories. Instead, it means that if open source is likely to be successful anywhere, it will be in those categories.

That’s because the connectedness requires a more concerted sales, marketing, growth, and/or business development effort than makes sense to organize around an open-source project. For example, for a connected service like Twilio to be valuable, it requires tons of business development deals with telecom carriers around the world. This highly connected product category is unlikely to be successful without these deals. The deals are a critical part of the product and the product is a critical part of the deals. Twilio’s software has minimal value without the deals, and the deals have minimal value without the software to orchestrate them. So a standalone open-source version of the product is unlikely to be valuable. On the other hand, in less connected product categories, like data systems, the products are more able to stand on their own and so are more likely to have some value as an open-source project from day one.

The financial services stack

The financial services stack is not that dissimilar from the computing stack. It’s an imperfect analogy, but financial services also have things analogous to applications, platforms, and infrastructure. You can think of applications as individual financial products and their user-facing components (e.g., P2P payments, checking accounts, budgeting tools), platforms as the foundation on which applications are built (e.g., banking-as-a-service providers, payment networks, account aggregators), and infrastructure as the more generalizable resources that enable the platforms (e.g., payment rails, risk engines, billing engines, etc).

Where to find open source in financial services

Like in the computing stack, financial product categories have varying degrees of connectedness. If anything, financial products are generally more connected than not because financial services often require interacting with third parties to deliver value. A P2P payment app isn’t valuable if you’re the only user on it. A banking-as-a-service vendor isn’t valuable if it’s not connected to any sponsor banks. A payment rail isn’t valuable if it has limited on- and off-ramps with other financial systems.

So, the financial services stack is becoming less monolithic, more modular, and more developer-led. That means more open source is popping up across the stack, just like in the computing stack in the 1990s. However, just as in that case, there are likely parts of the stack where open source will be more successful. Thankfully, there are decades of precedent from the developer world to suggest where that will be.

Like in developer tools, the opportunities are heavily weighted towards the less connected infrastructure side. 

It’s unsurprising that many of the recent fintech players adopting open source are typically both infrastructure and less connected. You’ll find examples in risk and rules engines (Ballerine), ledgers and data stores (TigerBeetle), payments orchestration (Hyperswitch), loan management systems (Corefin), and billing engines (Lago).  Understandably, there are fewer instances of the open source strategy further up the stack, but there are some, like Maybe. 

It’s still the early days of software eating financial services. So it’s likely the early days of the open source model in fintech also. Hopefully the framework above helps founders decide whether or not open source is the right fit for their product category. Since it’s still early days, the market and model are changing often. Feedback is welcome on this framework… where does or doesn’t it apply to financial services? What product categories are more or less connected than they first appear? Where is open source really taking root in financial services?

09/2024 update: the full data set behind this post is now available at https://www.verticalsoftware.fyi

The two trends I’m most bullish on are vertical software and embedded fintech.

Businesses of all sizes rely heavily on software increasingly built for a specific vertical. Within verticals, businesses increasingly prefer the convenience of integrated, all-in-one suites over multiple disconnected vendors. These software suites have started embedding financial products to provide more value, monetize at a higher rate, and increase customer retention.

“Vertical software + embedded fintech” is a well-known strategy (I call it “vertical ERP”). Although there are plenty of market maps and Top-10 lists for vertical software and embedded fintech individually, I’ve never seen a data-driven study of how vertical SaaS companies adopt embedded fintech, so here it is. Thank you to Amit Kallakuri for his great help gathering and refining the data.

Defining vertical software and financial products

We started by gathering a list of several hundred vertical software companies. 

What “counted” as vertical software? We included companies that focused on explicit verticals (versus horizontal markets) AND whose product suite was, or at least aspired to be, multi-product (versus point solutions). 

One way to consider qualifying companies is to look at the chart below. Companies in the green area were included. Companies in the yellow were sometimes included (judgment call), and companies in the red were typically excluded.

Practically, the companies in the green had websites that looked like the ones below, with wording like “Everything you need to run your {{business type}}” or “The operating system for {{vertical}}. For example:

Their navigation often had a product dropdown that included a mix of vertical-specific software products (scheduling, CRM, marketing tools, etc.) and financial products. For example:

We reviewed this list of vertical companies and tagged financial products: payments, lending, banking, cards, expenses, accounting, taxes, payroll, and insurance.

We tagged a company as having a product only if offered in an integrated or embedded way. For example, a deep and robust Quickbooks integration didn’t count as accounting, whereas a natively integrated P&L, cash flow statement, etc. within the product itself did. Most cases were clear, but some judgment was required in others.

We also categorized each company into ten verticals: restaurants / retail, construction, real estate, logistics / supply chain, education, government / non-profit, professional / field services, hospitality / travel, beauty / wellness / fitness, and healthcare.

That gave us a database that looked like this:

An updated version of this data set has been published at:

https://www.verticalsoftware.fyi

We then analyzed the data to learn how vertical software companies adopt financial products. An important disclaimer: this data is directionally correct but not perfect. We didn’t cover every vertical SaaS company, and we did our best to assess which products they offered and what vertical they were in.

Here’s what we learned.

How is fintech adopted in vertical software?

Companies had a median of 1 financial product and a mean of 1.9 products.

I was surprised that 11% of companies offered no financial products. I expected some companies to offer none, but 1 out of 10 seemed high, given these were generally successful and scaled vertical software companies, and embedded fintech has been a known strategy for several years.

The number of companies offering only one product also surprised me. I thought the median would be around two or three. More on this below.

83% of companies offered embedded payments, but no other financial product surpassed 25% adoption.

This wasn’t surprising, as embedded payments acceptance, pioneered by Stripe and now improved on by companies like Rainforest, is a well-known strategy in vertical software. Payments is a great way for vertical companies to monetize customers beyond SaaS. All businesses must accept payments, and few love their existing payment provider. Bringing that into software enables powerful follow-on use cases like lending and accounting.

However, it was surprising that no other fintech product broke 25% in adoption. Expenses came close at 23% but still far from payments.

42% of companies offered only payments.

This shouldn’t be too surprising. However, it also helps recast the chart above on the mean and median number of products adopted. If payments are the most logical product to start with, then maybe the payment-only companies are still early in their embedded journey.

If payments are the logical starting point, then it also makes sense that the overwhelming majority of companies with two or more fintech products have payments as one of those products.

The most common product pairs were “payments + expenses,” “payments + accounting,” and “payments + payroll.”

I was surprised at the relatively low coincidence of otherwise seemingly complementary products, like cards and expenses or accounting and taxes.

We found up to 3x differences in average product adoption across verticals.

I was surprised by the size of these differences and the industries that were furthest apart. The industries I expected to adopt less tech had higher average embedded fintech adoption (e.g., construction and logistics). The ones I thought would have above-average adoption had average or lower fintech adoption (e.g., professional services and hospitality).

Non-payments product adoption varied significantly (4-10x+) across verticals.

The presence of variation across verticals shouldn’t be surprising, but the size of the variations surprised me. For example, more than 60% of construction companies offered embedded/integrated accounting, while 0% of the education, beauty, wellness, and fitness companies did.

While there’s still room to expand the adoption of all products in all verticals, this highlights the importance of knowing a vertical deeply before building or investing in it. Even if you’re convinced that a certain vertical needs a certain product, there are many nuances to building one product in one vertical versus another.

Takeaways for founders and investors

The right level of resolution for takeaways is not in the specific numbers (e.g., 20% lending adoption in hospitality versus 29% in restaurants and retail) but in the major differences between products and verticals. Here are my takeaways:

Payments is the beachhead of vertical software’s fintech strategy.

Every business needs payments. Handling payments also give the software vendor access to critical data and downstream workflows, including the ability to fund banking, card, and payroll products, underwrite lending products, and populate products like accounting and taxes.

Non-payments adoption (lending, banking, etc.) is still in its infancy. Nearly every company we looked at uses nearly every financial product described here, although most do so directly rather than through the software vendor—for now.

For example, none of the verticals had >50% adoption of embedded payroll, although ~100% of the companies use some payroll solution. This is more a question of time and right to win/embed than anything else. More on this below.

When you compare verticals, there’s significant variance in which financial products are adopted.

If you’re building for a vertical, don’t blindly copy the embedded strategy of another vertical. Think about your specific vertical needs. Similarly, if you’re building an embedded fintech solution, carefully pick your vertical ICP(s). For example, it may be easier to sell embedded lending to professional and field services (15% adoption) than healthcare (0% adoption).

When you see low adoption of a product in a vertical, consider whether the product isn’t suited for the vertical or there’s an opportunity for growth.

Low adoption of a given product in a particular vertical isn’t good or bad. Most companies in all verticals use most of the fintech products listed, but not in an embedded form yet.

So the important question is: How much of that is addressable via embedding, and over how much time? How you approach the problem will determine how you look at it. If you’re a vertical software company, you must understand the maximum embeddability of the different products (such as in the construction below on the left). If you’re an embedded fintech founder, you must understand the embeddability of your product across multiple verticals (such as on the right).

Payments adoption shows that a significant attachment rate is possible. While not every embedded product may reach those rates, the real attainable rate is likely higher than what’s shown in the data. The founders who win in each market will be the ones who figure out the real attainable rate for any product or vertical (the white boxes above) and pursue it.

Conclusion

This data makes me even more excited to invest in vertical software and embedded fintech. It shows how early verticals are in adopting and combining embedded fintech. It underscores the importance of going vertical-first in understanding a customer’s needs rather than blindly applying strategies from other verticals.

Between the rapidly growing demand for software from businesses and the swell of vertical software and embedded fintech companies supporting them, this remains a very exciting area to build and invest in. As always, if you’re working on something interesting in this area (or just thinking about it), I’d love to chat with you: mb @ matrix.vc

Matt: Let’s start with you introducing yourself and talking about how you ended up at Toast.

Michel: I'm an immigrant. I grew up in Beirut. I went to school there, then came to the US to study electrical engineering and computer science at MIT. I started my career at McKinsey, and then started a couple of companies in the consumer and fintech world. Those were great experiences, but ultimately like a lot of start-up stories they didn’t pan out. 

I then went to work at State Street, one of the oldest and largest banks in the US. I had a variety of roles, but the common thread was turning the business into a platform. Then towards the end of 2022 I started talking with the Toast team to join and lead the fintech organization. After meeting much of the team and founders in the interview process, it was just clear that it was a great fit. I always admired what they had built and I believed I could make a difference at this stage of growth.

Matt: Awesome. And before we go deeper, can you give the elevator pitch on Toast?

Michel: The simplest way to think about Toast is as a cloud-based, all-in-one digital platform for restaurants. Fundamentally Toast helps restaurants run better, grow their brand, and manage their teams and back office. We started with the point-of-sale (POS) that helped restaurants take payments.

Over time that’s expanded to not just in-person, but also digital channels. We’ve expanded into nearly every area of running a restaurant including guest-facing surfaces - for example we help restaurants attract guests, make reservations, and manage guest relationships and loyalty.

We also help power the back of the house: everything from products for managing your team, like scheduling and payroll, to investment management, access to capital, and more. I like to think of Toast as concentric circles starting with the POS, and over time, we added ways where we can actually help our customers really grow and thrive.

Matt: Great. So tell me about your current role and Toast and what you focus on?

Michel: I’m part of the product organization at Toast. We have a GM structure, and I’m the GM of fintech. Fintech means different things to different people, but for Toast it’s four things.

First, it’s the payments engine that helps our merchants take all sorts of payments. 

Second, it’s lending and embedded finance. We have a fast growing lending platform, and we’re starting to embed other financial products as well. Think providing access to bank accounts and the like to our customers. 

Third, we have team management. That’s primarily scheduling and payroll and team management. 

And fourth, suppliers and accounting. That's helping customers with things like accounts payable automation, balancing their books, getting insights from their COGS, paying their suppliers, managing inventory, etc.

Matt: That’s very clear. It’s a great way of thinking about all the things you can do when you focus on a specific vertical like restaurants. It seems like Toast has been very intentional about expanding those circles over time. What was that journey like expanding from point of sale? How do you start layering on additional products, deciding what to focus on?

Michel: Let me go back in history. This will be a little bit of a guide to how Toast makes decisions. Toast actually didn’t start as a POS company. It started as a mobile payments company. The founders realized this was really hard to turn into a successful business, so they went back and talked to their customers. They quickly recognized common needs around POS specifically, with opportunity for reinvention there.

At the time, tablets were still a relatively new thing. So a cloud-based tablet solution made a ton of sense. And this thread of “where do your customers need the most help?” is how they went from mobile payments to where we are today. 

They made 3 decisions early on that were incredibly consequential – but at the time these weren’t well understood or accepted things.

First, they focused on restaurants. This was unique because at the time the generally accepted knowledge was that the future was horizontal solutions. You had the McKinseys and BCGs always talking about horizontal solutions. Toast made a very explicit decision to be very vertically integrated, which was not common at the time. Now everyone talks about the benefits of being vertically integrated.

Second, they had a direct, on-the-ground, differentiated go-to-market function. This was the belief that brick and mortar and omnichannel were key. It went against the generally accepted wisdom at the time that everything was moving online.

The third thing was a business model decision: requiring payments as a part of every deal with restaurants. This enabled both SaaS and payments monetization. Now that’s a more accepted strategy, but at the time many people thought SaaS fees were enough to build a big enough business. 

Those three decisions were customer-led and instrumental to where we are today. The rest of it is really as simple as talking to customers and listening when they say “Oh gee, I wish you could help me with this.”

Matt: It's funny how the default or accepted strategy changes so much over time. Going back to the first insight of focusing on restaurants… it’s still a big category. There are many different kinds. Single location, multi-location, QSR versus sit down, different geographies, etc.. How do you think about prioritizing where you start pushing out those concentric circles? 

Michel: It's a really good question. At Toast we're very customer-led, in the sense that we listen a lot to our customers, identify what their pain points are. Now the customers aren’t very good at telling you exactly what they want, but they'll guide you. They’ll say, “This is a big problem area.” 

The second question we ask ourselves is, “Can we build a 10x product?” Do we really have a differentiator? For pretty much every problem our customers deal with, there is a solution out there. But can we build a 10x solution? Do we have an advantage?

For example, one big thing just because we're talking about fintech, is risk-based products. We have unique vantage points because of the data on our platform. We actually know our customers very well, probably better than anyone else. 

The third is, is this a big source of value for our customers first? If we help them solve this, does it really make our customers more successful? Then maybe fourth is, and maybe this is related to the 10x-ing, do we have a right to win?

We could bet it's a big problem. It's valuable for our customers. We think we can 10x it. And by the way, do we have a right to win in that market? And then at the end, you put some numbers together and you say, “How much effort is it going to take? What is the outcome both for our customers and for ourselves?” And that's roughly speaking how we think about it. 

Matt: That's a great way to go about it. Obviously the bundling approach, the concentric circles, is a powerful one for you and your customers if done well. But it can go wrong if you say, we have this captive audience, but we're going to bundling a bunch of products and force them on the customers, and they're going to take it because they're buying the suite from us, and it doesn't need to be as competitive as point solutions, for example.

So how do you think about keeping the quality bar high on your products within that bundle while having that MVP mentality? And how does leveraging your existing, risk-based advantages that you have as you sit on top of all the business data factor in? You have this very captive audience who have, I would imagine, a great affinity for Toast, but you also want to continue to grow your product in this area over time.

Michel: It's a really good question. People will say, “You have this captive audience,” but there are a few things that get missed in this thinking. 

The first thing is: how much value can you deliver to a customer and how much will they ultimately pay you? You can put a number on it, let’s say in the tens of thousands of dollars. As noted on our last earnings call, it was on average around $12,000 for Toast. Let's say you could increase the ARPU a lot more than that in some cases, but generally that’s the zone. On average, we're not going to make $300,000 from one customer. By definition, there are constraints of the business.

I always like to compare it to a store with limited shelf space. I say this because the customer's attention span or their patience with Toast as we try to do more is limited. You can’t pitch them 20 things. You can pitch them a handful of things. So what are the handful of things? What we then do from a product development and commercialization perspective, we're fairly disciplined about it from an alpha, beta, and then what we GA as a product.

That's what we really test for. There's the four or five things I went through: Do we have 10x the value prop? Is it valuable for our customers? Do we think we have a right to win? And does it also work for us as well?

We're pretty quick at iterating through this. For example, we’re piloting a high-yield bank account product for customers. We built it in about 7 or 8 weeks. At the end of the pilot, if we think it hits all the metrics, we'll decide to GA it, or we may just say this is not actually going to work. 

Matt: That's very helpful. That leads to the next question, which is when you have this portfolio of products, obviously, point of sale and payments is the core of your concentric circles. How do you think about the value or the job to be done to you as the platform? One of them or a handful of them is the initial hook that brings the customer in. Other ones are more about stickiness. Other ones are more about revenue and expansion. Do they all have that kind of objective? Or how do you think about the jobs to be done of your products and the product portfolio when there are so many in there?

Michel: We've recently reorganized our products. We have way too many SKUs for our customers to handle separately. So we reorganized how we think about our products in suites. We have 6 suites right now. 

The first one is the POS and restaurant operations. Second is digital storefront, basically in person versus digital. Third is marketing, and the job to be done is how do you market and attract your guests. Fourth is payroll, hire, onboard, and pay your employees. Fifth is manage your team. Sixth is manage your suppliers and accounting. What's not on there as well is some of our embedded finance products, which gets me then to our go-to-market motion. And there are a couple of things that are in the works.

We have three motions when approaching our customers. The first one is a land motion, the initial sale. What happens next depends on which segment the customers fits in: are they full service over $2,000,000 of annual sales? Are they a small diner, QSR, a coffee shop? The packages that we optimize for every sale are a little bit different.

The second motion is the expand motion, which means they’re onboarded onto Toast, they're happy with our products, so what are the follow-ons that we can go in with and help them. 

The third motion is a product-led motion. When I think about embedded finance, a lot of what we do in embedded finance is mostly product-led at this point. 

Those are the three motions. We try to optimize everything because you can't sell everything to everyone. We spent a lot of time thinking about that go-to-market motion and how to optimize each one of the land, expand or product-led growth. 

Matt: That makes sense. Talking about these embedded products, it brings me back to something you mentioned before, which is the benefit of Toast sitting on top of all these different products that a business uses to run on.  So how do you think about risk, how do you think about using that data? And maybe give some specific examples where that's been a competitive advantage for you in building new products. Specifically that overlap of risk and product and go to market, which is very unique in such a vertically integrated product like Toast. 

Michel: Yeah it is. There's a couple of other things too. We haven't really captured the benefits of all of this, but let me give you some themes I think a lot about.

We talked about risk and understanding the risk, of understanding our customers and therefore being able to help price risk. I think that’s a massive advantage. It's not just a massive advantage because a particular customer processes payments on our platform, it's because there's a network of other customers that look and feel exactly like them. When we train our models, we're able to train them on a big cohort that is almost self-reinforcing because you're the only one that has this data.

Another theme I think a lot about is faster access to money. We know what the payments flow is. We know what the lending flow is. And increasingly we're going to know what the COGS are, what the payroll is. You don't have to squint very much to say that we’ll have line of sight into something like 70 or 80% of the cash flow of a restaurant.

How do you create a better product built for restaurants that combines all of those things? And it creates some real opportunities. You could do what banks do today. For example, if a bank knows money's coming into their systems, but the money has not yet settled, do they give their customers access to their money before the funds are good? Yes, they do, because it's in the system. They just haven't settled. And you could see very similar opportunities being created for Toast and across the entire ecosystem. 

There's also a lot of talk around AI. A simple thing for us to consider is, how do you use AI to help a customer run their business? So right now, if you and I were to do it, we'd look at it in a very systematic way. But you could just train an AI on an entire cohort.

Just riffing here, as an example, but at some point it would basically suggest something like, “You have a pretty high balance of gift cards. And by the way, Wednesday is a slow day for you. Why don't you run a promotion to get those people who have gift cards and run some form of promotion, like 20% off? You have the capacity to serve them, and it just really works out for you.”

There's so much opportunity to really help operators just run better. And we haven't even talked about what we could do for the employees of those restaurants. Just think a little bit about everything that we do for restaurants, eventually maybe we could do for employees too.

Matt: There’s a lot there to talk about. On the AI discussion in particular, I'm curious how you think about that AI across the broader organization. Is it an enabling technology that will improve lending and will improve payroll and improve scheduling, and all these sorts of different things?

Is it more the foundation for a relatively new product or relatively new standalone product or this analysis layer, as you just mentioned? How do you think about where AI is most effective as an enabling technology for a multiproduct company like Toast?

Michel: Simplistically, I'll maybe use words like old AI versus new AI. There is the old AI, which is more machine learning, data science-driven. And we are very advanced users of that. That's what powers really our data science models to enable bank lending on our platform, so that we could predict defaults, business performance, powers a lot of our scheduling, etcetera.

And then there's the new AI. New AI is basically the era of ChatGPT. How do you use generative AI to then create some interfaces that frankly didn't exist before and ask it to do things that you couldn't do before? We don’t do this yet, but you could actually throw all the data that Toast gets out into Gen AI and say, “Hey, build me a P&L.”

There are some companies who do this. And so starting to explore some of those ideas, you could actually ask Gen AI, “Look at the data that Toast gets, and tell me how I can run the restaurant better?”

Matt: That makes sense. We talked about your different product areas.  Each has some kind of financial product component either directly within it or adjacent to it and then some kind of software component as well. Those are typically two different worlds. Building software and building financial products. They're just two different mindsets in a lot of cases, two different ways of building and thinking about products.

And so what have you or what has Toast learned about building high-performing teams that combine these two different types of products across multiple different areas?

Michel: It's a good question, so let me try to break it down. And the core of it is that we focus on the problem to be solved, and we try to solve the problem in its entirety with one team. I say this because what we don't want is, for example, one team to solve the payment side of it and another the software side. You want one team to do both. 

So there are some products that are solutions-oriented. They solve a very clear customer problem, and then there are products within Toast that are more platform-oriented. So let me just give you two examples of those. Our payments rails is a platform. It's a platform that basically powers our billing solution, our payments acceptance, our digital storefront, our POS, etc. So we think of it as a platform. 

Whereas our lending product is a solution. It's all-in-one. It's like we solve a very clear customer problem, which is to provide them really quick access to a loan. And our value prop there is speed, a day or two roughly speaking. That's really what we try to do. And there’s the entire experience that we own end to end, including the entire stack.

And then it comes down to how you organize these. And very often within Toast, we organize them either as a triad – product, design, engineering – or a quad – commercial, product, design, engineering. One of those two models. It really depends how heavy the lift is on the commercial side.

Matt: You mention the commercial piece, and you talked about the MVP of bank accounts. Within say embedded fintech in particular, how do you think about the build versus buy versus partner trade-off there? There's obviously a lot in fintech that you can't do right away. On the other hand, again, Toast has been known to own a lot of the stack themselves very early on.

So how do you broadly think about that set of trade-offs within fintech where there's such a broad surface area and a lot of complexity underneath that surface?

Michel: It's a good question. On build versus buy, I don't think our framework is much different than most companies. It comes down to, is it absolutely core to the experience? Is it differentiating? And are there enough players in the market that we could source multiple proposals from? That's really what it comes down to. There's another overlay that is, does it actually matter?

Take a payfac example: when you're small, let's say you're processing a billion of GPV, 5 bps on a billion of GPV is half a million. Then you think a little bit. What is the team that I need to get that 5 bps down to 1 bps? It's going to cost a whole lot more than a million and then half a million. Five bps on a hundred billion is ten times that number. All of a sudden, putting a team, or for that matter two, on that makes a lot more sense.

So putting aside the core versus differentiating, there's always as well, is this actually worth our time? So, being a payfac makes a lot of sense for us at our level of scale. The other question we always get is, should you go direct? Well, what do you get by going direct? And how much do you save? And that's relative to the size of our business. And maybe the other thing that I'll think about that I'll mention as well, we always think a little bit about resiliency when it comes to partners.

Matt: That makes a lot of sense, particularly at the scale that Toast is today. If you have businesses beginning to rely on a lending product or any financial product, we're talking about storing, moving, or lending money, then resiliency matters.

Michel: Yeah. And when it comes to financial services, we think our differentiator is around the experience, as well as on the product definition. It's less on the ‘could we get funding’ question. We work with banks that actually do that. We are all about the experience, tailoring the products to the customers, and helping them deliver value and assess risk. 

Matt: That makes sense. If you step back and think about either embedded fintech specifically or just fintech generally, what areas are you most excited about? What products do you see a lot of upside in, whether it's inside of Toast or outside of Toast?

Michel: I think we've talked about most of them. It comes down to how to connect the various experiences between all the different products that differentiate the product as a whole.

Right now, if you're a small business, the bank that you typically work with is not building a product specific for restaurants. The loans that you get are not built for restaurants. Right? So bringing that into one ecosystem together where you could literally say to someone, “I'll help you accept payments. I'll give you instant access to money. By the way, I'll lend to you based on that. I'll give you a credit card or a debit card for you to spend based on that. And by the way, I'll enable the people that work for you instant access to their wages.”

Getting that ecosystem right is super powerful. Once you do all that, you can potentially even tell them, “By the way, we have access to a lot of your data. I can actually help you run your business better.” That is really exciting. I think we're barely scratching the surface on what we could do for the hospitality industry.

Matt: You touched on what I think is one of the largest shifts over the last 10 years, that Toast has been a big driver and beneficiary of. If I'm a new restaurant owner 20 years ago, I go to my bank, and I say, can I get a small business loan? Here's the business plan. Can I get funding and a bank account and card processing and all these other services? But today, you start with Toast. I don't have to sit down and talk to someone. Everything I need from day 1 to expansion and beyond is all accessible within Toast.

Michel: The platform, by the way, can measure the heartbeat of the business. That's what's super powerful. The Apple Watch tracks so many things — it turns out one of the biggest benefits of having an Apple Watch is that it can alert you: “Hey! Something is not going right. You should go see a doctor right away.” Not to go all the way on the analogy here because I don't think a lot of it applies. But what's on the Toast platform is really the heartbeat of the business. Really being able to help customers run better, get more of their guests, is what's super powerful.

Matt: I love that heartbeat analogy. And just like, unless you had very specialized hardware in the past, it would have been difficult to track this easily, on an ongoing basis, so today you have this platform in Toast.

It's not just the payment, but it's the lending access. It's not just the lending. It's the scheduling. It's the, it's the full stack. Are your employees doing well? Is your top-of-funnel business doing well? How's your marketing? How's your cash? There's no, there's no more comprehensive view of a business's health in this vertical than I can imagine about that.

I think that’s a great note to end on and we’ve covered a lot of ground. Thanks again Michel for taking the time!

My name is Matt Brown. I’m a partner at Matrix, where I invest in and help early-stage fintech and vertical software startups. Matrix is an early-stage VC that leads pre-seed to Series As from an $800M fund across AI, developer tools and infra, fintech, B2B software, healthcare, and more. If you're building something interesting in fintech or vertical software, I'd love to chat: mb@matrix.vc

And if you’re a vertical software founder, operator, or investor, check out Vertex, The Vertical Software Conference in San Francisco on September 9, 2025.