Unit Credit Formula with Fractional Accrual Method

[Guest flogger]

I'm looking for feedback concerning a plan that specifies a unit credit benefit formula and accrues benefits under the fractional method of 411(b)(1)©. I'm looking for some thoughts about how to handle a potential violation of the minimum accruals required under Reg 1.401(a)(4)-3(b)(4)(i)©(1).

One Plan doc I've read specifies (summarized) that the plan will not violate this regulation. However, there is no fail-safe provision in the document.

Is it possible to draft a doc that specifies correction in the event a participant's accrual rate is too high, or too low? Could you either increase the low accrual rate or bring down the high accrual rate? Is there a difference using permitted disparity? Or is the Plan just not in compliance and subject to DQ?

Any thought? Thanks in advance.

[Blinky the 3-eyed Fish]

Not satisfying 1.401(a)(4)-3(b)(4)(i)©(1) means the design is not a safe-harbor and you need to run the general test. You don't give specifics, but consider whether or not it's a non-design based safe harbor.

In asking whether or not corrective language is there or available doesn't make sense. It's the design that is controlling here. Just look at the first part of 1.401(a)(4)-3(b)(4)(i)©(1). It says, "Under the plan, it must be impossible for any employee to accrue in a plan year..." So, the fail-safe languge, if you will, is the language that makes it a safe harbor.

Now if you fail the general testing, then you have 1.401(a)(4)-11(g) as your guidance to make it pass.

[Guest flogger]

My question really is: Can you have fail-safe language that keeps the plan safe harbor? If so, do the corrective measure (ie how are you going to fix it) have to be detailed in the plan doc?

You could either increase the benefits to those with low accrual rates, or you could decrease benefits to those with high accrual rates. I'm sure there may be other fixit solutions. Is any of this possible and still remain safe harbor?

[Blinky the 3-eyed Fish]

My question really is: Can you have fail-safe language that keeps the plan safe harbor? If so, do the corrective measure (ie how are you going to fix it) have to be detailed in the plan doc?

Let me try again. It's not fail-safe language that keeps it a safe harbor; it's the language in the first place that makes it a safe harbor. In other words, it's either a safe harbor or not. It's not possible for it to try and be a safe harbor, but have corrective language in the plan that makes it a safe harbor in case it's not a safe harbor.

So, you need to ask whether it's a safe harbor or not? If yes, skip merrily along. If not, then run the general test. If that fails, seek -11(g).

[Guest flogger]

Ok, very clear. Thanks.