Giving Retirement Participants More Services And Reducing the Costs of Pension Administration

The challenge of offering more retirement services, but also reducing administrative fees leaves many recordkeepers wondering how did we get here?  The main 3 drivers are:

• Increased fee disclosure which exposes fees offset with hidden asset charges.  Administrators who heavily relied upon 12(b)1 type fees are struggling to compete with all the fees on the table.  A few administrators kept separate and fair service fees and are doing fine, but most are going to have to make dramatic cost cuts in the next year or so.  Previously subsidized administrative processes are now being forced to look at substantial and overdue rework.
• Supporting heavy internal software builds of custom modules.  These modules were developed back in the day to support new services or prop up lagging vendors – a lot of good intentions.  However, the functionality has evolved into a commodity but the administrator is still maintaining tangled custom code which is now strangling their ability to reduce costs and adopt new features.
• A massive paradigm change in infrastructure provisioning.  The use of cloud environments and virtual servers is common and solid – the biggest and most secure companies are moving forward full throttle.  The administrator who is trying to maintain a physical data center with blinking lights will not be able to provide the service or get control over their costs.  The cloud provisioning of secure servers have moved these costs from thousands of dollars (fully loaded) to only a few dollar per month.  And the uptime and performance far exceeds anything that the administrator has in their data center.

The solution is some basic restructuring and some correctly applied technology.  This change must be attacked with a concerted effort, but it is often best implemented in a controlled and measured manner.  Administrators who cannot address the key challenges will be out of business inside of 12 months.

• Push more self-service to the employer and the participant.  This is typically done through newer, more flexible web portals.  The employers and participants are growing smarter every day and want to take more control over their accounts.  Many items always deemed as requiring administrator handling can now be totally handled on the web.
• Standardize the payroll on-boarding process to remove rework, manual intervention, and errors.  Administrators are always surprised to see the incredible amount of rework that is actually happening in their back office payroll processing.  This is the most expensive process in administration and unfortunately the area with the least amount of standard processes.  A successful approach has been to actually pay employers to adopt a standard and complete interface – the key is to make the interface self-contained.
• Move quickly toward mobile Apps.  The mobile App not only forces the administrator to look at what really matters on the screen, but it also get the participants more involved with their accounts on a daily basis.  The web is passive but mobile Apps are active.  In the next 12 months, the primary account access will move from web to mobile.  The game has already changed.
• Deploy a common publishing database for all plan artifacts.  This includes statements, documents, forms, and reports.  The employers and participants are both looking for just in time delivery of the critical items needed – not sent but in a secure repository available when needed.  Looking around the market, there are few tools which effectively do this in the context of employers, plans, and advisors (SharePoint is not the answer).  The key is to have a file exchange mechanism where items can quickly and securely be published to any plan entity.
• Rework and rethink the web design.  The pension webs evolved into a kitchen sink mentality with many pages, buttons, and icons – unfortunately most are never used.  The winners will scale back their webs using a hierarchical approach to focus on the happy paths.  And transition the language from industry jargon like ‘transactions’ to ‘life events’.  The user experience will be more holistic and managed through easy to understand wizards.  But the challenge is that the web screen sizes are changing from tablets to wide screen.  This means the modern website will have to use ‘responsive coding’ to tailor itself to whatever screen size the user presents – this is not just scaling, but actually changing the layout, menus, and content.

Based upon working in the trenches for many years working with industry leading software and administrators, these are the challenges and the pitfalls.  This has enabled a vision for the future and a pathway for 4 simple solutions.  These solutions can be done without big bang technology rollouts or professional service engagements.  But, it does often require a big internal cultural shift from the top down to adopt new ways of thinking and leave behind some pet projects.

Click here to find out how we are helping our client reduce costs and deliver more!

Is Your Pension Mobile Yet?

As the costs for retirement administration are forced more into the open, providers will be looking for new ways stand out in the crowd.  Participants are demanding more services, faster access to information, and drastically reduced costs.  The old model of having just delivering statements or even updating a static website will no longer keep the younger generation’s attention.  The pension world has moved past paper, through voice response, on past the web, and onto mobile.

The mobile app will allow administrators for the first time: 

• Deeper penetration into participant base (in everyone’s hands)
• Secure connection (deliver confidential data)
• Intimate relationship (specific alerts)
• Focused message (just the facts)

 However, the administrator must carefully select their app provider as this is still the mobile wild wild west:

• There are many devices.  And the same app is not always compatible across different brands.
• The mobile providers are rapidly changing the OS which mandates frequent updates
• Unfortunately, there are few development tools
• On some platforms, the app is unable to lock devices
• Legacy back office systems do not necessary support mobile devices
• And most importantly, it is difficult to synchronize the data with the presentation on the existing website or voice response system.

The best approach is to get an app in the market quickly in order to keep some experience and feedback.  This is not a fire and forget model like the early voice response and websites.  The apps will need to continue to evolve so avoid the temptation to wait until the perfect app can be designed and validated.  In order to get something to market quickly, consider a platform which can do the following:

• No personal data stored on device (all transient data)
• Use existing multi-factor authentication with existing credentials
• Multi-factor compliance with device ID (UDID)
• Optional to require web device approval
• Uses SSL for data in transit

 Of course, transactions can easily be added later.  But the transaction rollout needs to be focused on what the participant would really want to manage quickly.   This is not just a duplication of the available web-based transactions.  The larger, more complex transactions are likely to still be left on the website.  However, quick changes as a result of person alert should be available on the mobile app with suitable mobile controls to make it easy for the participant in interact with their pension while they are on the go.

There are 2 approaches to the mobile market:  native mobile app and mobile website.  The mobile app takes full advantage of the local device for performance and navigation.  While the mobile website essentially uses adjusted html to simply present a smaller web.  The challenge is to avoid thinking of the mobile app as just a ‘smaller’ web.  The provider MUST rethink their presentation in terms of ONLY what the participant really needs to see as they are catching an airplane, picking up kids from school, or at lunch.  The mobile website is still heavily dependent upon bandwidth and html style navigation.  Whereas the mobile app can have much higher performance and present true mobile navigation features.  Some the better mobile apps contain the following:

• Each App has custom skin to match web look and feel
• Native apps maintained as simple as possible (high portability) – host based graphics
• Screen zones tailored by host based XML (easy host-side tailoring)
• Use real-time connectivity to back office system or alternative ODS

 The platform which drives the mobile app is the real secret.  It must deliver processed data, preferably XML, to the device.  And leave the presentation and graphics to the local app.  However, in some cases, pushing the graphics can be an advantage.  Such as bar or pie charts which are still very difficult to render in the mobile world – largely because of OS variations.  The best mobile apps will be built upon:

• Fast aggregate single interactions (client-server)
• No rule or data duplication
• Use existing script based rules
• Open system XML and XSLT (same rules and data as web)
• Include data from alternate sources

 Beware of the imposters!  There are some mobile apps which look a lot like mobile website.  The app is basically just a container.  This gives the provider the appearance of being able to migrate code from one device to another – but all they are really moving is the web service calls and the frames.  The advertised advantage is the ability to modify the application without re-issuing the application – sounds good.  However, the distribution process for the application is so easy, streamlined, and automated that the benefit is negligible.  But the performance cost for the additional communication is high and the loss of navigational functionality is painful.  The mobile devices are more powerful than the computers many of us took to college so why not use them.  Be sure you are getting the native mobile app you deserve.

The best place to start is with the Iphone™.  Regardless of your phone preference, the reality is that Apple has the easiest and most efficient rollout path.  For example, Testflight™ makes the iterative issuance of test versions quick and simple.  The recommended strategy is to get a solid application working on Iphone and then quickly cookie cutter it out to Andriod and Windows7.  This avoids having moving requirements on 3 platforms.  If designed right, the code can be ported between platforms, but to date there is no proven code generator for a full native app.  There are some instances of scripted conversion where the app is essentially a frame using host based html, but this makes the user suffer daily for a few hours of one-time programming effort.  The rollout needs to avoid the temptation to try to develop the ‘perfect app’.  Again, this is not the world of the fire and forget.  The application management strategy needs to include a plan for continuous review and tuning.  The usage patterns and needs will continue to evolve at an ever increase pace.  So if done right, the screens and functions rolled out today will not be the same ones your community will be using in 6 months.

Then, many shops will take a look at the Ipad2.  This will be the single most revolutionary device for the Pension space in the next few years.  It is the only channel which allows high navigation and the ability to quickly tune it to the user.  However, care must be taken to not just 2x (size up) the smartphone app.  This is a DIFFERENT platform with new characteristics, not the least of which is the screen size.  The IPAD will allow administrators to skip past the paper and get direct input participants even in remote meetings.

The smartphone and IPAD applications will take our pensions mobile.  They will allow administrators to reach wider into their population and develop a far more intimate relationship with their participants.  Never has there been a channel that is available to so many people across socioeconomic lines.  The progressive administrators will be doing things like:

• Integration with social media for ‘retirement badges’
• Shake for sample portfolios
• Market information for sticky use
• Quick balance check
• Secure alerts for key events
• Direct enrollment
• QR codes for quick reference information

 The smartphone allows users direct and quick access to their pension data.  And it forces providers to thin down the data to ONLY what the participant really needs to focus on.  The participant can see what matters with a click of a button.  No more remembering websites or complicated logon routines.  The mobile app is not just a scaled down version of a website.  It is a targeted and concise pension control that is at the participant’s finger tips almost 24×7.  Although participants are not yet making widespread demands for this access, it will be the single largest used channel by the end of 2012.

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