Engineering, analytical and operations. These are the three distinct and dynamic categories (“stacks”, perhaps?) of knowledge into which the lifetime income markets seem to be organizing itself-out of necessity, I would argue.

We’ve known for a very long time that transforming defined contribution plans into vehicles which facilitate the accumulation and distribution of income guarantees (think, for example, of 403(b) plans-whose tile is even revealing: “Taxation of Employee Annuities…”) has different demands than those plans which have been simply used to accumulate wealth. Yes, defined contribution retirement plans have always demanded a unique blending of ERISA, tax, securities and insurance laws, but these new lifetime income programs now require application of all of those rules in ways unfamiliar to most-even for the typical, variable annuity based 403(b) plan.

Policymakers and regulators have been working at adjusting existing regulatory schemes in order to do so, without having to resort to developing yet another plan type. I think they have largely been successful, in part by adjusting relevant rules applicable to terminating defined benefit arrangements.

Which leads to my comment about these “stacks” of expertise. As lifetime income programs are beginning to become more widely accepted and used in the retirement plan space, retirement plan professionals have needed to concurrently develop the knowledge to support their clients. What we’re finding is that it is not necessary to garner comprehensive familiarity with everything that’s involved in these programs in order to provide the support clients need.

In my often long conversations with other professionals working their way through these matters, it really does appear that these three stacks are shaping up:

• Engineering. Not many professionals need to know all of the pieces that go into developing a lifetime income program. If you are interested in putting out a new kind of lifetime income program, however, you’ll need a few engineers to do so. An old friend of mine once labelled the list we developed of all the pieces necessary to make a new program idea work the “aircraft carrier.” Those professionals working with plans and participants need not be familiar with the details of what is on that “aircraft carrier.” For example, who really needs to know the nuances of using individual insurance applications versus a master or group app, and the impact of who owns the policy? The engineer, however, does.

• Operational. The operator bears the brunt of the work of the engineer. These are, generally speaking, the recordkeepers, custodians, TPAs and financial institutions who are trying to implement, and integrate into their existing services the (sometimes seemingly “harebrained”) engineers’ package. Those professionals are more focused on the pieces that fit into their own software and participant facing utilities, rather than the entirety of the design. The middleware provider is a good example of such services in the market today, a critical role until these integration processes become more normalized.

• Analytical. The analyst is probably the key to making anything really becoming usable: they need to know enough of details of the program design and operation to being able to assess if any particular program or its outcomes meets the client’s needs or fiduciary standards. They also have to figure out how to sensibly compare these disparate programs.

Each of these stacks seems to be developing their own dialect and focus. An interesting case in point is the manner in which SECURE’s “annuity safe harbor” is approached by each stack. From discussions I’ve had, it seems as if each stack has a different sort of take on how it fits within their own responsibilities. It’s not a particularly big deal for the engineer, who is only concerned that the insurance company has processes in place to draft and update the safe harbor notice; the operator has a bit of a heavier lift, concerning themselves with the logistics of the delivery; but it becomes a very serious matter for some analysts, who can bear the brunt of assessing it, monitoring its implementation, and figuring how it applies to any particular client. As you could guess, this engenders a lot more serious attention for the analysist than for the engineer.

I also note that these stacks crossover from time to time.

Their importance lies in two circumstances, I think. The first is that the this really is making it clear that no one needs to know everything about any lifetime income program, and that, for example, analysts can be confident that they don’t have to know everything about a program in order to successfully assist their clients. The second is for those of us who educate on these programs. The audience is critical: an analyst’s knowledge needs are vastly different than that of the operator. Using this kind of model, we can finally fashion sensible educational efforts.