Administer 401(k), 403(b), 457(b), Defined Benefit, and Pooled Employer Plans from a single, audit-ready system built for TPAs, sponsors, and recordkeepers. The current state: retirement administration lives in too many places If you administer employer-sponsored retirement plans for a living, you already know the shape of the work. A single plan touches recordkeeping , contribution processing , compliance testing , participant management , government filings, and year-end reconciliation. Multiply that by dozens or hundreds of plans, each with its own document, eligibility rules, vesting schedule, and payroll feed, and the operational surface area becomes enormous. Today, most third-party administrators (TPAs), plan sponsors, and recordkeepers stitch this together from a patchwork of tools. A recordkeeping ledger sits in one system. Compliance tests run in spreadsheets or a separate testing engine. Contribution files arrive by email, SFTP, or a payroll portal and a...
Get link
Facebook
X
Pinterest
Email
Other Apps
RetireCore PEP: Pooled Employer Plan Administration, One System
Get link
Facebook
X
Pinterest
Email
Other Apps
-
Pooled Plan Provider operations, per-employer isolation, per-employer compliance testing, and pooled reconciliation that still ties out to the penny — administered from one audit-ready platform built for PPPs, TPAs, and aggregators.
Per-Employer Isolation
Row-level data separation between unrelated employers, verified on a live database.
§413(e) Testing
Compliance run per adopting employer, not pooled in a way that hides a failure.
Pooled Reconciliation
$0-variance reconciliation across the whole pool, proven at multiple sizes.
Straight-Through + Human
Routine work automated; every money move waits for human approval.
Local-First Privacy
Runs on your own infrastructure under GLBA and DOL cybersecurity expectations.
Built to Scale a PPP
Onboard new adopting employers as configuration, not a custom rebuild.
The current state: PEPs are a new structure running on old, single-employer assumptions
The Pooled Employer Plan, created by the SECURE Act and available since 2021, is one of the most significant structural developments in the retirement industry in years. A PEP allows unrelated employers — with no common ownership, no shared industry, nothing connecting them except a decision to join the same plan — to participate in a single retirement plan administered by a Pooled Plan Provider (PPP). For a small or mid-sized employer, that means access to institutional-scale plan administration, pooled buying power, and a single named fiduciary taking on much of the administrative and fiduciary burden that employer would otherwise carry alone.
The appeal is real, and adoption has grown steadily since PEPs became available. But the operational reality behind that appeal is genuinely complex, and it is complex in a way that is specific to this structure. A PEP is not one employer's retirement plan with more participants — it is many adopting employers, each with its own payroll cadence, its own eligibility rules within the bounds the PEP document allows, its own contribution stream, and its own compliance testing obligations, all rolling up under one plan document, one recordkeeping structure, and one Pooled Plan Provider accountable for the whole arrangement.
Much of the software administering PEPs today was built for a single-employer plan and then stretched to accommodate multiple employers, often by layering employer identifiers onto what is still fundamentally a one-employer data model. That approach can work at a small scale, but it strains as a PPP's employer count grows, and it creates exactly the kind of ambiguity — about whose data is whose, and whether one employer's testing accidentally touched another's — that a fiduciary structure like a PEP cannot tolerate.
The pain point: where a multi-employer rollup creates risk that a single-employer plan never has to face
A PEP concentrates a set of operational challenges that simply do not exist, or exist in a much smaller form, in a single-employer plan. Here is where the friction and the fiduciary exposure concentrate:
Per-employer payroll and eligibility, at scale. Each adopting employer sends its own payroll and contribution data, on its own cadence, and applies eligibility rules that must stay within the PEP's overall plan design while still reflecting that specific employer's workforce. Reconciling dozens or hundreds of separate payroll feeds by hand does not scale, and every manual touch is a chance for one employer's contribution to be posted against another's participants.
The §413(e) compliance boundary. Certain compliance testing in a PEP — most notably nondiscrimination testing — must generally be performed per adopting employer, not pooled across the entire plan. A system that runs testing at the plan level rather than respecting the §413(e) employer boundary can produce a result that looks clean in aggregate while masking a real failure at one specific employer.
Data isolation between unrelated employers. Because adopting employers in a PEP have no relationship to each other beyond the plan itself, each employer's participant data, census, and compliance results need to be genuinely walled off from every other employer's — not just filtered in a report, but isolated at the data layer. A breach of that isolation, even an accidental one where one employer's staff could see another's participant data, is a real problem for a PPP whose entire value proposition rests on trust.
Reconciliation across a pool, not just a plan. The PPP still has to prove that the numbers add up — not only within each employer's book, but across the pooled plan as a whole, as contributions, distributions, and forfeitures move through potentially dozens of separate employer relationships simultaneously.
The compliance and administrative burden the PPP is supposed to absorb. Part of the PEP's appeal to a small employer is that the PPP, as named fiduciary and plan administrator, takes on most of the day-to-day compliance and administrative load. If the PPP's own systems cannot actually absorb that load without heavy manual intervention, the promise of the PEP structure — lower burden for the adopting employer — does not hold up in practice.
Onboarding and offboarding employers without rebuilding process. A PPP's growth model depends on being able to onboard new adopting employers efficiently and, when necessary, offboard one without disrupting the rest of the pool. A system built around a single-employer assumption tends to require custom setup work for every new employer, which caps how fast a PPP can actually grow.
The cost of getting any of this wrong is not abstract. A testing result that pools data across employers when it should not, a data-isolation gap between two unrelated employers, or a reconciliation break that cannot be traced back to the specific employer it originated from is a serious problem for a PPP that has taken on named-fiduciary status for every employer in the pool — and it undermines the exact trust-based value proposition that makes a PEP attractive in the first place.
RetireCore for PEP: built for the Pooled Plan Provider, not retrofitted from a single-employer plan
RetireCore from HolyByte Innovations is an enterprise retirement plan administration platform, and its PEP build is designed from the ground up around the multi-employer structure a Pooled Plan Provider actually runs — not a single-employer plan with employer tags bolted onto it afterward. RetireCore is a B2B2B2C platform: it is built to be the rails a Pooled Plan Provider, TPA, or RIA/aggregator runs on to serve the many adopting employers, and through them, the participants, inside their pool.
The core design principle is straight-through processing with a human firmly in the loop: payroll intake, posting, reconciliation, and compliance testing run automatically for the routine work, while every material action — a movement of money, a compliance correction — waits for a human approval before it takes effect, and that approval is logged with the model version behind any AI-assisted recommendation. The result is lower cost to serve a growing pool of employers, and a process that is defensible if a regulator ever asks how a specific decision was made.
RetireCore's PEP build runs entirely on the buyer's own infrastructure, keeping the AI-based document verification local-first by default, with paid cloud AI available only as an opt-in behind a data-residency guard — a real advantage for a PPP operating under GLBA and DOL cybersecurity expectations across many unrelated employers' data.
Key features for PEP administration
Every capability below addresses a challenge that is specific to running many unrelated employers through one plan, rather than a generic administration feature with a PEP label attached.
Per-employer isolation, proven at the database layer
Each adopting employer's data is isolated using row-level security in the underlying database, not merely filtered in a report or a screen. That isolation has been verified on a live database, so a PPP can demonstrate, not just assert, that one employer's participant data is genuinely walled off from every other unrelated employer sharing the pool.
Compliance tested per employer, respecting the §413(e) boundary
Nondiscrimination and other required testing runs at the individual adopting-employer level, consistent with the §413(e) boundary that governs how testing must be performed in a PEP, rather than pooled across the entire plan in a way that could mask a failure at one specific employer while the aggregate result looks acceptable.
Straight-through processing, with material actions held for human approval
Payroll intake, posting, reconciliation, and routine compliance checks are automated end to end for each adopting employer, clearing the large majority of routine administration without a human touch. Anything material — an actual movement of money, or a compliance correction — is escalated to a human-approved queue and refused without that approval, regardless of how confident the underlying recommendation is, with every approval logged against the specific AI model version that generated the recommendation.
Correctness you can audit, across the whole pool
An append-only ledger and bitemporal corrections mean any account balance can be reconstructed as of any date, and every dollar is tracked in exact integer cents rather than floating-point approximations that can drift at scale. Reconciliation is proven to hold — $0 variance — at multiple pool sizes, so the same correctness that works for a small pilot pool continues to hold as a PPP's employer count grows.
Local-first privacy as a structural feature
Document verification defaults to free, local-first OCR, keeping participant documents on the PPP's own infrastructure. Paid cloud AI is available but strictly opt-in, gated behind a data-residency guard — a meaningful advantage for a PPP whose entire pool of adopting employers is trusting it with sensitive participant data under GLBA and DOL cybersecurity scrutiny.
A live operations console built for the PPP's day-to-day
The platform provides a command-center view across the PPP's client employers: per-employer payroll cadence and compliance status, a working AI approval queue where a governed recommendation can be approved or rejected directly, and a pooled reconciliation view that ties the whole pool out to the penny alongside each individual employer's own numbers.
A revenue engine the PPP owns
Because RetireCore for PEP is sold as an owned system rather than a per-seat subscription, it ships with a complete fee and billing subsystem so a PPP can run its own participant economics — per-participant/year fees, asset-based basis-point fees disclosed under 404a-5, platform or white-label fees, and revenue-share levelization — keeping the fee income the platform generates rather than sharing it with a SaaS vendor on an ongoing basis.
Onboarding designed for growth
Because the multi-employer structure is native to the platform rather than layered on afterward, bringing a new adopting employer into the pool is a configuration exercise within the existing system rather than a custom build. That is what allows a PPP's employer count to grow without a corresponding multiplication of manual setup work.
Honest about the trust infrastructure still being built
RetireCore for PEP is positioned deliberately and honestly: the underlying technology is pilot-ready today, verified with hundreds of automated tests and live reconciliation across multiple pool sizes. The path to full production readiness for ERISA plan sponsors runs through trust infrastructure that sits outside the software itself — SOC 1 Type II and SOC 2 attestation, ERISA-counsel validation, a custodian or trustee partnership, cyber insurance, and disaster recovery. A PPP evaluating the platform is told plainly which of these are in place and which are in progress, rather than being told everything is production-ready before it actually is.
Watch the RetireCore PEP demo
Who it is for, and how it changes the day-to-day
RetireCore's PEP build is aimed at Pooled Plan Providers, TPAs, and RIA/aggregators that are either launching a PEP or already running one and looking to scale it without proportionally scaling headcount and risk. It is not sold to individual plan sponsors or participants directly — it is the operating infrastructure the PPP runs, on behalf of every adopting employer and participant in its pool.
Consider a PPP bringing a new employer into an existing pool. In the fragmented, single-employer-shaped model, that means custom setup work, a real risk that the new employer's data gets commingled with an existing employer's during that setup, and testing that has to be manually scoped to the new employer alone rather than accidentally pooled with the rest. With RetireCore, the new employer is onboarded into a system that was built for exactly this structure: its data is isolated by design, its compliance testing runs at its own employer level automatically, and its payroll and contribution activity reconciles against the pool without disturbing any other employer's book. The PPP absorbs the administrative burden the PEP structure promises to the adopting employer — and can prove, with a verifiable audit trail, that it is doing so correctly.
Frequently asked questions
What is a Pooled Employer Plan, and who is RetireCore for PEP built for?
A PEP allows unrelated employers to participate in a single retirement plan administered by a Pooled Plan Provider. RetireCore for PEP is built for the Pooled Plan Providers, TPAs, and RIA/aggregators who run that plan — not for individual plan sponsors or participants directly.
How does RetireCore keep unrelated employers' data separate within one pooled plan?
Each adopting employer's data is isolated using row-level security at the database layer, not just filtered in reports, and that isolation has been verified on a live database. This matters because adopting employers in a PEP have no relationship to each other beyond the plan itself.
Does compliance testing run per employer or across the whole pool?
Per employer. RetireCore runs nondiscrimination and other required testing at the individual adopting-employer level, consistent with the §413(e) boundary that governs how PEP compliance testing must be performed, rather than pooling results across the plan in a way that could mask a single employer's failure.
What role does AI play, and can it move money on its own?
AI-assisted recommendations handle the routine, high-volume work, but no material action — any actual movement of money or a compliance correction — is ever taken without a human approval, regardless of how confident the recommendation is. Every approval is logged along with the model version that produced the recommendation.
Is RetireCore for PEP ready for a live ERISA-covered plan today?
The underlying technology is pilot-ready and has been verified with hundreds of automated tests and $0-variance reconciliation across multiple pool sizes. Full production readiness for ERISA plan sponsors also depends on trust infrastructure outside the software itself — attestations, a custodian partnership, cyber insurance, and disaster recovery — which is why the current path forward is a shadow-mode pilot alongside a design-partner PPP or TPA.
How do we see RetireCore for PEP in action?
RetireCore is an enterprise platform, so the best next step is a guided demo tailored to your pool. Reach out through our contact page and we will walk your team through the multi-employer workflows that matter most to your PEP.
This article is general information about retirement plan administration and the RetireCore platform. It is not legal, tax, actuarial, or compliance advice. Regulatory citations are provided for convenience and should be verified against current IRS, DOL, and ERISA guidance. Compliance-critical output should be reviewed by a qualified TPA, ERISA counsel, or CPA before you rely on it for a filing.
Ready to simplify Pooled Employer Plan administration?
See how RetireCore isolates every adopting employer, tests compliance at the right boundary, and reconciles the whole pool to the penny.
ADP/ACP, top-heavy, 402(g) and 415 limits, safe harbor, Roth, vesting and force-outs — administered from a single audit-ready platform built for TPAs, sponsors, and recordkeepers. ADP/ACP & Top-Heavy Testing Run §401(k) nondiscrimination and §416 tests against a clean, current census. Recordkeeping & Reconciliation Live participant reconciliation that ties to the penny before any filing. Loans, RMDs & 1099-R The full transaction lifecycle with correct withholding and tax codes. Safe Harbor & Roth Eligibility, vesting and money sources driven straight from the plan document. Daily NAV Pricing 4PM-cutoff valuation with connectors to major custodians and recordkeepers. Audit-Ready & Private A tamper-evident trail, running entirely on your own machine. The current state: 401(k) administration is many disconnected jobs pretending to be one The 401(k) is the workhorse of the American retirement system, and administering one is deceptiv...
Introducing HolyByte Innovations Smart software, practical tools, and digital products built to give people and businesses their time back — without the bloat, the steep learning curves, or the endless subscriptions. Explore our products Every single day, millions of us lose hours to work that a computer should be doing for us. We copy leads from one screen into a spreadsheet by hand. We reformat the same documents over and over. We edit videos frame by painstaking frame. We post the same update across a dozen platforms, one tab at a time. It adds up — and it quietly steals the hours that could have gone into the work that actually matters. HolyByte Innovations exists for one simple reason: that time belongs to you, not to busywork. This is our introduction to the world — who we are, why we started, what we build, and what you can expect from this blog. If you have ever felt that your tools were working against you instead of for you, you are exactly the per...
Administer 401(k), 403(b), 457(b), Defined Benefit, and Pooled Employer Plans from a single, audit-ready system built for TPAs, sponsors, and recordkeepers. The current state: retirement administration lives in too many places If you administer employer-sponsored retirement plans for a living, you already know the shape of the work. A single plan touches recordkeeping , contribution processing , compliance testing , participant management , government filings, and year-end reconciliation. Multiply that by dozens or hundreds of plans, each with its own document, eligibility rules, vesting schedule, and payroll feed, and the operational surface area becomes enormous. Today, most third-party administrators (TPAs), plan sponsors, and recordkeepers stitch this together from a patchwork of tools. A recordkeeping ledger sits in one system. Compliance tests run in spreadsheets or a separate testing engine. Contribution files arrive by email, SFTP, or a payroll portal and a...
Comments
Post a Comment