The Promise of Payroll APIs

One of the most important catalysts for the recent growth in financial services has been fintech enablers and infrastructure. Companies like Plaid wrap otherwise byanztine legacy infrastructure in modern APIs, allowing every developer to easily integrate financial products with software products, often to the great benefit of consumers. The importance of Plaid and the API market more broadly cannot be overstated—an entire generation of neobanks, lenders, and financial management tools have been made possible through programmatic access to bank transaction data.

A new set of platform players are emerging that follow a similar pattern. Much as Plaid allowed consumers to make their bank transaction data available to fintechs, these new platforms are giving fintechs access to payroll, insurance, credit, and ERP data. In addition, these API providers are moving from a read-only modality to read-write, which gives rise to new use cases: credit APIs can provide data furnishing (read/write), in addition to credit monitoring (read only). In this post we outline our thinking on payroll-connected APIs, including the best model for market entry and the long term outlook for these companies at scale.

A framework for payroll-connected APIs

In assessing payroll-connected APIs (as in all companies), we’re evaluating two things: the “wedge” and the “vision.” The wedge is a narrow product offering that solves an acute problem, allowing the startup to achieve momentum and benefit from increasing returns and preferential attachment. The vision represents the scaled, long term outlook for the product, and ideally shows maturation and expansion around the wedge. Because momentum is so incredibly important for startups — indeed, the only way to will them into existence is through a focused and compounding product strategy — these two areas are given equal weight.

The promise behind payroll data

If we think of a consumer’s balance sheet in the way we would a business’s, then payroll is the “revenue” side of the equation. To date, this data has only been visible to financial service providers in a peripheral way—income data isn’t available on credit reports and is only directly visible to a consumer’s primary bank. This data is important because it gives visibility into a consumer’s spending potential or “ability to pay,” while most other measures of credit focus on “willingness to pay.” Both Jeff Bezos and your grandmother may have a 760 FICO (indicating their “willingness to pay”) but have very different incomes (their “ability to pay”).

Universal access to payroll data holds promise for lenders, neobanks, employers, and B2B fintech companies in distinct and interesting ways.

Lenders can become better at both underwriting and servicing loans. Most immediately, lenders can verify income and employment information much more quickly and easily than existing methods for doing so. Further, when loan repayments are pulled directly out of a consumer’s paycheck, called payroll-attached lending, it de-risks a loan significantly. It is akin to a loan that is securitized with a consumer’s income stream, or by factoring a consumer’s paycheck, rather than a true unsecured loan where the lender depends on the customer’s willingness to repay. This sort of “voluntary garnishment” can reduce losses for lenders and allow them to underwrite to a broader set of consumers. In addition, payroll-attached lending has the potential to reduce fraud, improve credit quality, and decrease charge-offs. This is particularly important for startups in the unsecured lending space (such as credit cards and personal loans), since consumers are less likely to repay a loan from a lesser known startup than they are from an established legacy lender. The order of repayment is known as the “payment waterfall,” and pulling directly from payroll puts the lender in question at the top.

Consumer fintech companies can increase LTV by switching a consumer’s direct deposit. When neobanks and other deposit-taking institutions connect to payroll, it gives consumers the ability to re-route their direct deposit to a new account, called direct deposit switching. There are many benefits to receiving a consumer’s direct deposit. Namely, the account receiving the direct deposit is likely to be the consumer’s primary account, where the account is automatically funded with payroll rather than relying on the consumer to transfer funds. This dramatically increases the fintech company’s share of spend and LTV, as most neobanks today monetize through Durbin-exempt debit interchange.

Enterprise fintech companies can also get more seamless and secure access to payroll and HR systems so that all employee data can be pulled into one place. This saves significant time for the software company that would typically need to build one-off integrations, as customers may be on different payroll and HR system providers. As a result, payroll access provides these applications with a rich set of additional data. For example, an FP&A application can pull detailed headcount expenses from payroll data; headcount expenses can be used to underwrite insurance or commercial lending for the business. 

Finally, employers are better equipped to provide financial benefits to their employees. It is a strange anachronism that workers receive health benefits through their employers, but not financial benefits, even though the employer is their primary source of income. As this trend gathers steam, employers are increasingly offering holistic, employee-aligned benefits like earned wage access and savings accounts, all powered by payroll APIs. Companies like Brightside, which provides financial health as an employee benefit, are at the forefront of this approach.

All of these benefits hinge on coverage: the percentage of employers and employees that the API platform connects to across the fragmented landscape of payroll providers. Currently, payroll data is provided through a combination of third-party software providers and employer-built solutions (such as Walmart’s). Most fintech companies currently build coverage through a combination of screen-scraping and direct integrations. The former is easier to set up, while the latter is more reliable. Either way, high coverage is the necessary price of admission to be a player in this space.

The trade-offs of various wedges

There are four main approaches here. Each has opportunities and challenges.

Income and employment verification

This entry point has a number of interesting attributes. First, there’s an opening to compete with underwhelming incumbents in this space. Equifax has a large (and unloved) legacy business called Work Number that provides income and employment verification. Despite being low-tech, the business generates hundreds of millions in revenue each year, making for a well-understood TAM that a startup can go after with the usual playbook: attacking a low-tech company that has an enormous profit pool with software.

Second, there is the potential for market expansion. Though income and employment are routinely verified for mortgages, they are typically not verified for unsecured loans (cards + personal loans). Adding this verification should improve underwriting and reduce losses for lenders, thus increasing market size for the product.

The challenges with this approach are:

• Lack of customer urgency – Work Number customers have little incentive to switch providers. Better employment verification, while valuable, does not unlock additional revenue for companies, implying a race to the bottom on price.
• Regulatory hurdles – The Equal Credit Opportunity Act limits what information can be asked of consumers and the ways in which it can be used by unsecured lenders.
• Competing models – Though more accurate employment and income verification could improve underwriting, many card and personal loan lenders currently have models for how consumers fib about their income. For example, it turns out that people who make $100,000 consistently claim to make $120,000. These models, though imprecise, have sufficed for most lenders, to date.

Direct deposit switching

Enabling consumers to switch their direct deposit destination is incredibly valuable to consumer fintech companies, making it an interesting wedge. The company that wins direct deposit likely wins the customer’s engagement and greatest share of spend. 

The current direct deposit switching process is slow and filled with friction: the consumer needs to manually submit the payroll change to their employer’s payroll provider. It then takes a couple pay cycles to implement the change. This acute pain point creates an opportunity for software to automate the switching process.

The challenges with this approach are:

• Customer concentration risk – There is risk that a few large neobanks will end up gathering the most traffic, especially as consolidation occurs among consumer fintech companies, which should drive down unit price for a platform provider.
• Low defensibility – While deposit switching is an interesting wedge, it isn’t particularly defensible given the lack of recurring use or network effects. A customer could easily move from one switching provider to another; the utility is one-off on a per-customer basis.
• Smaller TAM – The existing market size for deposit switching may be small. There are about 50 million new deposit account openings each year in the U.S.—even capturing a large number of those account openings at $5/switch implies a smaller than usual market for a venture-backed startup. However, market sizing is inherently challenging for startups: most are attacking potential markets, not existing markets. In this case, one could imagine layering on switching of products like 401(K)s, which would increase LTV and market size significantly.

Payroll-attached lending

Allowing lenders to pull loan repayments directly out of consumers’ paychecks presents a much better way to service loans and a large TAM. Conceivably, any lender would like to have the security of getting direct access to a consumer’s paycheck (with the consumer’s consent), rather than waiting for a consumer to repay a loan out of his or her bank account. Likewise, given the additional security to the loan, consumers would likely benefit from a better rate. However, payroll-attached lending is operationally complex.  

The challenges with this approach are:

• Regulatory hurdles – In some states regulators have required a separate intermediary bank account to be set up for payroll-attached lending, which adds additional friction. There’s also the existential risk that, in an effort to protect consumers from unknowingly garnishing their wages, regulators will disallow this product. 
• “Front page” risk – Put simply, the risk of bad PR. If consumers do not understand the implications of loan repayments being deducted directly from their paychecks when they allow access, there’s risk of backlash against these lenders, as well as their payroll API partners.
• Subprime focus – Subprime lenders with the highest risk of default have the most incentive to pursue payroll-attached lending, and subprime borrowers have the most incentive to permit payroll attached withdrawals to occur. It’s not yet clear whether consumers with good credit will be willing to allow lenders to access their paychecks in this way. Thus, the actual market for payroll-attached lending may be smaller than assumed.
• Complex rollout – Implementing payroll attached lending is complicated. Lenders would need to adjust their underwriting models and work with their servicers to factor in the additional security of payroll access. In addition, some payroll providers don’t currently allow multiple routing. And in the case of multiple lenders, it will be necessary to arbitrate disputes and set the preference order around which debt is most senior.

B2B HR and payroll access

Difficult-to-access payroll data is of particular value to those building enterprise applications. Historically, payroll integration has been painful and time consuming, often taking weeks. This use case builds defensibility as well: the API provider needs to get IT and security approval from the enterprise application team before use, particularly since it contains sensitive data.

The challenges with this approach are:

• Approvals take time – The downside of needing IT and security approvals is that this process often takes time, unlike the direct deposit, where the consumer has agency to sign up themselves. 
• Unknown TAM – While this data is valuable and was previously hard to access, for many enterprise applications its uses are unproven.
• Employee consent – While the payroll data itself is less sensitive—it’s already coming from and being used by the employer—other types of HR data might be more sensitive and require employee consent.

While each approach has its trade-offs, we believe that the most successful payroll-connected API will have the following characteristics:

• An urgent use case – Wide adoption of payroll APIs will require a highly motivated customer, and the more complex the implementation (i.e. servicing loans) the higher the value will have to be. For income and employment verification, for example, API solutions will need to differentiate through dramatically improved coverage, data types, and speed of verification. 
• Recurring use cases – One of the reasons Plaid was so sticky was that fintechs had to frequently update a customer’s data; switching transaction data providers would have meant losing access to historical data and asking the customer to re-authenticate. Similarly, the winning product in this space will have some recurring use-case, which both provides a defensive moat against competitors and the potential for recurring revenue.
• Expansion potential – Companies who focus on a single wedge will have to find a natural expansion path within an organization, selling to multiple buyers or having the same buyer purchase multiple products. There is a clear path for this to happen within fintechs, given that many of them are converging on a similar product strategy (deposits + lending + spending). Whatever company is able to build early momentum in a single space will be well positioned to win in others.

The wild card: Payroll companies

Much as Plaid relies on connectivity to banks for bank data, payroll APIs rely on connectivity to the underlying payroll systems. One interesting dynamic will be how platform accessibility plays out. Banks have a love-hate relationship with Plaid, in that they’re often reluctant to allow consumers to access their data via third parties. That reticence is twofold: fear of issues around information security, as well as around losing direct control of the customer.  

Payroll companies are realizing the power and value of their data and are angling to become part of the economic value chain. Gusto, for example, is launching more partnerships to become users’ financial hub, and ADP is investigating how it might allow consumer-permissioned data to be used for new use cases. There’s a strong precedent for making consumer-permissioned data accessible to third parties (indeed, it shares similarities to the principles governing account aggregation published by the CFPB).   

* * *

Just as Plaid has opened the door to a new wave of fintech integrations, payroll-connected APIs are poised to vastly improve underwriting, upgrade employee-provided financial benefits, and streamline and scale consumer and enterprise fintech companies alike. While we’re realistic about the hurdles to break into this space, we remain enthusiastic about the potential for payroll  APIs and the ambition of the fintech entrepreneurs who are rising to the challenge.