What is the core problem that Finch is solving, and how does the company plan to tackle it?

At Finch, we’re building a universal API for employment systems, which we define as any system with access to employee records. The problem we're solving there is really twofold.

One is fragmentation. If you look at the types of systems within the employment ecosystem, there's HR, payroll, admin, recruiting and staffing, time and attendance, and more. 

Finch is currently focused on HR and payroll, but our goal is to expand this data model across the other employment systems within the sector. 

Now, if you look at payroll or HR alone, there's around 6,000 different systems solely in the U.S. The top 10 of those cover around 55% of the market. 

To draw a quick comparison to Plaid, there's around 11,000 banks in the U.S. and the top 10 cover 75% of the market. 

To get to that 75% mark in our market, an application would have to build 40 or 50 different connectors, so it’s actually way more fragmented than banking.

The second problem is connectivity. 

This whole industry basically operates via files. You’re sending them via SFTP or you’re downloading CSVs and sending them via email to some benefits provider. That report’s going to have all the information, including Social Security number, income, and employment data. As a developer today, I personally do not want to interact with or set up SFTP servers to do the standardizations. 

And while there are some parts of the industry that have moved towards an API-driven model, they tend to have closed APIs that take 12 months of partnerships to be able to get into, and they also take a revenue share on top of that—so it isn’t the standard open API ecosystem that we're seeing in other industries.