The No-Code/Low-Code Accelerant

APIs are everywhere, and, in no uncertain terms, every SaaS company must turn into an API-first company to survive. For the last six weeks we’ve laid out a guide for the next generation of SaaS built on the foundations of API-first development.

What does it mean for the next generation of fintechs to be powered by API-first companies?

• First, it means that the barriers to entry are going to go down for consumer-facing and small-business companies.
• Second, it means that the divide between financial services and other products will erode.
• Third, the sources of value in API-first companies will subdivide and product- and strategic- distinctions need to be even sharper.

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

‍

Financial companies embrace tech while tech companies, via embedding and other types of integrations, become financial services providers. In this mixed-up future, there are still just three layers to the puzzle: feature-rich customer experience plus some financial institution plus connective tissue.

In reality, many fintech companies are actually just digital marketing arbitrage companies—beautiful, hyper-segmented containers offering financial services like checking accounts, savings and investment accounts, free trading, or insurance brokering. They differentiate on distribution, bundling, experience, access and premia while focusing on ease. The best ones ‘just work.’

At the bottom, financial institutions will continue to excel at just that—having bank charters, writing insurance policies, managing investment accounts, transmitting payments and underwriting loans.

So, over these seven essays, we’ve drawn a line in the sand about whether banks should move toward having APIs that ecosystems want to write to, or participate by writing to someone else’s APIs. As we’ve seen, we expect larger money center banks to use their critical mass to pursue an imperfect platform play whose APIs are written to, whereas regional and community banks can capture value through their ability to become infrastructure or channel partners and decouple banking services from the user experience.

As a result, BaaS companies comprise the connective tissue that facilitates creative combinations of products and experiences and gives both sides the freedom to buy versus build. Some of these companies in the middle—specifically those companies we have examined in this series—will make holistic connections between top and bottom stable, flexible and easy to use (Treasury Prime, Moov, Stripe, etc). Others will focus making data easy to get, easy to work with, easy to analyze; these companies will help others make their features “rich” and differentiated – enabling personalized experiences and facilitating the current explosion of verticalized financial services companies.

Some examples

• Attach installment financing to things that traditionally aren’t financed (Affirm, Klarna).
• Facilitate payments at times when they aren’t usually made (WageStream, Rain).
• Capture different data streams that allow for much cheaper financial services (Wayflyer, Fairplay, Pipe).
• Balance modern security and permissioning to collectivize finance (Braid).
• Centralize bank account information to streamline lending option discovery (Guiabolso).
• Consume output from other APIs via gateways to form SuperApps that merge ecommerce with wallets, fulfillment and prepaid (Rappi)..

Simon Taylor at 11:FS partially sums up the market pressures:

Banks have competition from above, where the strategy is to solve the customer problem, build for engagement and use that to create growth.

Banks have competition from below, where the strategy is to be a platform for others, enabling financial products to be embedded elsewhere to create growth.

The logical endpoint for the BaaS-enabled financial services ecosystem is that it will be dominated by the inevitable logic of customer centricity and create a natural marketplace against the backdrop of commoditizing services.

Today, the value of an embedded financial product is that it allows the company who already has acquired a customer to monetize that relationship in a new way. Those banks or financial services companies offering embedded services get access to more customers with lower acquisition and lower servicing costs. Meanwhile the customer gets convenience and may even get lower prices because of the lower acquisition costs.

But the customer loses out on choice today and that arrangement is unlikely to maintain itself. Every point of lock-in is also a way to lose a potential customer. Moreover, while banks will have narrower risk appetites than the marketing and consumer acquisition-led companies that sit on top of them; they will also have broader desire to sell their financial products to everyone who fits their risk appetite. This, too, will drive marketplace-type dynamics in the BaaS ecosystem.

API-first BaaS makes infrastructure abstracted and easy to use, with the following consequences:

• Economic returns for infrastructure companies will increase because the returns to scale have increased barriers to entry.
• Copycats and marketing-arbitrage companies, like all arbitrages, will tend to go toward zero unless differentiated by business model (Wagestream versus Wonga, for example) or by brand loyalty (Robinhood, Public), or by segmentation (Chime).
• Market transparency will increase as it becomes progressively easier to compare prices of traditional financial products and consume them in effortless ways.
• It will become easier to combine features in creative and novel ways and limit the first-mover arbitrage of companies that truly innovate financial product.
• The battle for user experience is waged as a feature parity war on the back of the underlying API service providers and financial institutions who stand to gain the most.

We have articulated a vision of the next few years in which API-first companies are taking the first steps on that journey of abstracting the infrastructure layer. We don’t know yet how fast or how forcefully it will consolidate, but we are confident that it will enable fiercer competition both above and below the players who best succeed in enabling abstraction, while locking in gains for those who facilitate that ease of use.

The companies and financial institutions that will survive will either do so by being smart bundlers who write to other fintech APIs todrive incredible experiences, or those who thrive behind the curtain by having indispensable APIs to which companies write.

On one hand, the rise of the 'headless bank' gives credence to the fact that infrastructure banks like Greendot, Fidor and Bancorp are here to stay, bolstered by API connectivity. As long as these headless banks can avoid single client risk and maintain some pricing leverage as players higher in the stack grow, we should seriously rethink calling them 'dumb pipes.'

The utility and allure of APIs are powerful, though still at times unwieldy. Going back to a point from article 3: for the thousands of regional and community banks that either need to become partner banks or smart bundlers to thrive, what's the next step in their world where building technical teams is expensive? Fintech will push into the no-code/low-code era though it’s too early to tell how quickly these tools can deliver enterprise grade applications or go deeper than enabling quick web forms and interfaces.

No-code/Low-code: The API Implementation Accelerant

A late 2020 survey conducted by Propeller Insights with support from Internal, a low-code tools platform, found the following:

Many businesses are making immediate transitions to a digital-only economy, forcing a ton of new app development requirements. Yet, hiring top engineering talent is especially difficult, amid a developer drought and pandemic uncertainties. One in three organizations has implemented a hiring freeze. Respondents cited rising development challenges and insecure internal software, putting a strain on normal operations. To help address these challenges going forward, a whopping 85.1% believe implementing low-code and no-code will become more and more omnipresent within their company.

No-code/low-code software allows non-engineers to build databases, workflows, business logic and whole applications through pseudo-code and UX-based interactions. The fundamental premise is simple: allow nontechnical people to supercharge their abilities by being able to do technical work without using much, if any, code.

No-code is, first and foremost, an implementation strategy for both general and industry-specific solutions. The strongest no-code opportunities exist where API-first software development is employed against generalized problems, e.g. ML/AI, workflow automation, OCR, data pipelines, higher level application development etc.

In other words, low-code tools remove the blockades to working with APIs and help nontechnical teams knit together technical solutions from well-formed APIs—a workbench for a new era.

In the past five years, low-code/no-code investment has been growing rapidly. According to Pitchbook, since 2015 there has been major activity in 52 companies, 117 deals, 225 investors, and approximately $1.3 billion invested across TMT, Cloud/Devops, SaaS, Mobile and AI.

What does this mean for our API thesis and why are we looking at this on the horizon? The push to do more with less continues, while a dogged pursuit of either capturing the user experience or being an indispensable ingredient will incentivize highly-collaborative development practices. We think low-code engineering tools plug into our thesis by

1. Giving API-first companies a baseline expectation for how to create business-friendly self-implementation tools.
2. Giving API consumers significantly better tools to knit together and operationalize multiple complementary APIs.

Low-code tools will open doors for non-developers and nontechnical founders. Seventy percent of companies said non-developers in their company already build tools for internal business use, and nearly 80 percent predict to see more of this trend in 2021. Most companies (75.2 percent) have already implemented a combination of low-code and traditional engineering methods. It appears that low-code is complementing existing software engineering practices at a number of institutions.

In addition, 28.8 precent of respondents predict low-code and no-code will become a high priority in the coming months, and for 21.6 percent, it will become an essential focus. Impressively, 85.1 percent of developers foresee low-code and no-code as becoming more commonly implemented within their company.

As more businesses adopt low-code/no-code strategies as a standard mechanism of introducing operational efficiencies, only those providers and banks with APIs worth writing to will survive.

While it would seem that the no-code/low-code movement would put pressure on API-first companies, we believe that this movement will be much more threatening to traditional workflow-based SaaS.

In financial services, the rise of no code and low code implementation tools, combined with broad API-functions could allow banks to get back into the feature-parity competition with the best of consumer and SMB focused fintechs.

Oracle-Google SCOTUS Decision and an Optimistic Future

The magic of an API-first company is its directness and its interoperability. The fact that an API-first company sells to employees of a company who are builders is much more important than the fact that they sell to employees who are developers. As more and more business users become builders, they will get the power of customization with the scalability and interoperability of API-based tech stacks.

One would assume that APIs are naturally protected under fair use given their critical role within interoperable ecosystems. However, protections around re-implementing APIs to build new products was not explicitly protected until this past Monday. SCOTUS reversed previous judgments and rejected Oracle’s claim of copyright on elements of its Java SE APIs and Oracle’s claim against Google for implementing parts of the Java SE API within certain parts of the Android Operating System.

According to the Electronic Frontiers Foundation, the decision gives more clarity and certainty into a commonly held belief — that software developers create APIs to encapsulate knowledge, knowhow and tools with the intent that they be shared and reimplemented. This is a fundamental build principle of machine-to-machine communication: interoperability. Why make developers learn someone else’s software at the code level when APIs allow for predictable use? With predictable use, author and implementer both benefit.

Abstracting Breyer’s majority opinion, Oracle cannot claim something is basically a free utility and then attempt to claim fees when others build other free tools and utilities on top of it. The great irony, of course, is that Sun, Java’s originators, coined the mantra “run once, run anywhere.”

Nevertheless, the most salient part of the fair use doctrine is about the nature of the work and whether, as Breyer puts it, the work is “transformative.” Last week’s ruling ultimately paves the way for banks and fintechs alike to rally behind API-first approaches to ecosystem development and function more collaboratively despite intense competition. While the unit economics and pricing strategies of API-first companies will continue to be sensitive to API usage, we are optimistic that new legal protections will allow a proliferation of transformative development and implementation.

The relationship between consumer fintechs and BaaS providers will become more complex as the lines between consumption and re-implementation of Open APIs blur. Meanwhile, lower down the stack, we should expect the largest money center banks to accelerate building their own APIs and vie for positions as critical fintech infrastructure, achieving the status of APIs that are written to.

Similarly, we are optimistic that the recent ruling, along with other recent regulatory and technology changes, reduces the risk and overall friction that local and regional banks face when trying to digitize and compete in 21st century fintech stacks. Solid partnerships between smaller financial institutions and BaaS providers are more crucial than ever, with BaaS providers feeling the market pressure to implement as easily as possible.

The question remains: will these institutions be able to evolve the next generation of companies writing to others’ APIs, or, as we framed from the get-go, will they try to fend for themselves and be SOL? We’ll see.

**

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