What Swift Payment-Speed Statistics Do—and Do Not—Tell You

Suppose the proposed customer message is: “Your funds arrive within one hour.” Colleagues point to Swift’s headline speed figures as evidence. Before approving it, the important question is not how fast the network is. It is what “arrive” means.

Swift reports that 75% of payments reach the beneficiary bank within ten minutes, and over 90% within one hour. Those are its reported global network figures. Their endpoint is the beneficiary bank—not credit to the customer’s account, and not confirmation that the customer can use the money.

That distinction changes what the statistics can support. They are evidence of fast bank arrival across Swift’s reported network. They are not, by themselves, evidence for your service’s promise of funds within an hour.

Bank arrival is a milestone, not necessarily the finish

Swift calls the movement from the sending bank, through any intermediaries, to the beneficiary bank the in-flight segment. It defines the last mile as the interval between arrival at the beneficiary bank and credit to the customer’s account. The headline ten-minute and one-hour percentages describe arrival at the end of the in-flight segment.

The last mile can vary because of receiving-country requirements and individual institutions’ operating practices. Swift identifies examples such as manually confirming payment information or waiting for a local processing cycle. These are reasons why two payments with the same bank-arrival time can have different customer-credit times.

Consider a hypothetical pair of supplier payments. Both are accepted together and reach their respective beneficiary banks well before the one-hour deadline. One is credited and usable immediately. The other awaits a local processing cycle and is not credited before the deadline. Both satisfy the bank-arrival measure; only the first satisfies the proposed availability message. If the suppliers release goods only when funds are usable, the same bank-arrival result produces different commercial outcomes.

This does not mean the last mile is generally slow. The supplied percentages establish neither the share of customers credited within an hour nor the share facing a long additional wait. The missing measurement is not evidence of delay—but it is still missing evidence for the customer-facing claim.

Why the average cannot fill the gap

Swift also says that in-flight time represents less than 20% of the total journey on average. That may look like a way to convert the headline arrival times into an end-to-end estimate. It is not.

The figures describe different things. “Over 90% within one hour” is a distribution threshold: it tells you what proportion reached a milestone by a stated time. It does not say those payments each spent an hour in flight. The reported average share, meanwhile, does not give every payment the same relationship between in-flight time and total time.

Nor does that overall average establish the relationship for just the payments inside the one-hour threshold. Those payments could have different last-mile experiences. Swift’s supplied explanation also does not specify how the average share was calculated.

Scaling a threshold by an average share therefore cannot produce an end-to-end percentile or a promised duration. The missing link is payment-level timing: how the in-flight and last-mile intervals combine for the same payments. You cannot reconstruct that distribution from these two summaries.

Measure the clock the customer hears

“How long does a SWIFT transfer take?” sounds like one question, but the answer depends on the clock. For a customer-facing claim, SWIFT payment processing time needs a defined start and a defined finish.

A customer may read “within one hour” as starting when they submit the instruction. A provider may measure from acceptance. Those are different events. If your evidence starts at acceptance, it cannot establish a submission-to-availability claim without measuring the intervening time as well.

The finish needs the same care. Beneficiary-bank arrival, account credit and usable funds are distinct endpoints. If the proposed message concerns availability, a credit timestamp must not simply be assumed to prove usability. The evidence needs to identify when the customer could actually use the funds.

Swift’s supplied explanation does not state a precise clock-start event or reporting period for its headline figures. Neither detail should be filled in by assumption. In particular, the figures should not be presented as though they measure an hour from your customer’s submission.

To support your own service-specific claim, the evidence needs three things:

• Matched timestamps. Observe the promised start and end events for the same payments, rather than joining separate aggregate measures.
• A relevant population. Define the service, routes, currencies, receiving institutions and operating conditions covered. Strong results for a subset do not establish performance for every payment your service accepts.
• An observed end-to-end distribution. Over a stated reporting period, establish what share reached the promised endpoint within the stated time. Account explicitly for pending payments; examining only completed transfers can omit the very delays the claim needs to describe.

This is the practical difference between knowing that the network moves payments quickly and knowing what your customers experience. For treasury and operations, the latter is what connects cross-border settlement performance to a supplier deadline or a customer’s cash position.

What to approve—and what to hold back

Without matched end-to-end evidence, Swift’s figures can still be useful customer context. Keep them attributed to Swift, retain their global-network scope and say explicitly that they measure arrival at the beneficiary bank. Do not place them beside an unqualified availability promise in a way that makes them appear to substantiate it.

If your own data supports a customer-level timing statement, keep the wording within that evidence: the measured interval, covered population, observed proportion and reporting period. Conditions that materially change the timing belong close to the claim, not far away in an explanation customers may never read.

There is also a distinction between reporting performance and making a promise. Even a well-matched historical percentage does not establish that every future payment will meet the threshold. An unconditional “within one hour” message says more than a measured share of payments arriving within an hour.

Changing the wording to “same day international payment” does not remove the measurement problem. It still needs a defined deadline, relevant time zone and endpoint. A broader-sounding timescale cannot repair a mismatch between bank arrival and customer availability.

Conclusion

Swift’s speed statistics answer an important bank-arrival question. They do not answer your service’s customer-availability question. Approve a timing message only when its clock, endpoint and scope match the evidence—and keep a measured performance statement distinct from a promise.

For requesting more information about how we can help reach out to us. We're here to help and answer any questions you may have.

Contact us!