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

In our last essay, we defined the core ecosystem value and the raison d'être of banking-as-a-service (BaaS) providers—to sit between consumer apps and "real banks" and do what many banks are still struggling to do: provide portable, pluggable banking services out in the wild where consumers need and want them the most.

Bear in mind that this value is based on API-first methods that allow fintech companies to provide both regulatory and transaction infrastructure to non-finance companies across the whole range of money movement and financial risk.

We argued that banks need to embrace their role as financial infrastructure, bound by their ability to use government guarantees to take levered bets on the real economy and create products to maximize lifetime value. In turn, it is up to BaaS to act as the amplifier through which these services can be broadcast into a much wider market than they would be able to do solo.

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

Today, we talk about the impact on regulation and government policy. Starting with recent examples, we look at what governments can do to support markets and consumer fairness in a world of API-first software.

Policy makers are recognizing this trend at an increasing pace, and there are promising examples where they can drive it forward. In fact, the logic and language of APIs is consonant with best practices in writing law and regulation, with an emphasis on open standards, clarity and predictable inputs and outputs.

We've spent five articles talking about the power dynamics generated by API development and related changes we're seeing with the connective tissue between software and banks. So we're going to spend this one considering what's going on in the world. Mexico's so-called “Fintech Law” is a powerful example of a public policy change that will prompt accelerated adoption and enforcement of open data standards and protocols. Here are three more:

1. PSD2 standardizes new types of intermediation
2. The US's PPP meltdown is a case study for much-needed standardization
3. Central banks consider digital currencies and fintech participation

The practical effect is that the next generation of financial regulation globally will be—to an extent— regulation on the modularity and interoperability of fintech SaaS that the markets need to run efficiently, fairly and inclusively.

Mexico: explicit language for data standards

Mexico's 2018 Financial Technology Institutions Law—the “Fintech Law”—launched in 2018 and largely implemented by the end of 2020, is transformative. It mainly regulates two types of companies: electronic payment institutions (EPIs, or what other countries call "electronic money issuers") and crowdfunding institutions. Under the law, both types of institutions are permitted to operate with virtual assets (e.g., cryptocurrencies) that are authorized by the Bank of Mexico.

Licenses are the main mechanism of control, and the onus of applying for licenses falls to different types of EPIs, including consumer-facing neobanks like Klar, which relies on BaaS provider Galileo to deliver payments services. While the law supports specific licensure and capital requirements that help de-risk the landscape for investors and consumers of the consumer apps, the underlying licensing mechanism enforces a specific level of compliance not only on the user-facing app, but also on the service providers responsible for the plumbing between app and bank.

In fact, the law introduces a shared regulatory framework grounded in open banking principals, specifying that fintech entities be subject to, among other things, data sharing requirements to ensure compatibility and open standards between payment institutions and other technology providers, explicitly defining open data, aggregated data and transactional data.

The biggest macro-level trend is an emerging framework for other Latin American regulators to engage with emerging fintechs and their mechanisms of connecting with lending and depository services to ensure market standards spanning from P2P payments (Brazil) to crowdfunding (Colombia) to roboadvisors and payment agents (Chile). The common denominator is not around the apps themselves, but the mechanisms of issuance, money movement, money storage, plus transaction and account integrity—the stuff of digital banking services themselves.

Open Banking & PSD2: standardized, API-first participation

We glossed over open banking when discussing Mexico’s so-called “Fintech Law...but what is it? The Open Banking movement is characterized by a number of international regulations and initiatives that require banks to make both financial service functions and consumer financial data more readily available to approved third parties.

This shift in mindset cropped up in multiple places at once—Australia, the U.K., the EU and the U.S. Much of the regulatory pressure to standardize stems from the U.K.’s and the EU’s treatment of retail banking data, whereas in the U.S. the Dodd-Frank Act created a dormant authority to require data access that has been recently taken up by the Consumer Financial Protection Bureau. In the U.K. and EU cases, the regulations apply strong market pressure on institutions to ensure that data both around payments and also the associated account information are mutually intelligible to all participants.

The motive is simple: a consumer has a right to their data, and the right to permission it to accredited third parties. An institution holding the data has the obligation to protect it, the obligation to release it, and an obligation to make the data easily portable.

WIth that in mind, policymakers have begun to recognize that account information needs to conform to the same predictability as transaction data, especially as BaaS providers take on more of the heavy lifting between third party providers and underlying financial institutions, not less.

What’s the most effective way to enforce common data standards and reduce market friction? Open API-first approaches for both payments and account information. By this understanding, Open Banking establishes the rules of engagement, and banks have to turn to API-first methods of participation, which, as we’ve seen, will more likely be through third-party BaaS providers instead of being self-built.

In the EU, Payment Services Directive 2 (PSD2) is a statutory framework aimed at making payments more secure by allowing customer banking data—with client permission—to be shared with authorized third-party providers like fintechs and merchants. The Access to Account (XS2A) rule focuses on the standardization of APIs and the creation of a third-party payment service provider (TPP) register.

Access itself is broken out into two components.

• Banks and other account-holding payment services must facilitate consented access to account payments data via Payment Initiation Service Provider (PISPs).
• Banks also must enable centralized customer and provider identity verification and authentication in order to govern access by PISPs via Account Information Service Providers (AISPs.)

AISPs and PISPs are the enforcement mechanisms through which any given API-first financial services provider will sink or swim in a PSD2 jurisdiction.

1. PISPs will grow as a preferred way to connect online payment experiences directly to banks without going through the telephone game of processors and card networks. This shift in disintermediation substantiates our hypothesis from Article 4 that the "actual banks" that survive will either create open APIs worth writing to or otherwise survive in an infrastructural capacity, partnered with a BaaS provider that can manage the PISP requirement.
2. AISPs will become more widely adopted as bank customer data fragmentation will take a long time to clean up. In practice, AISPs will ensure that sharing financial health and identity data across banks will drive customer value. Done properly, this might be a viable alternative to weakly-adopted or regionally-limited consortium models. For this to be market-viable, banks must be empowered enough from a technical perspective to reliably provision customer information via API and required to cede control back to the customer.

PPP Meltdown: A Cautionary Tale

The Paycheck Protection Program (PPP) created by the CARES Act was a grant program dressed up as a credit program. PPP was designed to get dollars into the hands of small businesses as quickly as possible in order to help those small businesses avoid needing to lay off workers. To do so, the government needed essentially four pieces of information: proof that a business was small, proof that a small business was hurt by the pandemic, the monthly payroll of a business and a valid bank account.

In practice, we had no reliable way to access that information quickly. As such, PPP was designed to outsource this data gathering and payment processing to banks (initially) and other lenders (at the tail end of the first tranche).

Given these realities, the PPP program was designed to try to get money out quickly, almost entirely sacrificing design principles of comprehensiveness or fairness. A comprehensive program would have been designed to give all small businesses a payment. A fair program would have been designed to give payments to small businesses payments in proportion to the impact of COVID-19.

Instead, we primarily used the credit underwriting business processes of banks, which naturally prioritized existing customers and business strategy as they ramped up capacity.

The results were clumsy at best. Fintech’s record in this process was both heroic and problematic. The rapid processing capacity and geographic flexibility allowed fintechs and partner banks to vault into the top ranks of PPP lenders. Ocrolus, for example, working with Square, processed 100,000 applications in a single weekend. Cross River Bank, also working with Ocrolus and partnered with Fintechs, became the fourth-largest PPP lender in the country. Radius Bank (now Lending Club Bank) used an automated engine created by Treasury Prime to process over $1.5 billion of loans in the first week, more than its entire balance sheet before COVID. Fintech lenders also vastly overperformed banks in making small loans, with 73 percent of fintech loans smaller than the national average.

Research by Sabrina Howell and colleagues shows that fintech lenders made a significantly higher share of loans to minority business owners, even higher than Community Development Financial Institutions (CDFIs) and minority depository institutions.

Unfortunately, fintechs seem to have been a significant vector for fraud as well.  According to the DoJ, fintechs handled 75 percent of the approved PPP loans that were ultimately connected to fraud despite touching only 15 percent of PPP loans overall.

How could so much go so wrong so quickly?

Let’s face it: PPP was designed to work on the old rails that existed and to function as a credit program, even though it was an entitlement and a grant program. The PPP lifecycle could not support everyone who was eligible, the lifecycle could not consistently identify ineligibility, and then resources were not prioritized for the neediest. Any time some data needed to change hands, a guessing game ensued.

Identity verification and eligibility is a simple example to illustrate the larger set of interlinked issues. As we’ve seen in PSD2 in Europe, identity is one of those tricky domains in which common data standards and mutually-intelligible information sharing is a necessary precursor to having a usable financial identity. An astute reader will notice that data standardization and mutual intelligibility are essential features of the API-economy. But creating a comprehensive and fair system without that infrastructure was all but impossible.

If the government had somehow been able to access validated information on small business status and bank accounts, the payments themselves would have been easy to make. Frustratingly, these data sources mostly did exist within government systems. Every business is required to file W-2 wage data with the IRS; every state collects sales tax and therefore sales tax data. But without a modular infrastructure for data exchange, this information was locked in silos and couldn’t be brought to bear on the problem.

In the majority of fraudulent application cases, some cursory googling or targeted searching would have indicated some types of ID spoof. But alas, speed won out over thoroughness in order to keep individuals and SMB afloat. Because most loan application systems relied on self-reported/self-certified information, with each underwriter collecting and crunching slightly different signals, fraud slipped through the cracks.

This prompts the question: are there chances in the future to enforce shared consumer and SMB identity verification standards knowing what we know of APIs and their market power?

Yes and no. APIs are an implementing technology; they enable scalable consistent data exchange. But they can’t create those standards, validate the source data, or tell their users how to use the data that come out of them. It thus falls to the next generation of regulations and policy guidance to set the rules of engagement and ensure financial data infrastructure is more responsive, more accurate and more fair in times of crisis.

Central Banking Has Entered The Chat—Standardized Digital Money

As markets continue to heat up and fintech stacks become more sophisticated, central banks are wondering whether they'll be picked last for kickball. To extend an earlier metaphor, central banks live 'underneath' the money center and smaller banks we've discussed. They are called Central Banks because they literally act as the bank at the center of a country’s banking system—holding accounts for licensed players to exchange payment with each other; lending to licensed players in times of crisis.

How do they participate in API-led transformations throughout the stack? Central Bank Digital Currencies (CBDCs), a type of digital fiat currency that is part of the money supply and independent from, but interoperable with, payment systems. Instead of a central bank printing a new 10-dollar bill, it will issue a digital token worth 10 dollars that is provisioned to a consumer directly without having to go through a payment app.

For example, China is moving toward a digital Yuan, and other large economies including South Korea and Sweden have begun working on their own central bank digital currencies. Emerging economies are assessing feasibility of national digital currencies to help address systemic issues like financial exclusion and payments inefficiencies.

Most of the excitement around CBDCs has come as a response to the blockchain community, though CBDCs could be implemented with or without blockchain infrastructure. Importantly, the questions around CBDCs are not primarily technological. In almost every country, money is already digital. But digital money is fundamentally private. It is money that is created and managed by the banking system, even as that banking system is guaranteed by the State. So the conversation on CBDCs should actually be seen as a policy question about public provisioning of digital money.

There is also a recent literature review from the Federal Reserve on the application of CBDC in the U.S. that's worth a read. The gist is twofold:

1. CBDCs may allow central banks to participate more directly in the consumer financial experience in addition to supplying an alternate form of reserve. Some see CBDCs as an interest-bearing asset that may be a viable consumer alternative. Open questions remain about whether such competitive pressures would theoretically enhance traditional banks' depositor base or cannibalize profits.
2. CBDCs may serve as a payment alternative to physical cash and deposits (private money), each of which are subject to their own limitations. For example, CBDCs are conceived as real time, free payment networks, which could directly help traditionally cash-reliant populations and free up collateral assets for traditional transactions. There's an open question of what such an equilibrium state between CBDCs and deposits looks like. Initial thinking suggests both underbanked and banked households would need to have CBDCs in their portfolio, though it’s possible that the consumer perception would not distinguish between the two. (Just as we currently think of dollars in the bank and dollars in our pocket as identical.)

If CBDCs become a reality in monetary systems, they will need support from modern technology approaches to make them useful. Just as banks need modularity to be worthwhile participants, central banks will also need a boost from fintechs to ensure centrally-controlled tokens can interoperate fully in the new world. Nevertheless, glimmers of payments-platform-friendly CBDC solutions are already taking root. For example, fintech company EMTECH is launching a Central Bank Sandbox specifically to enable central banks to set up interoperable digital currencies with APIs to support modern networks.

Fintech-central bank collaborations comprise a white space we should all keep our eye on as the bleeding edge of API development and the push toward greater interoperability continues to overlap with the blockchain and digital money spaces.

But in the meanwhile, government and regulatory focus on standardization is happening across the globe, seemingly all at once, as the questions on financial plumbing become inseparable from questions around the plumbing for financial data. It's a safe bet that government institutions will continue to apply positive pressure on the connective tissue between banks and fintechs and disincentivize fragmentation and proprietary standards. What remains less certain is not if, but whenand how central banks will develop novel methods to plug into the increasingly API-first ecosystem.

**

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