Demystifying Pension Administration

I know, this is bold, who would write up an article on the subject of demystifying pension administration and worse, who would read such an article?!? Well, I’m only putting pen to proverbial paper as it’s a topic that keeps coming up in my day to day. It’s also easy to become complacent, insulated in what you know that you become genuinely surprised when clients react to seeing how our approach to administration software works in practice.

There’s an expectation that you need a small army of people and a separate workflow tool to connect up your various systems

I’m often on point to demonstrate Keystone, our end to end retirement platform which includes administration as part of the ecosystem. There’s an expectation that you need a small army of people and a separate workflow tool to connect up your various systems of record and show an agent how to reconcile data to complete a business process.

I was reminded of this understanding whilst at a conference recently and there was a lot of talk about the complexity of pension administration, how large teams of people were needed to key in data and how robotics are used to scrape data off customer portals as the underlying admin system wasn’t designed to share data. There’s also been a lot of consolidation in the industry, but with a focus on the legal ownership of the assets and not necessarily bringing the separate legacy systems under one roof which just adds more cost and complexity.

So, to that end, I thought I would share how we tackled the same subject.

To start with, I should explain that I no longer work for Smart Pension, the master trust, I work for a separate firm (Smart) that builds the software, Keystone, that Smart Pension and other financial institutions use today for their workplace solutions. But eight years ago we did start out as a unified team, an engineering team dedicated to building auto enrolment software for Smart Pension.

Before you build any software, the first question to address is nearly always: do you build or do you buy? At the time, there were no off-the-shelf solutions for auto enrolment and in fact the government legislation seemed to have taken the industry by surprise as many firms were furiously adapting their incumbent solutions. There were a number of pension admin systems, but they needed the auto enrolment rules adding and in many cases were focused on individual wealth management and not the necessary schema needed for a company based hierarchy. Importantly there wasn’t a single platform that offered onboarding, recordkeeping, data validation, payroll imports, letter generation, payment and investment reconciliation as well as a good user experience - plus all the necessary legislative requirements. In summary we were about to build some software!

At work we often talk about approaching problem solving with a blank sheet of paper and this moment was formative in becoming what is now one of our working principles. Other existing solutions offered recordkeeping, but you needed to build the auto enrolment rules or payroll process separately… and why was payment or investment often on separate systems? Plus nothing in the market seemed to offer an intuitive user experience which was necessary in educating a country that was suddenly told to get compliant with new pension laws.?

So where to start? I’ve always maintained that you build software to suit a business problem. At a high level the problem statement was: get the average business owner signed up, onboard their employees, assess them for eligibility, send out statutory letters, upload their contributions and request payment to invest their money on behalf of their staff. All of this in a secure and scalable way. With that list in mind we started in the cloud (AWS) and built the sign up process first.?

This was an employer focused user journey that signed them up in a fully digital experience. No wet ink or paper processes, a simple online profile creation straight into the database as you’d expect with any other website. Once in the Employer portal the business owner was walked through a selection of tasks to sign the necessary e-document, add their direct debit details and upload details of their staff. We built software to assess the employees against the new eligibility criteria and that automatically enrolled them into the scheme, sent out welcome emails and generated the statutory letters. This was all done at the same time that contributions were collected so we could pull payment from the employer's bank account upon the next payment schedule. The entire journey was timed by a third party as taking less than 30 mins in total for a firm with 100 employees and that simplicity enabled hundreds of companies to get compliant every day.

So how is this about administration? Well, a lot is going on behind the scenes.

First up the journey is powered by a suite of APIs that read and write data directly into our database in real-time whilst validating each value (data type) being ingested. Data that fails the validation is rejected and the self-serve nature of the portals dynamically asks the user to correct the data. So a big distinction here is that our platform is designed as being API first, versus an admin system that has APIs added to it. This means there is no lag in data and the data going in has a far higher data quality standard. I mention this as I have heard of admin systems that send error handling reports back to the user at night after they have completed their tasks, not helpful if you have submitted your data to HMRC already!

Another aspect that was obvious to us, but again surprises clients who visit us, is the automation within the scheme set up process. As the employer signs up, we validate the business details against Companies House and as the user presses the submit button on the website they initiate a POST request to the company/create endpoint which pushes the details of the company into our database and triggers a number of rules instantaneously. The company is attributed to a master trust and the associated scheme rules are automatically applied for all aspects of the scheme. Default funds and optional self select funds are assigned, along with any fees and glidepaths. Benefit groups and eligibility criteria are selected and in the case of UK auto enrolment all current and historic contribution percentages are applied (necessary for late stagers or schemes that are migrating with historic data). This all happens in the blink of an eye without human intervention. I remember demonstrating this to a client who announced “This is going to save us days!”

Employee onboarding is initiated by the employer, again as a self service journey. They can either do this via our assessment tool or using their own payroll software (including payroll software that is integrated with our API). Eligibility checks are performed in real-time and successful data is accepted into the system. All error handling is dynamically presented back to the user to ensure all employees are onboarded correctly. Once the employees and their contributions are imported the system calculates the total payment due. This can either be paid at the time or at the next payment schedule.

Payment is collected via direct debit (another API) and all successful payments that land in the trustee bank account are automatically reconciled against member level contributions and marked as PAID. The system does support BACS and non direct debit processes but direct debit accounts for >98% of payments in the UK and in all cases the system is state based, meaning valid payments are marked with the same PAID state.

All contributions that are in the PAID state are picked up by the investments worker, an automated job that matches contributions against the chosen fund(s) in member portfolios. Separate investment records are created, one per fund in the members portfolio. All investments of the same fund ID are automatically aggregated into a common trade instruction for that day and submitted to the asset manager. As the dealing process completes, the trade instruction is updated with the total number of units purchased and the price of the fund on that particular day. The final step is to automatically update the member level investment records with the new price and unit count which in turn updates the member holdings and ultimately their total valuation.

The only human step in the investment process is to verify the totals being sent to the asset manager that day and then send the associated money from the trustee bank account to the asset manager. This settlement process could be automated as well, but by design has someone on hand to verify this automated process has worked correctly.

Yes, not everything is fully automated in this way. Requests such as partial claims and divorce payments don’t yet have the same degree of automation, but just as we automated beneficiaries and benefit statements, we’ll get around to these processes also.?

As we started our journey building what would become Keystone by Smart, I remember someone explaining to me the concept of straight through processing (STP) in the context of pension administration as they were familiar with. This was a process that when all data points were correctly aligned could navigate several systems at once to complete a complex business process end to end without human intervention. But to me, the logic as it was described seemed counterintuitive. Why build scripts to connect many systems together when you can build one system that does it all under one roof and validates the data on the way in so that those straight through processes didn’t fail at the first hurdle. This encouraged us to build an end-to-end solution where data was captured and validated at the same time before being automatically reconciled or processed as part of each logical business process. A true single source of truth that provided operators with a read-only application to monitor activities that would typically be carried out manually.

Since that day Keystone has evolved into a configurable platform that trades across the world - in US dollars, whilst accepting payments in Euros for example, and provides users with journeys in Spanish or in Arabic as easily as it does in English. Rules can be created for every manner of situations, for example single employer trusts, and a forecasting engine produces calculations in multiple jurisdictions. And all of this happens whilst Smart Retire generates payslips for its customers who are in retirement and members can view their pension values in one of the six mobile apps we have built for our clients. These are just a handful of the features added to Keystone since it was conceived eight years ago.

In summary, we’ve made a name for ourselves by disrupting an industry, not necessarily because we came at it as experts at retirement software but because we were used to challenging the norm and building scalable, cloud-native software that was designed to meet a set of business needs in an efficient and user friendly way.