APIs are Everywhere -- An Intentional Choice: Being API First

Preamble

Welcome to the first in a series of essays that lays out a guide to the next generation of SaaS.  In no uncertain terms, in the modern software era, the API is the product. Every SaaS company must turn into an API-first company to survive.

A cursory search on Pitchbook for fintechs with 'BaaS' (banking as a service) or 'API' as keywords returns more than 2,000 hits worldwide. Since 2015, invested capital in platform- and API-led financial technology has more than quintupled, with 2020 clocking in at more than $80 billion USD invested worldwide, up from ~$15 billion in 2015.

It is already true that at the center of every financial SaaS company, every modern fintech infrastructure, every challenger bank, every anti-financial crime stack and every company pursuing financial inclusion is the humble API, or application programming interface.

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

But the prevalence and acceptance of APIs actually understates the current moment for SaaS companies and SaaS-investors. What we think of as the great SaaS companies have been built by mastering human-machine interaction, but the next generation of great SaaS companies will be based machine-machine interaction.

APIs are everywhere, but still the implications are underappreciated.  The distinction between using APIs and being an API-first company is like the difference between companies trying to replicate their web offerings on a phone (remember m.facebook.com) and companies that actually built for mobile (Instagram).

Over the next few weeks, we will lay out the case that it is one thing to build with APIs, quite another to build an API-first company.  We will explain why API-first approaches are the next logical stopping point for SaaS; and the essential element in fintech strategy. With our product management hat on, here is the roadmap of where this project is headed:

• Part I: Our first three articles will step through the strategic considerations of being API-first and major market dynamics. Here we define the forces behind those who provide APIs, those who write to them, and who are likely to be simply out of luck.
• Part II: Our next two articles will step through what API market forces mean for financial institutions, how banks’ API strategies will crystalize and what the maturation of the connective tissue between fintech apps and banks means for market activity.
• Part III: Our last two articles look to the future, first exploring open banking, standardized protocols and changes to central banking, then evaluating how the evolution of an API-first ecosystem will interact with the emerging boom in no-code and low-code solutions.

We’ll offer a big-picture view why ultimately most banks will survive by being API-friendly, rather than by being API providers. Buying habits will change alongside technical prioritization; equilibrium will exist in tension as the largest banks have the resources to pass as tech companies where needed, whereas the vast majority will need to become adept buyers and integrators of API-first products.

Truly, APIs 👏🏼 are 👏🏼 everywhere 👏🏼.

• Ocrolus (QED portfolio company) provides a set of machine vision and document processing APIs that automate and standardize how unstructured and semistructured content like loan applications and IDs are turned into clean data and analytics.
• Treasury Prime [1] (QED portfolio company) has developed a full set of BaaS APIs that provide end-to-end financial account lifecycle management, and connectivity between payments rails, fintech apps and financial institutions.
• OpenPayd recently released an API-based FX-as-a-Service product that allows clients to perform real-time trades and circumvent traditional batch processing.
• Square recently announced its TerminalAPI that allows businesses to build contactless solutions between Square Terminal and any point-of-sale hardware. Here, the API circumvents the problem of hardware interoperability altogether.
• Stripe's launch of Stripe Treasury is a powerful move into modular BaaS across ecommerce accounts, payments, etc.
• Arachnys [2] (QED portfolio company) has developed a unified data API that allows global institutions to plug in required and supporting KYC and AML data for virtually any jurisdiction.

Core and non-core banking service digitization has rapidly mushroomed in the past 12 months due to the COVID-19 pandemic. There's no shortage of coverage about how the pandemic has reduced cash reliance while platform players have grown to fill the sudden need. In fact, a report from Grand View Research has revealed that the global payments as a service market size is expected to reach $25.7 billion USD by 2027.

But payments is just the tip of the iceberg. As digital disruption affects the global money transfer infrastructure, all the interrelated "plumbing" is being changed concomitantly. Much like Veruca Salt and the golden egg, consumers want their transactions and all the related data now. This means balances, financial health and wellness, lending, deposits, even onboarding and authentication — now, now, now. And we expect all the pieces to be able to talk to each other within or across borders.

This has led to two critical trends: first, individual offerings in the market are becoming increasingly atomic to meet the precise needs of each financial technology use case (Stripe succeeded early by abstracting away business problems with specific technical methods marketed to developers); second, because these offerings are atomic, they must be built specifically to be pluggable and interoperable, to “play nicely with others.” Consequently, APIs become essential to the growing consumer and commercial expectations that money—and the data exhaust around how we interact with money—needs to move instantaneously regardless of jurisdiction. To borrow from Dead Kennedys, give me convenience or give me death.

On this ongoing quest toward modularity and interoperability, there will be three kinds of companies: those whose APIs are written to, those who write to others’ APIs, and those who are simply out of luck. [3]

Good APIs and API-first Companies

So let's back up a second—if APIs are the backbone of modern digital banking, what are they? What makes a good API? What does it mean to be an API-first company?

The API is a structured agreement between computer programs and systems to enable functionality based on pre-determined inputs and outputs. In essence, APIs enable dialog between computers—call and response.   They have their own grammar and syntax, and can be as expressive as needed for the situation.

Nick Gard at ITNEXT provides an example we all are familiar with: the archetypical API interaction between a data service, such Google Maps, and a website that sends it some data (e.g. two addresses) and receives data in return (e.g. a list of steps for getting from the first address to the second).

There is a widely held mantra the API is the product. We believe this to be true. But just as physical products and digital applications can be well-designed or poorly-designed, so too can APIs. Moreover, businesses can have strong design teams, be design-led, or both.

Lars Trieloff, writing for Adobe, notes that good APIs adhere to the following three principles.

1. Your API is the first user interface of your application.
2. Your API comes first, then the implementation.
3. Your API is well-documented or self-described (in other words, it's intelligible to us humans).

High-quality APIs are the way to square the circle between proliferation of SaaS solutions, the pressures of cross-system communication and market pressures to expand vertically or horizontally.

From the perspective of a company consuming software from an API, great APIs make a vendor’s software functions atomic and make products and solutions highly consumable “off the shelf”. Said differently, APIs turn software into legos.

A major consequence: the battle for user engagement and user experience is now a completely separate battle from API competition. User-facing apps can compete for users’ attention on the merits of their interactions and design (mostly) regardless of which APIs are called in the background. In fact, we’d go so far as to say the strength and granularity of modern APIs has helped design-led culture flourish while the competition to create the best connective tissue carries on elsewhere.

As a practical example, when Nate joined Arachnys and Amias joined the board in 2017, the company had a library of fairly beefy internal (non-open) APIs that powered a webapp sold through a SaaS model. Despite industry-leading data reach and indexing, we found that many potential clients were not interested in retraining their teams on new workflow tools or changing the way they conducted anti-money laundering investigations. Instead, they just wanted their existing tools to work better. Now, Arachnys relies on a full set of Open APIs and can as easily provide value through a pure-API sale, plugging its tools into the compliance stack of their choosing, as they can by consuming the original Arachnys product.

Even 10 years ago, it would have been out of the question to develop a SaaS company solely focused on one part of a data pipeline or transaction or interaction; and similarly, no one would have expected that the information from those transactions would become valuable proprietary data.

This is a fourth principle for good APIs, not articulated by Trieloff: APIs should structure and collect proprietary data from their use.  There's one thing to supply great standardized plumbing, but it's another massively valuable thing for that plumbing to generate an additional layer of value-add data and metadata based on user-input content, logs, diagnostics and other signals generated from regular consumption and edge cases.

Worth noting that the question of whether it’s the API provider or API consumer who owns the data exhaust is an active battleground in fintech and other industries. As new advancements in cryptography, cloud storage and related fields roll into the market, vendors and consumers have more options about who owns what, when and under what conditions.

This is the alchemy of a great API, a property that gives great API-first companies their market power.

So what does it mean to be API-first? What makes a great API-first company?

In terms of what makes a great API, we've outlined some functional principles, but we still have the open question: is there a meaningful business distinction between being API-driven and being an API-first company?

Yes. Being API-driven is a product development principle and a good tactical choice. Being API-driven allows companies to build extensible products faster, which decreases both time-to-market and time-to-patent where applicable. It forces your engineering team to build in a modular fashion and tends to more strongly align product and engineering teams to a customer-focus.  Being API-first requires a pure distillation of the “job to be done” framework. There is no visual design aesthetic or user-experience. Instead, your potential customers ask one question: what does each API endpoint allow me to do?

But being API-first takes these benefits further and becomes a good strategic choice.

Why is this defensible strategy in the long run?

If this crossed your mind, you're not wrong. But you're not quite right either.

Many, many, many pieces have been written about the nature of moats: user base and network effects, regulations, switching costs, and unique technology and related patents. So, to reiterate an earlier point, a focus on API-first design and productization often involves intentional choices around the proprietary data generated from its use, which, according to many, is where the maximum value of a moat sits.

Consequently, being API-first is a good strategic choice. Being API-first naturally forces the business to define differentiated user-facing processes and services earlier in company formation than traditional software development lifecycles.

In fact, being an "API-first company" is a strategic choice that:

• requires a company to focus on friendliness and interoperability; seeking lock-in through quality rather than switching costs.
• requires the intentional creation of developer communities and an ecosystem of support; relying more on facilitating peer-to-peer virality than traditional sales methods.
• tracks toward a long-term goal of having productized data derived from the APIs. (This might manifest as a productized data-generation capability, or bundled assets for complementary purposes).
• commits the business to an early horizontal strategy—get a lock on one layer or atomic service in a particular stack (e.g. payment gateways or authentication). An API-first company will act in ways that make providers above and below you more valuable with your offering in the mix, rather than immediately seeking to displace players in an ecosystem.
• recognizes the tradeoff between traditional SaaS margins and greater potential retention, lock-in, usage-based growth and up-sell potential.
• plans for future vertical growth through the addition of complementary services over time.

As Chris Sperandio of Segment rightfully pointed out in 2018, the strength of (a) how well an offering can be integrated or (b) the value of its combination of integrations will provide the best customer journey. But this is challenging, and in Postman's most recent State of The API report indicates that most respondents are somewhere in the middle of their journey.

In our next post, we'll comment on the role APIs play in SaaS unit economics and how these power dynamics have fundamentally altered the long-run view of customer experiences and buying expectations in financial services.

From there, we will go in-depth on the mechanics of our market power thesis and begin to examine what this means for traditional financial institutions and how the rise of BaaS and neobanking puts API market power into practice.

**

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

[1] Disclosure: Amias serves on the board of Treasury Prime, Ocrolus, and Arachnys.  Nate is working with Treasury Prime this semester on a project facilitated through Wharton’s Stevens Center for Innovation in Finance)

[2] Disclosure: Nate worked at Arachnys for the past 3 years. Shout out to David Buxton and team for tons of support and a great learning experience along the way.

[3] One could imagine using saltier language here.