[Skip to content]

Sign up for our daily newsletter
The Actuary The magazine of the Institute & Faculty of Actuaries

Front-end and back-office

A lot of money is spent on policyholder
administration systems: buying them,
maintaining them, and running them.
Most of it is wasted. Most of it should never have been spent in the first place.
For protection business, at least, effort should be moved to front-end systems. This is not just because they get the business in, but also because their environment is more complicated and the risks greater.

Front-end and back-office
First let me define what I mean by front-end systems. Figure 1 divides systems into two parts: front-end and back-office. Front-end are pre-policy systems, considering essentially the policy processing elements. I will here consider the customer and intermediary systems, which means I can avoid using the acronym CRM.
Back-office systems cover policy issue, data storage, premium collection, alterations, claims, and all the associated regulatory processing. A feature of the back office is that there need be only one system. It can be almost completely under the control of the life office. For historical reasons there may often be more than one system, but most offices try to have only one open to new business at any one time, or use middleware to give that impression.
Currently, most external people who want to inter-relate with policy data are supplicants of some form: customers wanting to change their contract, or relatives trying to obtain some money. Therefore the life office can dictate how it is approached, usually channelling requests through administrators by post or phone, and so the system environment can be simplified. Whether this approach is sustainable with the current range of flexible protection products is a tricky question, but not one we can quickly address here.
A new environment
Figure 1 shows the wider environment within which the front-end systems operate. It is the Wild West for life offices, fought over with intermediaries, internal sales forces, tied agents, and other interested parties. It is the fragmentation and power of this competition that force most life offices to maintain a number of different quotation and other systems.
Pre-quote systems include approach material, sales material for use with customers, enticements to get customers and/or intermediaries to use a particular process, eg Internet golf games, and literature. Most systems are currently manual or paper-based. Perhaps for this reason there is great variety here. The need is for automation to improve process, increase consistency, and spread best practice.
Quotation systems are the most mature of the front-end processes. Most offices now use a standard quotation number generator that can be used to support all quotation services. This has been facilitated by the development of message standards (for instance, in the UK, the Origo standard). This has enabled different services, such as the Exchange and a life office’s own Internet site, to build their own input and output screens and use the same quotation engine to get the premium and other numbers. This has reduced actuarial test time and quotation errors, as well as IS build and maintenance costs.
The automation of the application process has probably fallen recently with the decline of direct sales forces. However, some offices, notably L&G, are leading the way in the IFA market. Automation is constrained by the need to co-ordinate looking at a screen while also building a relationship with a customer.
Most application processes are currently part of bespoke, end-to-end solutions developed by insurers or software companies such as Allfinanz. This approach enables strong internal controls and stable development platforms.

Developments in underwriting
Underwriting is entering an exciting period of change. The underwriting choices now available are surprisingly diverse. Figure 2 shows the traditional underwriting process.
Paper applications go to underwriters who use wetware and snail mail to produce a rating with help from one or more of GP’s report, medical exam, extra medical tests, and CMO’s or reinsurer’s knowledge.
This is changing because of business pressures on costs, GP reluctance to keep writing reports and getting them to insurers on a timely basis, and the need to make swift underwriting decisions on products sold through non-traditional distribution channels. New risk selection propositions or underwriting approaches have only flirted with the UK up to now. Reassuringly, technology has been an enabler of change rather than a driver.
Figure 3 is shown as a diagram to demonstrate complexity, rather than to be read. There are now a number of different entry channels and approaches to the underwriting process, face-to-face new business, mail responses to top-up offerings, etc. The human underwriter is complemented by automated screening routines and full automated underwriting systems. Evidence could be from paramedical visits, routine lab tests, or other sources. Outsourcing some or all of this is becoming necessary in many firms.
There are a number of roles for technology in such circumstances. One is to manage complexity through workflow management. Another is to automate routine tasks, including a lot of the low-level underwriting. A third is to improve consistency and reduce human error.
Enabling new things to be done is always exciting. For example, life actuaries can stochastically model offices only because of the power of modern profit-testing tools. As yet I would argue that the underwriting process has not made an analogous advance.

Information systems issues
I referred earlier to some of the IS issues, three of which are of particular interest:
– platform independence;
– reach versus grab; and
– plug-and-play.
Any actuarial student who has had to test two calculation systems, because one is for head office users and the second for one of the comparison services, knows the problems of platform-dependent systems.
Reach versus grab for net applications is the politically correct version of the thin or thick client descriptions. Thin clients just open a pipe from the user to the provider’s computer servers, which do all the hard work. This increases reach, as all the user needs is a standard browser, though content is reduced owing to limited size of the pipe.
Thick clients place a lot of processing on the client’s machine and less on the central servers. This increases grab, as high-volume processing such as interactive imaging to enhance data collection and information presentation can be performed. However, reach is restricted as programs have to be put on the users’ machines and then maintained.
Currently, the cost of installing the more powerful grab solutions can only be justified for advisers, while end-customers suffer none-too-exciting and slow Internet screens. As broadband penetration improves pipe sizes, thin client solutions will improve to provide the same standards to all.
Plug-and-play is an urban myth for system components and whole systems. However, the amount of hammering necessary in future should reduce as people move to industry standards, for example using messages in the XML language laid out to Origo standards to communicate across and between systems.
Focus, which provides sales channel automation data solutions, refers to systems built using platform-independent, plug-and-play components as 21st-century software. Whether they can work with 20th-century mammoths is an interesting question.

In short
At the start I argued that the emphasis on back-office systems should be switched to the front-end. I think I have demonstrated that the underlying processes pre-policy issue are at least as complicated as those post-issue. In addition, the environment they are being delivered into is more varied and less controllable.
I also stated that a redirection of effort would reduce risk. This is by considering the combination of the likelihood of problems occurring, and the severity of problems. I offer the extra overall complexity of the front-end as a guide to its higher likelihood of risk as opposed to the back-office.
I would conclude by noting that while some front-end problems will affect only one policy or a short-run of policies, the greater risk is from the front-end’s being unable to adequately serve current or new distribution. As analysts of insurer market values will be aware, the value placed on goodwill for future new business is high, and is sensitive to small changes in new business volumes or prospects. While front-end problems are unlikely to make you insolvent, they can severely affect your company’s value.
But, for those that successfully tackle the front-end problems, both business and IS, the rewards, like the business, will flow smoothly.