Why your recordkeeping system is costing you!

You work hard and try to put away a few dollars for retirement.  Then, there are the fees the plan charges trying to erode your benefits – some you see and some you don’t.  Why does it cost so much to handle a simple account?  After all, my checking account is free.  Why can’t my 401(k) be free too?

The cost nobody is talking about is buried in the system itself.  The traditional recordkeeping system was born to do a narrow set of accounting transactions. The systems were designed to be held deep in the back office as the plan was managed by a trustee or advisor. The system tracked participant balances and added contributions. The participant interactions were few, simple, and heavily reviewed by administrators. These tried and true systems were successful at processing and tracking simple accounting transactions.

But, regardless of the database or coding language, these legacy systems are driven by a history core constructed from an arbitrary technical transaction file. These are the simple accounting entries required to manage the debits and credits. The transaction constructs were designed for the expedience of programmers rather than the business because the industry was still evolving. The functionality was simple and narrow but very efficient.

However, the recordkeeping business has dramatically changed because of higher participant awareness and involvement. We now see self-direction, lifestyle portfolios, aggregate balances, ETFs, and credit card loans on the table in order to stay competitive. The participants demand to see the data in a form they can understand and interact with it with respect to meaningful life event terms. This requires a successful administrator to engage in terms of business event packages rather than simple back office accounting transactions.

However, when the legacy system is driven by the core technical transaction construct it is difficult and awkward for the system to understand the end to end process. The back office system was born to process one debit or credit at a time. In reaction, the system vendors only have 2 courses of action in the short term: wrap the accounting details with a secondary event identifier or insert bloated middleware to attempt to trick and redefine the interactions.

If an internal wrapper is used, it does allow the system to be aware of related transactions, but it struggles to interact with upstream and downstream systems. The only transactions the wrapper can understand are the internal accounting. It cannot be aware of quality control steps, business interactions, or external interface dependencies. Unfortunately, in today’s recordkeeping environment, the business process always requires more than one system to service the participant. Thus, a wrapper ultimately does little to decrease the costs of ownership or improve the business’s ability to adapt to new service offerings.

The 2nd course of action is to front-end the system with bulky workflow systems or multi-tiered middleware. These workarounds are disguised as loosely coupled add-ons to make it easier to work with the aging host system. But what they inevitably insert into the process is duplication of data and/or rules. This not only makes it challenging to get to the source of truth, but also to diagnose any issues. There have been many cases of administrators acting upon the results they see in the bolt-on workaround when the actual data residing in the core accounting system tells a different story. The temptation is for these workarounds to do too much and really not understand the processing engine. This approach will provide some short-term relief, but inevitably drives the operational costs up and makes change almost impossible because of the tangled nest of code – just ask to see a process diagram in your favorite recordkeeping shop.

This explains why traditional recordkeeping systems are particularly bad at common remitting where the principle activity is workflow.  

System architects who understand the recordkeeping business recognize that the problem with today’s recordkeeping platforms is not a lack of understanding technology but a lack of understanding the business. There are no new 4 letter acronyms that can reduce the 401(k) fees for the participants. In fact, most bolt-on workarounds only increase the costs. These costs were easy to hide when the market was running high, but much more difficult in down times. Only a fresh approach to the system design can begin to provide some relief.

The system architecture must be driven by the business event or package. This must be redefined in terms of the end user rather than the software. It is not just a business service wrapping up complicated internal accounting devices, but rather an end to end process. This new comprehensive approach must include plan setup across the enterprise, contribution remittance, participant account interactions across several systems, upstream dependencies, and downstream deliverables. These key activities cannot be efficiently managed with bolt-on workarounds for things we must expect the recordkeeping system to deliver. In other words, the package must be core to the operation of the recordkeeping hub.

Each package is migrated through workspaces defined by the business flow. Packages are seldom single interactions but a series of steps. Each workspace must have a set of rules to observe and enforce. Those using the legacy systems typically have thick manual processing guides or yellow sticky notes to guide them through the maze. These are not simply status points pushed around by an external workflow, but core events managed at the heart of the business system. The package cannot be a simple wrapper or a middleware trick.

As a common history file becomes the core driver it then shows all of the packages impacting the participant. As each workspace is completed, the next generation system will update internal tables with specific data, such as plan changes, participant changes, contribution instructions, allocation instructions, or loan requests. These tables hold the specific processing results for the event much like traditional recordkeeping. However, the cost of ownership will fall dramatically because the one system at the hub managed the package from cradle to grave.

Of course, each workspace can also update external systems such as related pension recordkeeping, common remitters, vendors, or other systems. If updates are required to a back office system, the updates are done in terms of the recordkeeping system with the expectation that the pension rules will be applied and managed by the back office system. The intention is not to trick the back office system, but rather to listen closely to it.

Through this process the administrator’s actions must be carefully tracked and audited. In fact, this is the only way a transaction can be secure across the enterprise. Each workspace must have defined set of roles that can access it for review, processing, and overriding. In the traditional model, security is often has to be held within multiple applications. This means it is impossible to get a comprehensive enforcement of who viewed and acted upon a transaction. As security concerns and liability increase, the traditional model will become more and more expensive to work around.

The next generation system must inherently start with the business event. The system will be aware of the plan and participant original details, but expect to have to interact with various related systems. If you love your old legacy system, don’t worry. This paradigm doesn’t really compete with traditional recordkeeping systems. It can actually empower them. But it is time to recognize that those systems are too transactionally detailed to actually run a business. And old bulky workflow systems are too generic and image oriented to really manage specialty business lines. The workflow must have a natural understanding of plan and participant data in order to make meaningful decisions. Thus, expect to see more and more independent systems entering the market to become the central business recordkeeping system. This gives the recordkeeper more independence to pursue new service offerings. The new game is not about simple divisions between the front and back office. But rather on how to efficiently drive the business with the fewest number of systems and letting each system do what it does best. Too many shops are dying with 5-10 systems and hundreds of painful workarounds. The new business hub systems are the answer to driving down the cost of administration and letting the legacy systems keep doing what they do best.

For more details check out the new Common Remitter

A new day for the common remitter

Trent sailing in southern ocean

In the past, the common remitter was simply a back office service which split out contributions.  The actual recordkeeping was performed by various vendors.  And often the overall compliance was handled manually by another party.

 However, the market has learned that the compliance is difficult unless the same party also manages the contribution allocation.  This allows the same party to review and reconcile the amounts on the front end.  We have learned that most compliance issues are created during the remittance process – but not necessarily caught.  Thus, if the right scrutiny is applied on the front-end, then the compliance is easier on the back end.

We recognize there are a number of vendors currently handling some of the allocations by baking the administration fees into the cost of the investments.  This creates a challenge to not only properly disclose the cost of the administration, but also to maintain a degree of neutrality between vendors.  A common remitter allows the contribution allocation to be handled by an independent party.  As an independent that specializes in allocations, reconciliation, and compliance, they are able to better serve the plan and participants.  This enterprise view actually empowers each vendor because it makes it easier for the participant to deal with the plan as a whole.

In the case where the vendor or broker wishes to maintain an identity with the participant, this can be handled by simply white labeling the service.  The Relevant Remitter™ allows the common remitter the ability to either label the service under a general banner or identify it directly with the vendor or broker.  This is powered by Relevant Remitter’s™ unique CMS and CRM systems.

In the past, the participants managed by the common remitter have too often not been fully serviced as a community.  The common remitters have been unable to leverage modern web tools to draw in new members, provide targeted messaging, and provide relevant content.  In the future, a complete online delivery system will be required as a market differentiator.  Relevant Remitter™ will enable firms to be a market leader in this new world.

In the past, providers purchased back office allocation systems which simply handled the allocations.   In today’s retirement market, participants use the web more and more and expect broader functionality.  They no longer are content to logon and just look at their balance at a single vendor.  They must be able to manage their entire relationship with not only the common remitter, but also see their entire account.  This can even include single sign-on to the underlying vendor accounts.  An efficient enterprise solution is the only way the common remitter can deliver a complete picture to the participant to keep their interest.  This is not trying to take away anything from any vendor, but rather empower the participant to get to each vendor easier.  The retirement web is can no longer be viewed as just a contribution portal, but rather the common remitter’s e-commerce storefront. 

The Relevant Remitter™ solution allows you to not only use the best practices for efficient allocations, but also to cost-effectively provide relevant enterprise information to your participant community.  Relevant Remitter™ allows the provider to not only provider higher visibility and control to the participant, but also substantially reduces their internal operational cost.  This approach delivers a simple and thoughtful business-led approach to common remittance.