Settlement Latency

Overview

How it works and why it matters

Settlement latency measures the time between a clearly defined starting event and the moment settlement is completed or usable. Without named endpoints, the metric is misleading: checkout click, broadcast, first confirmation, provider ledger credit and bank availability occur at different times.

Important technical and operational details

The starting event may be transaction acceptance, clearing completion, cycle cutoff, or instruction submission, so the measurement definition must be stated.

The total can be separated into queue time, review time, funding delay, provider processing, network confirmation, and internal posting. Percentiles usually reveal operational experience better than an average because a small group of delayed settlements can be hidden by many fast ones.

A useful metric names the start, end, clock, timezone, included population, and treatment of holidays, retries, failures, and incomplete items.

Monitoring should segment latency by provider, rail, currency or asset, destination, amount, and outcome. Customer estimates should rely on current distributions and should not describe acceptance latency as settlement latency.

Practical decision points

Track a transaction as a sequence of dated milestones, not one vaguely defined duration. Example milestones include quote creation, payment broadcast, detection, required confirmations, internal provider credit, conversion execution and payout receipt. An outage can affect only one portion of this journey. Report both median and tail percentiles for each rail, separating weekends, batches and manual exceptions when relevant. A low blockchain confirmation time does not guarantee fast withdrawal from an exchange or faster receipt into a bank. Comparing 'instant settlement' offers without aligning milestones and risk thresholds produces misleading conclusions.

Related concepts

Settlement; Settlement Asset

Further reading

• bis.org documentation
• bis.org documentation