Modernizing FIS Relius-based administration workflows.

Why Relius-centered firms revisit their workflow

FIS Relius has been a core system for many independent TPAs for a long time. FIS describes Relius Administration as supporting a wide range of plan types, including 401(k), profit sharing, defined benefit, 403(b) and cross-tested designs, and as available both as a locally installed application and as a hosted (ASP) service. Few firms revisit that choice because the testing engine is weak. They revisit it because of the work that happens around it.

In a typical Relius-centered practice, census data arrives by email in several layouts, is cleaned in spreadsheets, imported for testing, and then re-keyed or re-imported into the recordkeeper portal, the billing spreadsheet, the deadline calendar and the workflow tool. Every hand-off is a place where a correction made in one system does not reach the others.

Step 1: map the work, not the software

Before comparing products, map one plan year for three representative plans. Write down every system that touches the data, every export and import, who does it and how long it takes. Most firms find the same pattern: the administration system is the system of record for testing, but not for the operational state of the plan. Deadlines, exceptions, payroll problems and billing live elsewhere.

That map tells you what modernization should target. If the biggest cost is census clean-up, look at validation at intake. If it is payroll reconciliation, look at a ledger that checks each remittance against the census. If it is chasing deadlines, look at a per-plan calendar tied to the work.

Step 2: choose a modernization pattern

Wrap. Keep Relius for administration and testing, and add tools around it: a workflow or CRM product, a payroll data service, better spreadsheets. Lowest risk, but the data is still copied between systems.

Integrate around one data model. Move intake, ledger, deadlines and billing onto one platform, and keep Relius for what it does best while you evaluate. Data still leaves Relius as exports, but every downstream step reads one copy.

Replace. Move administration and testing to a different system. Highest effort. Only sensible after a parallel run proves the new system produces the same results for your plan designs.

Step 3: decide with a parallel run

Whatever you choose, prove it on your own plans. Export de-identified census, payroll and balance data for 3 to 5 plans with different designs. Process them in the new system. Compare eligibility, contributions, ADP/ACP and top-heavy results line by line against Relius output, and explain every difference before you trust the new numbers.

Agree the acceptance criteria before the run: which results must match exactly, which differences are acceptable and why, and who signs off.

Where KinetiPlan fits, honestly

KinetiPlan is built for the second pattern. In its pilot build, payroll intake, the pooled trust ledger, ADP/ACP, 410(b), top-heavy, 402(g) and 415(c) testing, the compliance calendar, billing and Form 5500 data share one database. It does not offer plan documents, defined benefit or cross-testing, and it has no direct Relius connector: data moves by CSV export. If your plan mix depends on those capabilities, keep them in Relius.

See the Relius modernization page for the parallel-run path.