Undifferentiated heavy lifting in fintech

matrixpartners_gray

One of my favorite company-building quotes comes from Reid Hoffman: “Building a startup is like jumping off a cliff and assembling an airplane on the way down.”

Every startup creates and replaces huge parts of the metaphorical airplane at various points in their journey. However, I’ve noticed a recent trend (and opportunity): many fintechs maintain unnecessarily complex and costly parts of their airplane long after they should’ve replaced or outsourced them.

Take Robinhood as an example. They need to be uniquely good at providing powerful but low-cost trading tools to the average investor. To do this, they need to build as much of the trading and clearing stack as possible, to give them differentiated leverage in trading cost and performance. For that reason, Robinhood invested 2+ years in bringing their clearing infra in-house.

Conversely, while critical, Robinhood’s ledgers for tracking and reconciling trades and money movement do not differentiate their business. They can’t get it wrong, but being the best in the world at it won’t result in a 10x better product. Yet, Robinhood has spent significant resources building, maintaining, and rebuilding its ledgers.

That isn’t to single out Robinhood. Nearly every fintech at scale makes these costly mistakes—reinventing the wheel to solve complex, expensive problems that don’t make the company uniquely better.

I call this set of problems undifferentiated heavy lifting.

Why “undifferentiated”? Because even if the output is world-class, it won’t matter much to the business. It’s necessary for success but not sufficient for it.

Why “heavy lifting”? Because these are complex technical and operational problems. It’s difficult to build something good enough, much less world-class. And even a world-class solution in these areas wouldn’t provide a competitive advantage significant enough to justify the cost.

Each company thinks it has a special set of circumstances and justifications for doing this internally. These often boil down to a few common themes:

  • they believe it’s a differentiating investment, part of their competitive advantage (it’s often not)
  • they believe that “this is just something a fintech needs to do itself” (wrong)
  • they lack robust options and vendors to outsource this to (bingo!)

And that’s where there’s a big opportunity: a new wave of companies could take these “undifferentiated heavy lifting” problems, abstract the solution away into a service, and sell it to fintechs which can then focus on what actually makes them special.

It’s analogous to the Web 1.0 days, when companies had to maintain their own servers, both because the IT line item validated them as a tech company and because cloud models weren’t yet a viable alternative. After much change in technologies, business models, and organizations, it’s now exceptionally rare for a company to maintain its own physical infrastructure. Managing this is “undifferentiated heavy lifting” for all but the largest or most specialized companies today.

A similar shift is happening for big parts of the fintech stack. Fintechs will recognize it’s neither necessary nor economical to build them internally, and startups will arise to provide these as a service.

A bit more detail on the specific opportunities I see:

Ledgers

Ledgers are a critical part of the tech and financial stack. Fundamentally, they’re databases that contain debits and credits and bake in business-specific assumptions and logic to derive balances and other financial statements. However, they’re also incredibly complex, requiring high uptime and performance with strict security, data integrity, audit, and regulatory requirements. Multiple business processes are built on them, so failures not only degrade UX but can cost significant sums of money.

Rules and decisioning engines

Most “rules engines” start as hard-coded variables for things like onboarding, fraud, credit, etc. As the needs around decisioning and the teams managing it get more complex, these variables quickly spin out into complex, creaky systems that are difficult or impossible to audit, AB test, backtest, or report on. Patchwork rules engines can not only hamper optimization but can easily obscure poor rules that result in significant fraud or credit losses.

Servicing

Servicing is a classic “undifferentiated heavy lifting” area because it’s heavily regulated and operationally intensive, but unique in that it’s user-facing. It also typifies the unique challenges of the space in that you don’t win major points for a world-class experience, but there are significant downsides to getting it wrong.

These are just some opportunities. Many more exist. A good rule of thumb for finding them is to look for an area in a large fintech that has dedicated significant engineering and/or operational headcount to a non-user-facing project. Sometimes these tools, teams, or processes are large enough to justify a code name or project name (such as Uber’s Mastermind). This is a great tip-off that the functionality is distinct enough from the core product that it could be made into a separate service and offered to multiple companies.

If you’re building something that helps with this heavy lifting, then I’d love to hear from you. mb at matrix.vc

This post was originally published here.