MoJo

Can't say what the answer is without seeing the actual documents, but our solution is simple. Our "standard" loan policy says all vested sources are "lienable" (i.e. count for purposes of calculating the maximum amount available for a loan), but only "x, y, and z" (or whatever) are "loanable" (i.e. are the source of funds available to fund the loan (and may be limit it below the legal max loan available). The English language is so ... wierd ... just be crystal clear. And by the way, we'll take the plan on - away from our friends at Principal!

I concur, Bill - and further comment that in todays digital age, a lot of this is actually done on-line, via a service provider's website - which is NEVER checked by either the plan sponsor/fiduciaries or the (directed, ministerial - NON-FIDUCIARY) service provider (who shouldn't do so), until the claim is filed. It really is an "unseen by human eyes" scenario that is pretty common these days.

#2 - as those are the letters that differentiate between the two words. But then again, for efficiency sake (and for the same reason), we could just go with "R" and "E"... 😁

We take the position that a bene form is of no value until it becomes operative (i.e. when the participant dies.) It is then, and only then that anyone reviews the document - and anything that happened before that is of no consequence. Not saying someone doesn't take a glance at it and help the participant on occasion, but not as a fiduciary to the plan or the participant. Too many possible intervening issues that can render a bene designation invalid (death of a bene, divorce, law change, plan change, etc.) We recently had TWO bene forms that names their "fiancé" as a bene (by specific name). In one case, they got married, then divorced, then the participant dies. Divorce intervened and the bene naming the "fiancé" is invalid. In the other case, they never married, split up (up a decade ago) and the kids (from a prior marriage) are questioning why the ex-fiancé is getting 25%. Sorry. No intervening event, and we think the bene form is valid. Long story short - not a good idea to police something not necessarily operative - BUT, not a breach of a fiduciary duty (to whom? - the bene's were only contingent (speculative) recipients of plan assets). When in doubt, interplead the money to the court and let them sort it out.

Well, we prove ADP wrong often. It's the approach you take in conveying the information. We discuss it, but then produce regs, secondary source write-ups, our write-ups, and let them talk to the experts (me and my team!) who have a knack at being persuasive!

Until the DOL questions why the form 5500 doesn't contain all of the assets... Or the plan auditor qualifies the audit because the held away assets weren't included. Or a competitor (like us!) come a knocking telling your client they are getting bad advice.... 🙂

I think that the asset transfer date is wholly incorrect, and unsupportable in the law. The "documents" govern the terms of the plan (and the merger), NOT THE inability of others to move assets. Indeed, in some cases, it take years for assets to move (try getting assets out of TIAA's general account product). ADP apparently already has assets for the surviving plan, and if they can't then take on the new participants, and the data provided to them, time to FIRE them. I work for a service provider and we do this all the time.....

We use the "legal" date as the date of the plan merger. Transfer of assets is irrelevant - as, as of the legal date, those assets belong to the surviving plan, despite being held elsewhere. One plan from the merger date forward, but perhaps two custodians (and maybe even two trustees). Add them together and go forward.....

Now we get into what is "irrevocable." It's possible to "reverse" a transaction even after the check is mailed. Or even after the money has been received by an IRA custodian. Or even after received by the participant and check is cut (depends on how motivated they are to return the money). Not saying it's a best practice, but it happens. The problem with drawing that line is that even a distribution request where the order to liquidate funds is received by 4:00 ET (NYSE closing) won't have any possibility of a check being cut until 1/2 of the following year. Distribution when received in year 1, or when proceeds received and check cut in year 2? My treasury department friends HATE this time of year. And they detest this time of year currently because of the CRD issues.....

That raises a question. If the trade "order" had been placed to liquidate investments, and that order is irrevocable, is the money in the trust? Are the proceeds from that trade despite being earmarked for a distribution still in the trust? If the money is in a common distribution account, but the check hasn't been cut mean the money is still in the trust? Everybody has their own definition of "processed." I can argue either side of the question(s) - but I'm a lawyer and paid to do so! 🙂

Well, our system is tied to the "check cut" date. It's semi-automated. So if the date of the check is 12/31/2020, it's a 2020 1099. However, we had a handful that didn't get processed in 2020, despite the request being in - and that is the issue. And that is the issue SPARK discussed (with no resolution). Some are taking the approach that if the delay was "not the fault" of the p[participant, the request should be honored (but that still leaves the issue of the date of the 1099. We actually had requests come in on 12/30 (at best, and I mean at best) it's a three day process to get to a check cut) and unholy heck is being raised. Sorry - but that is the "fault" of the participant. We set a deadline to "guarantee" processing which was sufficiently before the 12/30 deadline in order to process - and communicated that widely.

SPARK members have met to discuss this (I would expect virtually al R/K'er have some variant of this issue (we do). Counsel to SPARK was on the call as well, and while not giving specific "legal" advice, indicated that *if* the money were out of the trust by the deadline (as in a common distribution checking account), arguably the deadline was met even though the check wasn't cut till the next day(s). BUT, there is a major 1099 issue - as to which year it is taxable in - if the check didn't go out until 1/4/2021.... No resolution....

Start from the premise that the rate is reasonable at inception. I don't think this becomes a "springing" PT simply because of this issue. It must be commercially reasonable when issued. But then again, when I worked for a bank, and we went to the lenders to determine "commercially reasonable" terms, the lender laughed, and said there was no way to make it commercially reasonable given ERISA's rules, and other factors.... I agree, it can result in an additional contribution to the plan under some circumstances. I've never seen that happen (and usually the complaint goes the other way - "you're charging me too much interest.") But, it is what it is, and that's the way OMNI (and others) work.

I believe it is a continuation....

What C.B. and Peter bring up has been my concern for decades. I would argue that there is a presumption that a prudent fiduciary would not turn away a plan debtor bearing money to reduce that debt. The problem is, is that the way a prepayment works on OMNI is that it simply is applied to the next payment (or more) and does NOT adjust the interest payable over the life of the loan (as a prepayment on a mortgage or auto loan would do). That means simply that when the loan is issued, the total amount due (principle and interest) is set in stone and doesn't change. If a participant wants to pay off the loan in it's entirety, the "payoff amount" is the total of all future payments, which include interest not yet "earned." I do not understand why the programmers of OMNI (and other r/k systems I seen) can't handle loans like a bank does. After all, the purveyor of OMNI is FIS, which is a large fintech company that provides bank software for virtually every banking need - including loans. Around our shop. we simply say "loans are evil." 'nuff said.

As noted above, the plan can request a rollover (and usually it's through the financial service provider who does so) - AND - if the funds are still in the (IRA) rollover account, the owner now has NON-ROLLOVERABLE funds in that account, triggering an excise tax due each and every year they remain in that account. If the money went into a subsequent employer's plan, they now have a qualification issue if not corrected. Debt collector, though, is a bit extreme. We (a recordkeeper) work with recipient custodians/plans to get the money back (adjusted for losses or gain) - and there is a semi-formal process for doing so (and usually involves hold-harmless agreements).

Nothing is in writing yet....

POAs are invalid post death. They only allow the holder to do that which the grantor of the power could do. I would suggest the grantor can't request a distribution post death - so neither can the POA holder. As David said, check the plan for what happens upon death - and see if there is a default beneficiary.

Guilty....

Luke: Let's not get too academic here - but until paid, the money (even though we "allocate it" to a participant's account" is NOT the property of the participant. It is the property of the trust, and one of the requirements of trusts under ERISA is that "all" of the money is available at "all" times to pay the benefits promised. DC plans make it seem like the money belongs to a specific participant, but "legally" it doesn't. A loss of any one participant's account balance is by definition a loss to the plan.

I'm not sure how you can conclude it is inconsistent with 2020-50. That notice specifically provided a safe harbor, and specified that there were other reasonable alternatives (PLURAL), and then provided ONE example of such a reasonable alternative. Granted, using something else puts the burden on the user to prove it's "reasonableness" but it isn't ruled out....

We are. We aren't Fidelity, but we aren't chopped liver, either (11,000 plans, $55 billion or so in assets). Read the regs - they "clearly" say one safe harbor, and other reasonable alternatives - with only one of those alternatives being used as an example. If there are other alternatives that are "reasonable" apart from the safe harbor of the one example, it *must* do exactly what you say can't be done.

I don't buy the 404(c) argument - nor the do I believe the DOL would. This is not an "investment decision" by the participant, it's an "obligation" that the plan fiduciaries must create consistent with plan documents (including a loan policy) and 2) in a commercially reasonable manner. Both have fiduciary implications. Now, those conditions occur at the time the loan is issued - but it raises the issue as to 1) what steps do plan fiduciaries have to take to ensure compliance; and as a part of that 2) how much information should they gather, and what to do with information once gathered (whether intentionally or not). In modern administration of a plan, recordkeepers handle most of that on an outsourced basis, and so 99.9% plus are non-issues. But one does uncover nefarious attempts from time to time (we see one or two a month out of the thousands of loan requests that come in) when an attempt is uncovered we go back to the plan fiduciaries for a decision. Keep in mind that this could be a loss to the PLAN, even though the participant isn't harmed. Different responsibility, and one that triggers consequences for the asleep fiduciary. As I said, as a percentage of loan requests that we receive, a handful are caught where it appears the participant is playing fast and loose with the rules. Amazing though how many loans are defaulted without a single payment ever having been made....

Two things. Employers routinely outsource loan approval to recordkeepers. So, no employer intervention, and unless the r/k spots something amiss among the thousands of loan requests received in a given period of time, the employer wouldn't know (and hence no collusion). Second, there is "fiduciary" risk, regardless of plan qualification risk

We're doing as TIAA is doing. Requiring reamortization as of 1/1/21 does not give full effect to the law, which allows one year deferral. Restarting regular loan payment on 1/1/21 while still deferring 2020 payments until the year is up (discussed in the IRS guidance as "one" of the "reasonable alternatives") is simply not workable for recordkeepers using core OMNI functionality (where any new loan payment made is automatically applied to the longest outstanding missed payment (which means, the 1/1/21 payment is applied to a "deferred payment." The TIAA option was discussed, Groom law said it appeared "reasonable" and SPARK, ICI, ACLI, ARA and it's subsidiaries ALL discussed it in their comment letters to the IRS, asking that the IRS *NOT* eliminate any of the 3 options, and only provide a "safe harbor" while not ruling out the alternatives. That's what the IRS did - a safe harbor, with "other reasonable alternative" and they provided an example of only ONE of the reasonable alternatives, leaving the door open. In case you haven't heard it before, but loans are evil. Temporary changes/extensions/requirements to loans (such as CARES Act loan changes) make loans positively hellish. We can incur the time or expense to reprogram entire systems for something that has a short shelf life.