The Next Generation of Fintech Infrastructure: How API Platforms are Disrupting Banking & Payments

By Sebastian Garcia, Stephen Rickli, and Sid Sapru

Takeaways

• Fintech infrastructure companies are transforming the technology and financial services industries through APIs, enabling virtually any software company to offer financial products directly to their end customers through embedded fintech
• In the Banking-as-a-Service (“BaaS”) ecosystem, unregulated startups (e.g., Marqeta, Bankable) offering financial products through APIs and bank partnerships are well-positioned to take advantage of these trends, as are digital-first banks (e.g., CrossRiver, BankMobile) and certain legacy banks (e.g., BBVA, Goldman). Longer term, we believe new companies establishing banking infrastructure API marketplaces between customers and multiple banks are likely to succeed
• In the Payment Facilitation (“PayFac”) ecosystem, two sets of winners are likely to emerge: (1) existing PayFacs (e.g., Stripe, Square) who provide payment solutions to customers below a certain size, and (2) Payments-as-a-Service (“PaaS”) companies (e.g., Finix) enabling software customers to become PayFacs themselves as they reach a scale worthy of that investment. While we believe the PayFac ecosystem will support multiple winners serving different customer sets on either side of this scale threshold, a single player could become dominant by offering product offerings aimed at both

The Next Generation of Fintech Infrastructure APIs

In the decade after the global financial crisis, new fintech companies succeeded by taking an existing financial product and building software that made the product easier to buy and use. Companies like Lending Club (personal loans), OnDeck (SMB loans), and Credit Karma (credit information services) executed on this thesis.

Matt Harris, a fintech investor at Bain Capital Ventures, coined this era “Fintech 1.0”, where fintech was a business model in and of itself. The next generation of fintech — Fintech 2.0 — is quite different: it’s all about financial products being embedded into existing technology solutions. As Harris puts it:

“Financial functionality is becoming a native component of the stack (both technology stack and as a business model), which means there’s a growing opportunity for embedded fintech rather than pure fintech. In other words, we’re turning our attention to investing in companies that use financial technology as an ingredient versus a primary business model.”

There are several benefits to a software company embedding fintech into its product: (1) lower customer acquisition costs, since customers are already using the existing product or service through which financial services are being cross-sold, (2) higher switching costs, as these products are deeply embedded into existing customer workflows, and (3) improved data and analytics; since technology companies have deep relationships with their customers, they often have better data for credit underwriting, risk management, and other analytics useful for delivering financial services.

As a result, several companies are now providing fintech infrastructure APIs to enable other software companies to offer financial services themselves directly as part of their native customer experience. Some of the largest software companies in the world are now offering financial products: Apple Card by Apple, checking accounts by Google, banking services built into both Uber and Lyft, and, most recently, Shopify offering business banking accounts.

Andreessen Horowitz partner Angela Strange goes further, arguing that “every company will become a fintech company” through an “Amazon Web Services Era for Financial Services.” In the same way that Amazon created cloud infrastructure enabling software companies to store and manage their data, new Infrastructure-as-a-service (“IaaS”) companies will create financial infrastructure enabling software companies to offer financial products. Strange argues:

“There are several different infrastructure companies that will partner with banks and package up the licensing process and some regulatory work, and all the different payment-type networks that you need. So if you want to start a financial company, instead of spending two years and millions of dollars in forming tons of partnerships, you can get all of that as a service and get going.”

Banking and payments are two of the verticals receiving the most investor attention and experiencing the most disruption from IaaS companies because they have outdated tech infrastructure and account for the largest segments of the financial industry. As such, they offer a possible roadmap for innovation within other verticals.

Banking

Innovation in fintech infrastructure has led to the rise of Banking-as-a-Service (“BaaS”), defined as “an end-to-end process where third parties — FinTech, non-FinTech, developers, etc. — can access and execute financial services capabilities without having to develop them organically. BaaS involves banks providing third parties with access to core systems and functionality so that they can integrate digital banking and payment services into their own products.”

The BaaS ecosystem is divided along regulatory boundaries. For the most part, fintechs offering banking services have stayed outside of the regulatory boundary because the process of obtaining a banking license is lengthy, expensive, and regulatorily prohibitive. Moreover, these startups have received attractive valuations as technology companies and have therefore shied away from obtaining their banking licenses, as becoming a bank would likely result in a materially lower valuation.

Two primary BaaS business models have emerged:

1. Unregulated start-ups (pure-play BaaS providers): these fintechs offer banking infrastructure APIs to customers and partner with banks (typically 1–3) on the back-end. Examples include Synapse, Bankable, Marqeta, and Galileo
2. Regulated banks offering BaaS APIs: this includes both legacy (e.g., BBVA, Goldman, GreenDot) and digital-first banks (e.g., Cross River, BankMobile) offering APIs through BaaS platforms. These banks identified the trend toward embedded fintech early on and have opened up their banking capabilities directly to software companies through APIs in order to create a hedge against tech competition and build a wider deposit share in markets they otherwise wouldn’t be able to access

In the short to medium term, we believe that both types of companies will have success depending on their respective use case:

1. Standalone banking products: for customers requiring specific banking products like card issuance and deposit accounts, unregulated start-ups will likely have the edge over banks because they can deliver point solutions more quickly, build superior technology with a better customer experience, and more easily integrate their offerings to other APIs used by the end customer
2. Full banking services: for customers requiring comprehensive banking solutions (e.g., deposit accounts, card issuance, funds disbursement, KYC / ID authentication, fraud prevention, lending, etc.), the likely winners will be digital-first and legacy banks offering BaaS APIs that fintechs and software companies can easily plug into. While start-ups are more nimble and better at recruiting engineering talent, banks can deliver a wider range of integrated banking products, provide a faster onboarding and underwriting experience, and offer better regulatory and compliance infrastructure for more complex use cases

In the medium to long term, we believe the winner is likely going to be a third model: “banking infrastructure API marketplaces”. These new companies (e.g., Bond, which launched in 2019) will be unregulated fintechs offering BaaS APIs but will have three key differences to existing pure-play BaaS providers:

1. Multiple banking relationships: instead of partnering with a few banks on the back-end, these start-ups will partner with a large network of banks. This will give customers more leverage in pricing and program management, allow for a more diverse array of banking products, and reduce the security, regulatory, and compliance risk of being dependent on a single bank (e.g., in the event of outages or a data breach)
2. Marketplace model: unregulated BaaS providers today primarily use banking partners as suppliers; in this new model, there will be a two-sided marketplace where banks will be a core customer, not just a supplier
3. Streamlined API integrations: existing pure-play BaaS providers have API capability limitations. Integration comes with friction for both customers (e.g., extensive sales, compliance, and onboarding requirements) and banks (e.g., long and costly integration processes) . The next generation of BaaS players will need to lead with an API-first, developer-friendly approach that addresses these issues by leveraging API routing layers to “enable a single integration…[and] programmatically access multiple vendors without having to do multiple integrations”

Banks will continue to play an integral role in this ecosystem by either (i) providing the financial and regulatory infrastructure for pure-play BaaS providers or (ii) developing their own APIs that can be licensed out to tech companies. In either scenario, banks will need to modernize their technology to support an open platform structure that enables them to “combine existing solutions with those from outside providers (fintech, bigtech or non-financial) facilitated by application programming interfaces (APIs)”. Marcus by Goldman, as an example, has pursued this strategy by “creating a cloud-based core technology platform that could be sold as a service to other financial services companies”.

Payments

Embedded fintech has also resulted in the emergence of Payments-as-a-Service (“PaaS”): “rather than having a standardized all-or-nothing solution delivered in a box with limited tailoring options, [PaaS] offers a menu of packaged microservices that can be delivered via the cloud. This means that all the functional capabilities available in a payments hub can be customized, packaged to order, distributed, and delivered via multiple media, significantly compressing implementation and onboarding times.”

To understand the emergence of PaaS API providers, it’s important to understand the history of digital payments. As payment volume first moved online at the turn of the century, banks partnered with Independent Sales Organizations (“ISOs”) to resell payment solutions. ISOs took on much of the burden of credit underwriting, risk management, and integration into payment processors, thereby reducing the time and resources required for merchants to accept payments.

In the 2010s, there was a shift in the preferred distribution model to technology-led sales, as payment processors recognized that software companies (Integrated Software Vendors or “ISVs”) could serve as an innovative channel for payment sales. In this new model, payments were embedded into the technology sold to merchants, leading to the rise of vertical payments. While this model streamlined sales, the arrangement made it more difficult and costly for customers to control the onboarding experience.

A new Payment Facilitator (“PayFac”) model, pioneered by Square and Stripe, emerged in the 2010s to address these issues. While initially only payments companies were PayFacs, software companies (e.g. Lightspeed) have started transitioning from just being ISVs to becoming PayFacs themselves to capitalize on the benefits of embedded fintech.

Today, software companies have three options to accept payments:

1. Pursue the legacy ISO model: the ISV refers its merchant customers to a payment processor. While this model is simple because the ISV is not in the funds flow and does not take on merchant underwriting and compliance burdens, there are downsides: the ISV is not fully able to monetize its payment transactions (it just receives a referral fee) and lacks control over the payment experience (ISV has no influence over which merchants get underwritten or how payments are disbursed)
2. Partner with a PayFac: the ISV partners with a PayFac to process payments. This model offers three key benefits to the ISV: (1) greater share of payment economics compared to the ISO model, (2) faster merchant onboarding, and (3) more control over the payments experience. However, these benefits come at a cost: (1) ISVs earn less than if they were PayFacs themselves because PayFac partners typically keep a majority of the payment economics; and (2) ISVs are limited in terms of the payment features they can offer because they are dependent on the PayFac’s product suite
3. Become a PayFac: the ISV becomes a PayFac by acquiring and aggregating payments for its submechants. The PayFac model offers several benefits to end customers: (1) faster onboarding of merchants, (2) increased control of payments experience, and (3) greater revenue share for the ISV. However, there are significant hurdles to becoming a PayFac: (1) hiring additional staff to manage legal, customer services, and engineering processes; (2) significant investment to set up payments system integrations; (3) high cost to develop merchant onboarding and compliance procedures; and (4) ongoing management of risk monitoring, fraud prevention, and chargeback process handling

In recent years, payment infrastructure API providers (e.g., Finix, Payrix, Infinicept, and Amaryllis) have emerged to help reduce the time and cost associated with transitioning from an ISV to a PayFac. These PaaS companies are taking many of the complex functions required to be a PayFac and automating them by offering these capabilities through APIs. Finix estimates that 90 percent of manual payments processes are automated through its API platform.

The other benefit to certain PaaS providers is their revenue model. Unlike traditional payments companies, which take a percentage cut of every transaction (typically 2.9% + $0.30 fee), PaaS providers like Finix charge a fixed subscription fee for their APIs. This subscription fee is significantly cheaper in the long run for ISVs who want to bring payments in-house because it enables them to gain operating leverage as they scale revenue.

While PayFacs will continue to succeed for the foreseeable future, there is still debate as to which model will win: (1) payments companies that are PayFacs and provide PayFac-like capabilities to ISVs, or (2) PaaS infrastructure companies that enable ISVs to become PayFacs themselves.

Our view is that the PaaS model will be the preferred choice for software companies with enough scale to justify the required investment to become a PayFac. While PaaS companies reduce the complexity of becoming a PayFac, there are still significant technical, compliance, and operational investments required to make the transition — hurdles that only make sense to clear if a company has reached a certain size. For example, Finix targets customers that process more than $50 million in annual payment volume.

On the other hand, smaller software companies are likely to opt for working with payments companies like Stripe offering hybrid PayFac-like solutions, which allow for many of the advantages of being a PayFac (rapid onboarding, better user experience) without some of the downsides (reduced support & compliance burdens, less revenue upside).

In the long-term, we believe there will be multiple winners in the PayFac space serving different fundamentally customer sets. At the smaller end of the market, the existing PayFac model offered by players like Square will continue to reign supreme, as these customers are too small for the economics of an in-house payments flow to make sense. For larger customers, the PaaS model that enables ISVs to become PayFacs will win out given the considerable economic and customization advantages that such a model offers.

The ability of any one PayFac model to cross the chasm from one side of the market to the other could alter this outlook. For example, Finix recently announced its Flex product, which allows smaller software companies to take the first step toward becoming a PayFac without undergoing the same underwriting, operational, and compliance burdens — effectively allowing Finix to act as a third-party PayFac on the company’s behalf. Once the company reaches a certain size, Finix migrates the company to an in-house PayFac. This approach allows players like Finix to own the customer’s PayFac needs for its entire lifecycle, regardless of scale. Similarly, larger payments companies could also begin offering APIs to enable their customers to become PayFacs once they reach a certain scale, although they will need to consider the potential revenue cannibalization once their customers bring more of the payments stack in-house.