How to Choose the Right RPC / TPA

By Ann Slotwinski, Executive Director, The Asteri Collective

Quick summary: 

For most businesses – at least for those with any kind of complexity or variety of employee needs from a retirement and retention perspective – retirement plan design complexity outgrows what a fintech platform can provide. 

The right Retirement Plan Consulting Firm (RPC not TPA) brings a number of things a plug-and-play platform structurally can’t: 

  • Cybersecurity practices built for the vendor chain a retirement plan actually runs on
  • Communication you can build a service calendar around
  • Attention to detail on the testing and errors that cause the most damage
  • Plan design flexible enough to fit each unique business. 

This guide covers how to evaluate an RPC relationship, how Advisors can talk to clients about the value of choosing to work with an RPC, the ROI for recordkeepers who choose RPC-supported plans, and how business owners/ plan sponsors should think about the regulatory complexity an RPC is there to manage.

Every advisor has had this conversation: a client with a growing team asks why they need a TPA at all when a platform will set up a 401(k) with a simple 5 question form and a click. It’s a fair question. The honest answer is that the right setup depends on the business’ goals, structure and circumstances.  A five-person company with a flat compensation structure and no highly compensated employees to worry about might be fine on a self-service platform. A twenty-person company with a mix of owners, key employees, and rank-and-file staff, running nondiscrimination testing every year, is a different question, and that’s where the value of an RPC shows up.

When Does a Retirement Plan Actually Need an RPC?

Plan complexity tends to cross a real threshold somewhere between 10 and 20 employees, not because of a rule written down anywhere, but because that’s roughly where the moving parts start to multiply. More employees means a wider spread of compensation, a higher chance of highly compensated employees (HCEs) triggering ADP and ACP testing, more edge cases in eligibility and vesting, and more room for a payroll coding error to quietly compound over several pay cycles before anyone notices.

Below that range, a plan can often run on autopilot. Above it, the plan needs someone actively managing the interaction between plan design, testing, and payroll data, which is precisely the job description of an RPC. If a client’s headcount, ownership structure, or comp spread is starting to look complicated, that’s the signal it’s time to bring in a consultant rather than lean harder on a platform’s default settings.

What to Look for When Choosing an RPC

Not every RPC operates at the same level, and the differences show up in exactly the places that matter most when something goes wrong.

Cybersecurity Practices That Actually Hold Up

A retirement plan’s data moves through payroll, the recordkeeper, the RPC, and the custodian, and every one of those handoffs is a place a security gap can live. When evaluating an RPC, ask how they move data, whether they rely on standardized, encrypted exchange like SPARK’s API framework or still lean on manual file transfers and one-off uploads, and what their incident response process actually looks like on paper. [We covered the full landscape of vendor-chain exposure and what to ask each party in the chain here], and it’s worth walking a prospective RPC through those same questions before signing anything.

Communication You Can Set a Clock To

The best RPCs operate on a predictable cadence: proactive testing updates before deadlines loom, plain-English explanations of what a compliance issue actually means, and responsiveness that doesn’t require three follow-up emails to get a straight answer. The worst ones go quiet until there’s a problem, then explain it in language built to be technically accurate and practically useless. Ask a prospective RPC to walk through how they’d handle a routine testing failure, and pay attention to whether the answer sounds like a process or an excuse.

Attention to Detail (Where Small Errors Become Big Problems)

Compensation coding errors, missed eligibility dates, and small data mismatches rarely announce themselves the moment they happen. They surface months later, usually during testing or an audit, usually more expensive to fix than they would have been to catch. An RPC’s attention to detail shows up less in what they say and more in how they operate: do they reconcile data proactively, or only when something’s already broken? Do they catch a coding discrepancy in March, or find it during December’s year-end crunch?

Flexible Plan Design, Not a Template

A retirement plan built for a ten-person engineering firm shouldn’t look identical to one built for a twenty-person medical practice with a very different comp structure and ownership mix. A strong RPC treats plan design as something to be built around the client’s actual business, safe harbor structures, profit sharing formulas, vesting schedules, and eligibility rules chosen deliberately rather than defaulted to whatever the platform ships with out of the box. If an RPC’s answer to “can we structure it this way” is usually “here’s how,” that’s the sign of a firm doing real design work instead of running a template factory.

How to Talk to Clients About RPC Value

This is often the harder conversation, because a fintech platform’s pitch is simple and an RPC’s value is more distributed across the life of the plan. A few ways to frame it for clients weighing the two:

  • Ask what happens when something goes wrong. A platform can set up a plan. Far fewer can walk a client through a failed nondiscrimination test, explain the correction options, and manage the IRS filing if self-correction isn’t available. That’s the moment plan complexity actually gets tested.
  • Separate setup cost from total cost. A platform’s low up-front fee doesn’t include the cost of a client’s HR team spending hours untangling a payroll data mismatch, or the cost of a correction filing after a preventable error goes unnoticed for two quarters.
  • Talk about what a human catches that automation doesn’t. Automated platforms are good at running the numbers they’re given. They’re not built to notice that a client just promoted three people into HCE territory and should be thinking about plan design differently next year.
  • Frame the RPC as the client’s advocate, not an added layer. The RPC’s job is to make sure the plan design, the testing, and the compliance work all serve what the business is actually trying to do, which is exactly the role a template-based platform isn’t positioned to fill.

For clients in that 10 to 20 employee range and beyond, this is where the complexity of the plan makes the RPC relationship worth the investment rather than an optional extra.

Recordkeepers: Retention and Plan Sponsor Satisfaction

Recordkeepers watching retention numbers know this pattern well: plans supported by a strong RPC tend to stay put, and plan sponsors on those plans tend to be considerably less stressed. When an RPC is handling communication, testing, and compliance clearly, the recordkeeper isn’t the one fielding confused calls about why a contribution didn’t process correctly or what a testing failure notice means.

That clarity compounds. A plan sponsor who understands what’s happening with their plan, and who has one clear point of contact managing it, is a plan sponsor far less likely to go shopping for a new provider out of frustration. And a recordkeeper working alongside a security-conscious RPC that’s already built around standardized data exchange isn’t the one absorbing the operational load of manual reconciliation or chasing down a data mismatch that originated somewhere else in the chain. The security and plan upkeep an experienced RPC handles isn’t visible in a recordkeeper’s day-to-day, and that’s exactly the point.

Plan Sponsors: Navigating Plan Types and Regulatory Complexity

If you’re a plan sponsor reading this wondering whether any of it applies to you, here’s the short version: retirement plans run on a genuinely dense framework of plan types, contribution limits, testing requirements, and fiduciary roles, and almost none of it is intuitive from the outside. [We put together a full field guide to the numbers and letters behind retirement plan compliance], covering everything from 401(k) versus 403(b) plan types to 415 contribution limits to what a Form 5500 actually is, worth a read if any of this is unfamiliar territory.

One piece worth calling out here specifically: fiduciary responsibility. Many Asteri Collective member firms offer 3(16) fiduciary services, taking on the administrative fiduciary role, signing and filing the Form 5500, and overseeing day-to-day plan operations, so that responsibility doesn’t sit entirely with the plan sponsor. For a business owner already running a company, that’s not a small thing to hand off.

Frequently Asked Questions

What’s the difference between a TPA and an RPC? 

They’re largely the same role. The industry has historically used “TPA” (Third Party Administrator), but the work has evolved well past pure administration into active plan design, compliance strategy, and fiduciary support, which is why “RPC,” Retirement Plan Consultant, is the more accurate term for what the role actually does today.

Do I need an RPC if I’m using a fintech 401(k) platform? 

It depends on plan complexity. A very small, simple plan may run fine on a platform alone. Once a business has a meaningful spread of compensation, highly compensated employees, or more than roughly 10 to 20 employees, the testing and design complexity generally benefits from an RPC’s active management.

What does a 3(16) fiduciary actually do? 

A 3(16) fiduciary takes on administrative responsibility for the plan, including signing and filing the Form 5500 and overseeing day-to-day compliance. Many RPCs, including a number of Asteri Collective member firms, offer this as a service to reduce the plan sponsor’s direct liability.

How many employees before a business needs a TPA or RPC? 

There’s no hard rule, but complexity tends to increase meaningfully in the 10 to 20 employee range, particularly once a business has HCEs, a varied comp structure, or nondiscrimination testing obligations.

How do I evaluate an RPC’s cybersecurity practices? 

Ask how data moves between their systems and the recordkeeper’s, whether they use standardized, encrypted data exchange like SPARK’s API framework, and what their incident response process looks like. [This resource covers the full set of questions worth asking any vendor in the chain].

The Bottom Line

Choosing an RPC isn’t about picking the biggest name or the lowest fee. It’s about finding a firm whose cybersecurity practices, communication habits, attention to detail, and design flexibility match the actual complexity of the plan you’re building. For advisors, that’s the conversation worth having with clients before a testing failure forces it. For recordkeepers, it’s the difference between a plan sponsor who stays and one who starts shopping around for that care and attention they feel tehy are missing. And for plan sponsors, it’s the difference between navigating the system or having to pick up the pieces of mistakes down the line.

Ann Slotwinski is the Executive Director of The Asteri Collective, a coordinating network of Retirement Plan Consultant and Third Party Administrator firms built around a collaboration-over-competition model.