Finch builds universal employment API

Diving deeper into

Jeremy Zhang, CEO of Finch, on building a universal API for employment systems

Interview
it’s actually way more fragmented than banking.
Analyzed 4 sources

This reveals why Finch is valuable as infrastructure, not just as a connector. In banking, a developer can reach most users by integrating a relatively concentrated set of institutions. In payroll and HR, the same coverage requires dozens of separate integrations across thousands of systems, many with weak APIs or no APIs at all. That makes standardization, maintenance, and partner relationships the real product.

  • Finch’s customers are not trying to read one employee’s paystub. They often need company wide payroll and directory data, or they need to write deductions back into payroll. Human Interest used Finch to automate payroll deductions for much of its base, which shows why one missing connector can break an entire workflow.
  • The fragmentation is structural. Finch tracks more than 6,000 HR and payroll systems in the US, and its product connects to more than 200 of them. Many underlying systems still move records through .CSV files, SFTP feeds, or manual operations, which is far messier than bank connectivity built around a smaller set of institutions.
  • This also explains the split with Plaid and Pinwheel. Plaid aggregates bank accounts for consumer fintech workflows, while Pinwheel focuses on employee permissioned payroll data for use cases like income verification and direct deposit switching. Finch instead connects employers to apps, which means broader admin workflows and a much wider long tail of system types.

The next step is that the connector layer turns into a control layer for employment data and payroll actions. As more benefits, lending, insurance, and back office software plug into payroll, the winner is the company that not only reaches the long tail, but can reliably read and write the core primitives every app needs.