Finch as Plaid for Payroll
Jeremy Zhang, CEO of Finch, on building a universal API for employment systems
Finch matters because it turns payroll from a closed back office system into programmable infrastructure that dozens of modern employment products can build on. As payroll and HR split into separate specialist tools, every benefits, lending, insurance, and HR app needs the same basic job done, read employee and pay data, then write changes like deductions back into payroll. Finch sits in that junction and sells the connective tissue once, instead of every customer rebuilding it themselves.
-
The pain is unusually concrete. There are about 6,000 HR and payroll systems in the U.S., the top 10 cover only about 55% of the market, and reaching 75% coverage would require roughly 40 to 50 connectors. That is why teams like Human Interest ended up with both dozens of in house integrations and large operations teams doing manual CSV and SFTP work.
-
Finch is closer to Plaid in business model than in product surface. Like Plaid, it aggregates fragmented systems, standardizes one data model, and handles partner access on behalf of customers. But Finch goes deeper into employer workflows, not consumer account linking, with products for org data, pay data, and writing deductions into payroll rails.
-
Rutter shows the same pattern in another vertical. As commerce software unbundled, lenders and software vendors needed one API for many storefronts and accounting systems. Finch is the employment version of that playbook, built for a market where the source of truth is payroll, and where write access into payroll is what unlocks retirement, health insurance, and other benefits workflows.
The next step is moving from data access to transaction rails. Once Finch is the default layer for reading records and writing deductions, it can expand into reimbursements, benefits enrollment, and other payroll actions. That pushes it from integration vendor to core infrastructure for the unbundled employment software stack.