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.

How to teach your web to Tango

In the e-commerce business dance floor, the new digital jumps and jives demand real-time connections to many business steps and swings. No longer is it satisfactory to just shuffle data to update a single process overnight in batch. For example, a consumer enters a website to buy a new PC. The transaction must interact with the vendor CRM system, the vendor inventory (ERP) system, and a payment clearing service (authorize.net). The challenge is that all of the required left footed touchpoints are not necessarily listening to the same music. In order solve this tangled mess, web developers must teach their webs to tango.

In the past, these web dance steps were strictly defined and tightly coupled. The digital participants simply stepped into painted shoe prints on the cyber floor. This enabled high efficiency, but changes were difficult and expansion opportunities limited. If any system were changed, then all had to be upgraded or retested as the changes could have a wide impact. If the vendor needed to expand, it was difficult to engage other products from other vendors with system not under the local control. Our webs were being pushed to do more than 2-step, but the costs were too high to learn the more exotic dances.

The first solution was to establish “orchestration”. This is essentially a local and centrally defined model as to how the interaction will behave. Certainly, a conductor could enforce the right moves, right? The developers essentially enforced a certain structure for inputs, outputs, and error handling. This evolved into WS-BPEL (Business Process Execution Language) which can be defined as (3):

· It is a web service with runtime semantics and central control

· Abstract definition of end point protocols

· Executes the specified WSDL (Web Service Descriptive Message) message calls

· Encourages reuse of WSDL resources

But this still didn’t create the beautiful ballet we needed. The primary difference between orchestration and choreography is executability and control. An orchestration specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are tightly controlled. In other words, orchestration refers to the central control of a distributed system while choreography refers to a distributed system which operates according to choreography rules but without centralized control. (1) The challenges to the old orchestration WS-BPEL dance are:

· It requires centralized execution

· The semantics are not globally formalized

· It is not scalable as dual control and connectivity are required

· It is rigid so it is non-collaborative

Originally marketed by Oracle, Web Services Choreography Descriptive Language is a specification by the W3C defining a XML-based business process modeling language that describes collaboration protocols of cooperating peer Web Services. The XML model defines a global scenario which is long-lived and stateful without a single point of control. Each service executes its own orchestration based upon its defined role and sequence. (2) The W3C Web Services Choreography Working Group, was closed on the 10th July 2009 leaving WS-CDL as a Candidate Recommendation which is intended to (3):

· Promote a common understanding between services

· Automatically guarantee conformance which reduces cost of ownership

· Ensure interoperability through behavior contracts

· Increase robustness and utilization

· Generate code skeletons

 

The key components of WS-CDL are:

· interactions

· Channels

· Participants

· Roles

· State

WS-CDL fits on top of the new technology stack as the key glue to bring it all together and make it work in the global context (4).

The design approach is different:

· BPEL: Design the baby steps first then put them together into a waltz.

· WS-CDL: Establish the flow of the tango first then distill it into simpler moves. (From WS-CDL we can generate BPEL/Java/C# logic for each participant.)

This gives very different results (4):

• BPEL: Participant specific viewpoints of control-flow (sequence, flow, switch, control links, exception handlers) based on the rigid imperative model
• WS-CDL: Global reactive rules for declaratively prescribing normal/abnormal progress, based on the flexible information driven model

The components of WS-CDL are:

• Typing. This defines the information types and location.
• Identifying & Coupling Collaborating Participants. In other words, the XML defines the participants, their roles, and how they relate together so there is no overlap or competition causing race conditions or deadlocks.
• Information Driven Collaborations. The key elements are the channel type, variable definitions, activities, and units of work. For example:

<variableDefinitions> <variable name=”ncname” InformationType=”qname”|channelType=”qname” Mutable=”true|false”? Free=”true|false”? Silent-action=”true|false”? role=”qname”? />+</variableDefinitions>

• Activities. These are interactions which enable collaborating participants to communicate and align information

The end purpose of Choreography is to combine actions with common behavioral characteristics, building a unit of work. In order to list all the binary relationships the dance is often expressed in complex PI calculus notations. The notation shows alternative patterns of behavior using workunits. This enables recovery backward by using exception handling and forward by finalizing already completed activities. But it has some drawbacks (5):

• Lack of separation between meta-model and syntax. The WS-CDL specification tries tosimultaneously define a meta-model for service choreography and an XML syntax.

• Lack of direct support for certain categories of use cases. Currently, WS-CDL does not support use cases with one-to-many or multi-transmission interactions.

• Lack of comprehensive formal grounding. While WS-CDL borrows some terminology from pi calculus, there is no comprehensive mapping from WS-CDL to pi-calculus or any other formalism.

The bottom line is that Choreography complements Orchestration. Choreography is concerned with global, multi-party, peer-to-peer collaborations, between application components, distributed within or across an organizations trusted domain (5). WS-CDL can allow a developer to get their web into the global ball. However, its complex notation and broad scope may be too overwhelming for so many dancers that they just sit this one out and head for the bar.

References

(1) Business Process Execution Language. http://en.wikipedia.org/wiki/WS-BPEL

(2) Web Service Choreography. http://en.wikipedia.org/wiki/Web_Service_Choreography

(3) Web Services Choreography and Process Algebra. 29 April 2004. Steve Ross Talbot http://www.authorstream.com/Presentation/Junyo-29185-WS-CDL-Web-Services-ChoreographyandProce-ss-Algebra-Agenda-Orchestration-vs-Choreography-BPEL-as-Entertainment-ppt-powerpoint/

(4) Aggregating Web Services: Choreography and WS-CDL. Nickolaos Kavantzas, Oracle. http://www.fpml.org/_wgmail/_bpwgmail/pdf0BHcCh7tU4.pdf

(5) A Critical Overview of the Web Services Choreography Description Language. Alistair Barros. March 2005. http://search.yahoo.com/r/_ylt=A0oG7mbDOKZNOFcAzDxXNyoA;_ylu=X3oDMTEyY21kaGljBHNlYwNzcgRwb3MDMQRjb2xvA2FjMgR2dGlkA0RGUjVfODc-/SIG=14r8m9pbf/EXP=1302760739/**http%3a//bptrends.com/deliver_file.cfm%3ffileType=publication%26fileName=03%252D05%2520 

WP%2520WS%252DCDL%2520Barros%2520et%2520al%252Epdf

(6) Web Services Choreography Description Language Version 1.0. W3C Candidate Recommendation 9 November 2005. http://www.w3.org/TR/ws-cdl-10/

(7) WS-Choreography Definition Language (WS-CDL) . EBPML working group. http://www.ebpml.org/ws_-_cdl.htm

(8) http://lists.w3.org/Archives/Public/public-ws-chor/2004Jun/0024.html

Is your common remitter for your 403b or 457 using Excel?

Our teachers and other non-profit employees are able to save for their retirement in 403b or 457 plans. These plans allow the participants to pick from the widest array of investment vendors. In this case, each vendor is a separate and distinct record keeper, but the total plan is rolled up under the Common Remitter umbrella. The challenge is the dozens if not hundreds of vendors to choose from and manage.

This means the participant’s hard earned contributions are routed through the Common Remitter in order to review the salary deferrals and remit them to the correct vendor. This is a critical service to maintain the plan’s compliance and reconciliation. It is a good and necessary step to protect the participant’s interests. However, too many institutions are relying upon manual or antiquated processes which rely upon Excel spreadsheets. This creates a huge opportunity for investment delays and lost money.

It is challenging to know exactly how your plan is being managed. But here are some tell-tale signs your remittances are being handled manually:

• There is a long time delay for processing SRA changes;
• The participant information is not accessible directly on the web;
• There is a long time delay between deductions and the actual investment;
• The payroll department is not using a standard electronic interface;
• The actual deductions are not tested each payroll against the expected SRA’s;
• There are compliance surprises at the year end;
• The employer cannot download SRA changes online with each payroll frequency;

These problems have been allowed to infect too many processes because this industry has emerged very quickly and has not had a great deal of standards. The initial attempts at remitting were either done by local brokers or the vendors themselves as a courtesy service. However, the level of complexity and accountability has grown dramatically in the past few years. Thus, a best practice has evolved to utilize an independent Common Remitter to evaluate the transactions who is not biased by any investment product.

For these Common Remitters to provide cost effective service they must deploy a quality system to manage the end to end process. This cannot be done with the typical recordkeeping system. These retail retirement systems demand to post the complete financial transaction with detail level accounting transactions. However, the common remitting process simply needs to track and evaluate the business event. Then, pass it on to the system of record for final posting.

Today’s common remitting requires a very different approach. It needs a diligent workflow tracking through varying workspaces. This is not the typical imaging workflow, but an integrated workflow directly aware of the plans and participants. Even though the balances are not maintained, the administrative plan rules must be enforced for transactions.  

The best common remitter systems used by employers for managing the multi-vendor investment providers for 403(b) plans function as an extension of the employers HR System and administer all multi-vendor benefit programs. The system will allow payroll to simply manage a single deduction. Then, the remittance system will handle the allocation instructions to the selected vendors. This dramatically reduces the payroll workload and complexity.

In the future, the participants will enter any Salary Reduction Agreements (SRAs) directly on the common remitter website. The online process will immediately evaluate the request to insure the vendors selected are approved and the amounts are within the plan ranges. This eliminates the most common back office processing errors. Then, the common remitter system will allow the HR system to download changes on a payroll basis in order to dramatically reduce the lag time for participant changes. This not only provides a better service to the hardworking employees, but also reduces the workload on the HR department.

Then, the HR system will update the Common Remitter with each payroll run. The payroll system will provide a standard SPARK interface. It is not efficient to require the common remitter to manually reformat local files. The new standard interface will show the participant information and the deductions. The upload will be done on the web to allow immediate validation and feedback. This allows the HR team to immediately fix any problems. This sometimes appears as more work on the HR, but it is actually less. It is less work because any required adjustment may only be done by HR; but in this case, it eliminates the manual iterations with the Common Remitter back office.

After review and processing, the deductions are routed to the approved vendors. The Common Remitter will route the contribution transactions on to the vendor either in an XML SPARK format or in the native downstream record keeper format. All transactions and cash will be delivered electronically. This practice significantly reduces the risk and cost for the vendor.

Take a closer look at your Common Remitter process. If you are a participant and you see any of the warning signs, then your contributions may be being manually tracked on spreadsheets. If you are on the HR team and you want to reduce your ever increasing HR effort, you need to demand your remitting agent deploy a quality system designed for this process. For the best interest of your employees, you may need to work with your remitter to agree on a standard format. If you are a vendor and are overwhelmed with inbound files, then work with your agents to take advantage of systems which will allow straight through processing.

Follow us to see the latest development for common remitting.

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