ICHRA is scaling. The infrastructure has to scale with it.
Reflections from the AIM 2026 panel: Building the Rails of the ICHRA Ecosystem
A few weeks ago, Remodel Health’s annual Aligning ICHRA Minds conference brought some of the best minds in the benefits industry together with a common goal: maintaining ICHRA’s trajectory as it moves from the early-adopter phase into the mainstream.
I had the privilege of joining Ideon and Paylocity on a panel moderated by Remodel Health at this year’s conference, and the conversation reinforced something I’ve been thinking about since I started working in the benefits space: the biggest risk to ICHRA’s trajectory isn’t demand, but whether the infrastructure behind it can keep up.
The demand signal, after all, is unambiguous. ICHRA enrollment tripled going into 2026, employer retention sits at 92%, and broker understanding has matured considerably. But the operational rails that support plan administration haven’t kept pace with that acceleration.
Closing that gap is critical, because the flexibility, cost control, and employee choice that ICHRA promises only fully delivers if the underlying infrastructure is reliable.
Fragmented infrastructure is the real risk to ICHRA’s growth
The last mile of ICHRA administration is still largely manual for most mid-market employers: getting the right employer contribution into the payroll system, coded correctly, and on time. Employees can easily enroll through their ICHRA provider’s platform, but then someone has to make sure the right amount actually lands in payroll. That handoff, from automation to manual work, is both time-consuming and where the process tends to break down.
There is an operational maturity curve that begins with fully manual processes, advances to flat file- and SFTP-enabled workflows in the middle, and ends with real-time API automation. Most of the ecosystem sits somewhere in the middle. On the advanced end, some of the largest players have made meaningful progress toward full API-powered automation; but many are still relying on batch processes and nightly files.
That has significant downstream consequences: eligibility decisions made on stale data, lagging termination events, and operations teams absorbing hours of monthly reconciliation work that’s largely invisible to everyone else. If the infrastructure doesn’t mature at the same rate as adoption, that operational friction becomes a growth ceiling.
Why building these rails is so difficult
To truly automate and modernize ICHRA administration, a host of information sources need to be consolidated into a single data flow. Enrollment, eligibility, payments, and payroll aren’t separate bets; but some parts of this flow have matured faster than others.
Enrollment platforms, for example, can now quote in high volumes with robust carrier network comparisons, and payment processing infrastructure has matured to the point where premium collection and remittance are largely automated. The payroll automation side, and how payroll data feeds back into eligibility, is where the ecosystem still has significant ground to cover.
That’s because several structural challenges make payroll unification exceptionally difficult, from the lack of an industry data standard to long-tail systems without APIs. Then there’s the scale of the problem: there are over 600 payroll systems in the US. Even to cover 80% of the market, you’re looking at roughly 200 systems.
No individual ICHRA administrator has the resources to build and maintain that many integrations, which is why an aggregation approach is structurally necessary and why Finch is investing so heavily in this infrastructure.
What Finch is doing about it
Finch is building the rails that will enable ICHRA to scale. Our unified API lets ICHRA providers and payroll systems securely share data in order to automate payroll and power eligibility loops. Finch has built hundreds of payroll connections that are accessible through a single integration, so ICHRA administrators don’t have to build and maintain those connections themselves.
When the ecosystem depends on an aggregation layer, that layer has to be held to a high reliability standard — uptime and data quality are the product. At Finch, reliability is my number one product priority.
Today we’re focused on deduction write-back automation and reimbursement write-back across the highest-volume payroll providers, expanding coverage methodically across the provider network. On the read side, we’ve seen ICHRA activity on our platform double over the past year, a signal that administrators are actively moving from manual processes and flat files to API-first connectivity.
Our next horizon is closing the upstream gap: pulling enrollment data directly from benefits administration platforms so the data flow is complete end to end, without requiring manual handoffs at the enrollment layer. This is a direct response to what we’re hearing from customers: they have the payroll data and the roster, but enrollment information still lives in a separate system that requires manual reconciliation. It’s a 12–18 month investment for us, and one that we believe will meaningfully reduce the operational burden on administrators.
The broader principle is that the same rails that handle major medical can handle dental, vision, and HSA the infrastructure doesn’t need rebuilding for each benefit type. It needs to be built right once, and then it scales.
Once the rails are reliable, benefit choice can expand. The infrastructure question isn’t a distraction from ICHRA’s growth story. It is the growth story. The companies investing in these rails now are the ones that will be ready for what ICHRA becomes next.
Ready to automate deductions and reimbursements? Explore Finch for ICHRA →



