Automation Is Not a Feature. It Is the Floor.

Automation is often presented as an improvement: a way to make a financial service faster, cheaper, or more convenient than it was before. That framing treats automation as a feature — something added to a working system to make it work better. The Group's view is different. In the financial infrastructure now being built, automation is not a feature added to the system. It is a condition of the system functioning at all. This article sets out why the distinction matters, and how the Group approaches automation as a result.

The Cost of Manual Process

Every manual step in a financial transaction carries three costs, and they compound.

The first is error. A manual step is a point at which a mistake can be introduced — a mistyped figure, a missed check, an inconsistent judgement. Manual steps do not merely risk error; they accumulate it, because each step is an independent opportunity for it.

The second is cost in the ordinary sense. A manual step consumes time and labour. A process with many manual steps consumes a great deal of both, and that consumption scales directly with volume.

The third, and the most consequential, is the ceiling. A manual process has a maximum throughput set by the people performing it. It can be made larger by adding people, but only linearly, and only up to a point. A financial infrastructure intended to serve large and growing numbers of customers cannot rest on processes whose capacity is bounded by headcount. The manual process does not just cost more at scale. At sufficient scale, it stops being viable.

This is the basis for the Group's framing. Automation is not pursued because it improves a viable manual process. It is pursued because, at the scale the infrastructure is intended to reach, the manual process is not viable to begin with.

Automation by Default

The Group's approach is to automate by default — to treat manual intervention as the exception requiring justification, rather than automation as the enhancement requiring justification.

This applies across the operational core. Customer onboarding and identity verification are designed to be conducted through automated processes; a decision with legal or similarly significant effect on a person is subject to safeguards, including the right to obtain human intervention and to contest the decision, as UK and EU data protection law provides. Transaction monitoring — the continuous scrutiny of activity for signs of financial crime — is, by its nature, a task that volume makes unsuitable for manual performance, and is designed to operate as an automated control. Regulatory reporting is designed to be generated systematically from underlying data rather than assembled by hand. Compliance controls are designed to be embedded in the system's logic rather than applied to it afterwards by intervention.

In each case the principle is the same. The process is built to run without a person in it, and a person is introduced only where their judgement adds something the system genuinely cannot.

Automation and Control

A reasonable objection to automation, particularly in a regulated context, is that it removes human oversight from processes where oversight matters. The Group regards this objection as important, and as addressable — but only if automation is designed correctly.

Automation done poorly removes oversight. Automation done well relocates and strengthens it. An automated process is, if properly built, more consistent than a manual one: it applies the same rule the same way every time. It is more auditable: every step it takes can be logged, traced, and reviewed, which is rarely true of distributed manual judgement. And it concentrates human attention where that attention is most valuable — on designing the rules, on reviewing the exceptions the system escalates, and on examining the cases the system is built to flag rather than the ones it is built to handle.

Properly designed automation does not remove control from a regulated process. It makes the control explicit, consistent, and inspectable. That is a stronger position than manual oversight, not a weaker one.

Designed From First Principles

The distinction between automation done well and automation done poorly is, in large part, a distinction of when it is decided upon.

Automation added to a system built for manual operation tends to be partial. It automates the steps that are easiest to automate and leaves the rest, producing a process that is part machine and part hand, with the seams between them as new points of failure. Automation designed into a system from the beginning is different. The system is conceived, from first principles, around the elimination of manual intervention wherever it adds friction without adding value.

This is the principle on which the Group's proprietary technology kernel is designed. The objective is not to automate an existing manual process after the fact. It is to build the operational core so that automation is its default state, and manual handling the deliberate exception.

Prerequisite, Not Feature

The title of this piece states the Group's position directly. Automation, in the financial infrastructure being built now, is not a feature — not an enhancement that distinguishes one service from another. It is a prerequisite — a condition of operating at scale, of operating with acceptable error, and of operating with control that is consistent and inspectable. The Group treats it accordingly: not as something to be added, but as something to be designed in from the start.