Important Services in Payments

Payment services count as important when their failure would leave people unable to pay, to receive money they are owed, or to settle obligations on time. That harm is often immediate and practical: a bill goes unpaid, wages arrive late, a merchant cannot release goods, or a business cannot meet its own commitments because expected funds have not arrived. Payments are also time sensitive in a way that many other services are not, since a payment that arrives after a deadline, a cut off, or a period of need has not simply been delayed, it may have failed in its purpose. For that reason, payment services are usually identified outcome by outcome, such as making a transfer, paying by card, or receiving a payment, rather than as a single undifferentiated payments function. DORA applies from 17 January 2025 in the EU, while the UK regime under FCA PS21/3 and PRA PS6/21 is labelled separately.

Different payment outcomes harm different people in different ways. A failed card payment at a till harms the buyer and the merchant in the moment, and the buyer may pay by another method. A failed salary payment harms employees who depend on that income for rent and essentials, with no quick workaround. A failed business transfer can cascade, since the recipient business may itself miss payments to staff and suppliers. A failed direct debit collection affects the collecting firm and the account holder differently again. Grouping all of these under one label would force a single tolerance onto harms that differ in urgency, reversibility, and knock on effects. Separating them allows each service to be mapped to its own users, its own dependencies, and its own recovery priorities, even where the same underlying systems support several of them.

Payments rarely involve only sender and receiver. A payment passes through channels, processing systems, clearing arrangements, correspondent relationships, and settlement accounts, and a failure at any point can leave money in transit, neither with the sender nor with the receiver. That in transit state is itself a source of harm, because neither party can be sure what has happened, and both may act on a mistaken assumption. Harm also spreads along the chain: a merchant who is not paid may delay its own payments, a supplier who is not paid may withhold delivery, and a market participant awaiting settlement may face exposures it did not expect. Mapping a payment service therefore means tracing the full chain to settlement, naming each dependency, and asking what users would experience if the chain stopped at each point, not only at the start.

Timing is part of the payment outcome, not an added refinement. A payment made for a house purchase, a tax deadline, a payroll run, or an urgent supplier invoice has a window in which it must arrive to be useful. Outside that window, the user may incur charges, lose a transaction, or breach an obligation, even if the money eventually arrives. Peak periods sharpen the point: salary days, month ends, and seasonal trading peaks concentrate harm, since many users need the same service at the same time. A tolerance for a payment service therefore needs to reflect what delay means for its particular users, rather than treating all delays as equivalent.

One mistake is to identify only the flagship channel, such as a mobile app, while overlooking the underlying payment outcome that customers reach through several channels. If the app fails but the payment outcome can still be achieved by phone or branch, the harm is different from a failure of the payment processing itself, and the service definitions should reflect that. Another mistake is to overlook receiving payments, focusing on sending while forgetting that businesses and individuals depend on money arriving. A third is to treat settlement as a back office detail, when in fact delayed settlement is often where harm crystallises for recipients. A fourth is to assume that a payment can simply be retried, without considering duplicates, limits, fraud checks, and the confusion that follows when users retry on their own. Each mistake comes from describing payments as systems rather than as user outcomes.

A sound payment service list shows, for each service, who sends and who receives, what deadline or need the payment serves, what happens while money is in transit, and what users would do if the service stopped. It shows the chain to settlement and the dependencies at each step, including third parties whose failure would block the chain. It distinguishes services whose harm is immediate and irreversible from services whose harm is delay that can be absorbed. This guide is educational only and does not advise any particular firm; the EU and UK regimes should be read separately in their own texts.