On Market Power — Who Reads, Who Writes, Who's SOL

In the first two articles in our seven-part series, we detailed that while APIs are everywhere, the implications are underappreciated, and we looked at the role APIs play in SaaS unit economics.

Today, we look at market dynamics and consider where and how APIs exist and why that is an expression of market power in the quest to control more pieces of the value chain.

Read all seven parts here:

Part 1: APIs are Everywhere — An Intentional Choice: Being API First

Part 2: On APIs and SaaS Unit Economics

Part 3: On Market Power — Who Reads, Who Writes, Who’s SOL

Part 4: A Fork in the Road for Traditional Banks

Part 5: Impacts of BaaS Intermediation on Embedded Finance

Part 6: API-first development: fuel for regulations, Open Banking and Standardization

Part 7: The No-Code/Low-Code Accelerant

A prediction: in the future, there will only be three kinds of companies: those whose APIs are written to, those who write to others’ APIs, and those who are SOL (*simply* out of luck).

If your company is not clearly headed to one of those categories, it’s time to rethink your strategy.

In the startup ecosystem, we already know that this is true. B2B startups consider it a triumph when they sign an integration agreement with a larger SaaS company that has pre-existing agreements with their target customers.  Consumer fintech or e-commerce startups naturally write to the APIs of Plaid, Stripe, Twilio and Intercom as they build their MVPs. In each case, the little startup is a company that writes to others' APIs, and the larger companies have their APIs written to.

The argument we’re going to outline today is that this is not a self-contained dynamic among startups, but rather a new expression of market power that is orthogonal to the traditional frameworks of who gets to set the terms of a contract.

Here, we’ll first walk through a parable to illustrate how existing market power dynamics play out when clean modern APIs from market leaders can serve to strengthen their grip on emerging ecosystems. Then we’ll complicate the story showing how API-quality can create market power in financial services because there are real enterprise value tradeoffs when a company is forced to choose between creating a custom integration versus writing to an industry-standard API.

Salesforce and Ecosystem Control

Salesforce is a juggernaut of SaaS.  It takes a marketplace approach to partnership, allowing other companies to integrate directly into Salesforce’s APIs and develop products that include Salesforce as part of other packages.  Salesforce does significant work to maintain the infrastructure for this marketplace approach and to maintain the quality of its API endpoints.

Crucially, it does not spend engineering resources to develop code that connects its systems to startup APIs. Salesforce has critical mass and has widespread market penetration—they're the standard and they can apply pressure to ensure companies and developer communities write to Salesforce APIs.

The Parable

Let’s imagine a startup, let’s call it “RobotAnswers.com” that has a new way to automate significant customer support for multiple manufacturers of advanced robotics. Across the market, these robotics are expensive enough that any robot manufacturer doesn’t just want to answer the client’s questions, but also needs to track the questions that are asked in a way that is specific to the client, the machine and the use case—i.e. customer analytics. Most manufacturers do this today with the help of live customer support entering conversations into Salesforce.

RobotAnswer’s CEO is pitching a manufacturer about the benefits of automating the manual customer service tasks. But the manufacturer knows that customer questions are important to his product roadmap and is worried that automation will prevent him from capturing this data in Salesforce.  The manufacturer asks whether the data from its robotic customer support can be included in the manufacturer’s customer relationship management (CRM) system.

Naturally, the CEO will say “of course” and then ask what CRM the customer uses (we’ve all been there). The manufacturer uses Salesforce, so, luckily, with its well-developed API ecosystem, it doesn’t matter whether a pre-existing integration exists. The product and engineering teams at RobotAnswers.com can fairly easily run a sprint to make sure that the customer data generated in its system, provisionable via its own API, can be automatically written to a Salesforce API endpoint.

In this example, the market power dynamics are clear and both companies have sufficient technical resources to effect the API-to-API automation. But what happens when things go wrong?

Same case, but now imagine a legacy provider of outsourced customer support instead of RobotAnswers. It has great troubleshooting and FAQ documentation; most customers’ questions can be answered without any customer support personnel; its customer support personnel are top-notch. However, when that same manufacturing CEO asks this provider about the ability to record routine customer inquiries in Salesforce, the provider can’t make it happen.  Although the legacy provider has the ability to record which customers clicked on which FAQs at which time, it doesn’t have developers on staff to take that information and wire it into the Salesforce APIs. (After all, the company’s resources have been dedicated to developing the documentation and supporting customers, not building random software requests.) Consequently, RobotAnswers.com wins the business and is on its way to domination of the “answering-questions-about-robots” industry. Monopoly achieved.

Third time’s a charm—same case, but finally imagine that the manufacturing company uses a legacy CRM system. After receiving the request to integrate their information into the CRM, RobotAnswers.com’s developers research the legacy CRM and they find that the APIs are just old, brittle, and poorly supported and confusing...basically useless. Let's say the team at RobotAnswers.com turns to Reddit and StackOverflow for help—when in doubt, Google it. What do they find? The legacy CRM has reams of comments saying that the APIs are unreliable and require constant workarounds. Great.RobotAnswers tells the manufacturer that such an integration will require a six-month implementation, $200K up front, and an additional $50K per year for maintenance and support. Uh oh—this risks turning RobotAnswers into an Application Service Provider.

It’s not clear who wins in this scenario, but the legacy CRM now has an unhappy customer more likely to churn, RobotAnswers is more likely to lose the deal and the manufacturing company has lost an important shot at new proprietary data about the challenges her customers are having with her robots. Deadweight loss all around.

The Takeaways

The question of where APIs exist (or don’t) and how they connect is an expression of market power in the quest to control more pieces of the value chain.

• When RobotAnswers.com is asked to integrate with Salesforce, they just say yes—all parties can participate and the ecosystem creates value. Salesforce adopters constitute a valuable addressable market with a low net cost of integration. Therefore, RobotAnswers implicitly accepts Salesforce’s market power upon recognizing that a Salesforce integration is the only way to enter that market.
• When a legacy robot-answers vendor fails the integration test altogether, there is no market participation since the vendor cannot meet the common denominator set by Salesforce. All parties stand to lose value.
• When asked about integrating with a legacy CRM, RobotAnswers imposes a significant up-charge—a tax, of sorts—on the customer to make it worth its time. From a different angle, the upcharge helps recover cost of labor, the opportunity cost of not pursuing a simpler market, and provides a potential cross-subsidy for future similar integrations on the assumption that such an integration should be repeatable for any company licensing the same legacy CRM. The market clears, but at a different equilibrium point.

This means that in a business negotiation, it is not enough to simply pay a vendor for their developer’s time. The vendor’s CEO faces a constant tradeoff between developer time that contributes to a generalized solution and will translate to revenue with a 10x valuation multiple and developer time that will slowly but almost certainly increase technical debt with the added penalty of maintaining the debt to avoid customer churn—the bane of every SaaS company’s valuation.

In this way, every API-first vendor follows the natural logic of modern SaaS:

Is customer X’s problem the general problem? How far from the general problem is it? If it’s not repeatable, it’s not a priority. (Solutions and product professionals, we empathize with you)

By this logic, APIs are an optimal technical solution to a business problem because they allow more complete market participation. They are the new standard answer for how a SaaS company creates cost-efficient repeatability. A simple, well documented, reliable API reduces the cost of doing business for a vendor. From a microeconomic perspective, this allows for a high quantity of lower-cost market clearing transactions to take place—and at its most efficient, everyone’s APIs are mutually intelligible.

In a fintech-specific case, assuming uniform resources, these pressures should—in theory— resolve to banks developing clean APIs. Every bank we’ve talked to has acknowledged the pressing need to have an API-strategy. But wait, there’s more. The market logic of APIs illustrated above is not simply about SaaS economics. Instead, the market dynamics go even further and indicate that banks and fintechs should adopt industry standard, or Open APIs, and participate in a scalable ecosystem where the effort of each software vendor and innovation is instantly transferable into each bank and fintech use case.

However, resources are far from uniform. Mckinsey, in a survey of global banks, finds the following:

While the majority of APIs by number are internally focused, most banks have some kind of outward-looking program. [S]ome 65 percent of the 40 European institutions among the 100 leading global banks (ranked by balance-sheet assets) have a developer portal to share APIs externally. On a global level, 47 percent of the top 100 do the same thing. Regulation is often a primary driver, but equally banks are seeking to innovate where they see an opportunity.

Moreover, only 2% of the APIs banks actively employ are classified as open APIs, with the majority serving internal-only purposes

But Wait—There's More

The earlier example shows the tug-of-war between major and minor players in what is a very weird version of the two-body problem. The role of market power in B2B negotiations is nothing new—whose brand is customer facing? whose needs drive the end product? How do the economics split? These are age-old questions, but the nature of APIs has introduced a new dimension into these negotiations which is already having profound effects on the B2B marketplace.

But the fact of the matter is that this tug of war is changing— the reality in fintech is that we're dealing with at least three bodies as the relationship between applications and financial institutions becomes increasingly intermediated. From the top down, we can summarize the market like this:

• Top: User-facing applications: neobanks, segment-specific applications, aggregators, marketplaces, P2P payments, remittances etc.
• Middle: API-first providers: payments, authentication, invoicing etc.
• Some of these have user facing components, e.g. Paypal, Onfido, Socure, etc.
• Bottom: "Actual banks" and financial institutions: Chase, Visa, Cross River, Bancorp etc. (more on this over the next two articles)

Why does this matter? More combinations and permutations of providers create market conditions where APIs become vital for the top and bottom tiers to survive. The best API providers provide highly flexible, high-fidelity services without necessarily requiring either customer type to conform to their opinion about how a certain business operation should be performed.

For example, cross-border e-commerce is booming (~2x growth rates, expected to reach ~20% of B2C e-commerce by 2022) but consumer payment behavior is still hyperlocal and culturally specific. If I'm Shopify, for example, I would be crazy to try and build the features necessary for managing a slew of complicated needs, e.g. global/local payments acceptance methods, currency conversion, RTP, onboarding, etc.

Cue Stripe to be a robust broker between me and the payment rails of my choosing.

Though with the advent of Stripe Treasury, Stripe continues to gain market force by being able to permute its own offerings into a wider variety of end-to-end solutions. A tearsheet article from December 2020 sums it up concisely:

Stripe has partnered up with Goldman Sachs, Evolve Bank and Trust, Citibank and Barclays to provide banking services for the new product. The API will enable merchants and vendors to make ACH and wire transfers through Stripe’s banking partners. Stripe clients also get access to interest-bearing bank accounts and faster access to payments.

Here, Stripe Treasury is a very aggressive form of value-added service provided by an API-first company in a universe where Stripe has become an indispensable intermediary. Stripe Treasury, by facilitating modular ACH embedding and deposit services (via Stripe Balance), completes a full end-to-end value chain almost exclusively for retailers. Moreover, in an interview with Wall Street Journal, John Collison described the rounding out of Stripe’s merchant stack as a customer acquisition channel for Stripe's partner banks.  This is verticalization in action.

In keeping with our framework, by fleshing out the stack with a BaaS API and incentivizing banks on one end to work with API-first/digital merchants on the other, Stripe has taken friction out of the market and facilitated greater participation, allowing the market to clear at a very efficient equilibrium point. This simplicity has put industry on notice.

Stripe Treasury’s choices are intentionally aimed at the digital merchant stack, not the neobank stack, not less-savvy merchants, and not small businesses that may need lending or bill-pay. We think it’s far-fetched to say ‘game over’ for BaaS when Stripe Treasury only has a lock on one part of the transacting universe. However, what we all ought to keep our eye on is the fact that all of Stripe’s products are interoperable. As Stripe releases new solutions, the value of all solutions goes up — increasing marginal product of capital. True to form, Stripe has the right combination of API-first strategy and SaaS unit economics to become a ubiquitous backbone

Given their capabilities of progressively achieving lock-in across multiple stack ‘types,’ not unlike a game of Risk, a player like Stripe is going nowhere

But as we'll see in the next two articles, the power battle between banks and API providers is heating up as embedded finance and Banking-as-a-Service continue their rise. Applications at the top of the stack would love nothing more than to plug directly into banks and processors directly, but as we'll soon see, most banks have a long way to go to start poking holes in this middle layer.

In the meanwhile, API-based financial intermediation is upon us, and it's everywhere.

**

Amias Gerety is a partner at QED Investors, a leading fintech venture capital firm.  His investing has focused largely on back office and infrastructure themes.  Prior to QED, Amias was Acting Assistant Secretary for Financial Institutions in the Obama Administration.

Nate Soffio is an MBA Candidate at Wharton focusing on fintech, regulation, and financial inclusion. There, is the co-chair of Wharton’s Fintech Conference taking place April 22-23. Hailing from Stamford, CT by way of Medellin, Colombia, he spent a decade building (and breaking) things in the infrastructure and regtech worlds with a focus on Know-Your-Customer and identity management. Before Wharton, he helped lead product at Arachnys, a London-based regtech and QED portfolio company. Nate holds a B.A. with Distinction in Linguistic Anthropology from Yale University.  In his spare time you can find him road cycling, rock climbing, and cooking.

Media inquiries:

Ashley Marshall, Director PR and Communications, QED
Ashley@QEDInvestors.com
(518) 577-9984