FCA and PRA Important Business Services in the UK

Under the UK regime, an important business service is a service provided by a firm to its users, or to the wider market, whose disruption could cause intolerable harm to consumers or risk to market integrity. Identification therefore starts with the effect of a stoppage on the people who use the service, not with an inventory of systems, departments or legal entities. A firm names each such service in terms its users would recognise, assigns an owner, and uses that named service as the unit for tolerance setting, mapping, testing and self-assessment. Services that do not meet that harm test are not treated as important business services for this regime, however important they may feel internally.

The discipline of the exercise lies in drawing boundaries honestly. A service drawn too widely, such as banking as a whole, cannot carry a meaningful tolerance, because different parts of it fail in different ways and harm different users. A service drawn too narrowly, such as a single processing step, fragments a customer journey so that no owner sees the end to end experience. Good identification work therefore follows the journey a user actually takes, from first access through to completion, and names the service at the level where disruption is experienced.

The harm test asks what happens if the service stops, degrades or produces wrong results. For a service that lets customers pay bills, harm may take the form of missed payments, charges incurred through no fault of the customer, or loss of access to funds at a moment of need. For a service that supports market activity, harm may take the form of trades that cannot settle or information that cannot be relied upon. The test is deliberately user centred, because a technically impressive recovery that leaves customers unable to use the service has not protected the service in the sense the regime intends.

A service name should describe what the user receives, in plain language, rather than naming the system that delivers it. A name such as customer payments describes an outcome, while a name drawn from an internal platform describes a component, and components can change without the service changing. The boundary should follow the journey: the channel through which the user accesses the service, the processing that completes the request, and the confirmation or settlement that closes it. Where a journey spans several internal teams, the service owner needs authority across that span, or the service will be owned in fragments.

Services that commonly require careful consideration include retail payments, access to deposit accounts, mortgage servicing, insurance claims handling, pension payments, investment dealing for retail customers, and clearing or settlement services that other market participants rely on. Each of those services has a recognisable user, a recognisable failure mode, and a plausible path from disruption to harm. The list is illustrative only, because importance is decided by the harm test applied to a particular firm and its users, not by copying a list from another firm or another regime.

One recurring mistake is to start from the technology estate and relabel systems as services. The resulting list mirrors an architecture diagram, and its tolerances, where they exist, describe system availability rather than user harm. Another mistake is to define services at the level of a legal entity or a business line, so that a single label covers several distinct user journeys with different harm profiles. A further mistake is to omit a service because it is delivered largely by a supplier, on the reasoning that the supplier owns the risk. In each case the error is the same: the unit of analysis has drifted away from the user experience of disruption.

A reader checking an identification account can ask whether each named service could be described to a customer in a sentence, whether its users and their harm from disruption are stated, and whether an owner is named for the whole journey rather than for a component. The account should also show services that were considered and set aside, with the reasoning recorded, because a list without rejected candidates may reflect habit rather than judgement. Where a firm cannot explain why a well known customer journey is absent from its list, that absence is the question to pursue.

Identification is not a single event. Services change as products change, channels change and suppliers change, and the identification list needs to be revisited when those changes alter the harm profile. The next guides in this cluster show what happens after identification: setting a tolerance that states intolerable harm for each service, and mapping the resources on which each service depends. Without a sound identification step, both later steps work on the wrong object, and testing will rehearse resilience for a label rather than for a service users rely on.