Settlement risk

Eva agrees to buy BTC from Peter. For the deal to work as promised, Eva must receive bitcoin and Peter must receive money. Something can go wrong between the promise and receipt. The Bank for International Settlements, BIS, distinguishes the risk of non-payment from a temporary shortage of funds. A “pending” message does not by itself establish a final loss: the transfer may be delayed. First identify which delivery is missing, who owes it and whether the agreed deadline has passed. [1] [2]

Agreeing the trade fixes its price and quantity. Clearing then determines who owes what to whom; it may include offsetting obligations. Settlement fulfils them. The PFMI, international principles for financial market infrastructures, distinguish these steps; they are not rules of the Bitcoin protocol. The distinction matters to Eva too: an internal exchange balance credit and a withdrawal to her own wallet are separate events. The contractual terms must make clear which event fulfils the promised delivery. [1]

In our illustrative example, Eva buys 1 BTC for 60,000 USD; this is not a current quote. If she sends payment without conditional delivery and receives no BTC, the amount paid is exposed, before any recovery. If no payment was made and a replacement purchase costs 62,000 USD, the difference is 2,000 USD before fees, not automatically a 60,000 USD loss. The BCBS, Basel Committee on Banking Supervision, distinguishes this principal risk from the cost of replacing an unsettled trade. A price change and an unrecovered payment are different problems. [2]

Before sending, Eva may be able to stop her payment. Once she can no longer cancel it unilaterally with certainty, that protection disappears. For foreign-exchange trades, the BCBS describes the relevant exposure window as lasting until final receipt of the currency bought. The same way of thinking helps with our example, without mechanically importing bank rules: when can I no longer recall what I deliver, and when have I verified receipt from the other side? Actual cut-off times, time zones and transfer rules matter, not just the trade date. [2]

Delivery versus payment, or DvP, links final delivery of an asset to final payment: either happens if and only if the other does. PvP, payment versus payment, similarly links two currencies. The PFMI use this to address the risk of giving up value without receiving the corresponding value. Sending two instructions simultaneously does not create that link. The mechanism can protect against loss of the value delivered, but does not by itself guarantee completion or eliminate replacement costs or the need to have funds available. [1] [2]

Eva can check that the BTC transfer goes to the correct address and has entered a block. Further confirmations generally reduce the risk of its replacement by a different chain history; they do not promise absolute irreversibility. They also do not confirm receipt through a bank: even many blocks cannot prove that Peter received the fiat payment, meaning payment in ordinary government-issued money. The PFMI also consider legal finality. Accepting a bitcoin transaction, receiving a bank payment and fulfilling a contract are separate questions. An appropriate BTC acceptance policy depends on the particular risk. [1] [3]

Peter expects to receive 60,000 USD and use it to meet his own payment obligation. If it arrives late, he must temporarily find other funds, postpone spending or deal with a breach of his own contract. This is a liquidity problem: money is unavailable at the moment it is needed. The BCBS therefore also considers dependencies on settlement banks and other providers. A delay does not automatically mean the counterparty is insolvent, but it can still create real costs and pass difficulties along. [2]

For both transfers, Eva and Peter need the amount, correct recipient, deadline, cancellation options and the condition under which receipt becomes final. A BTC transaction identifier helps locate a transfer, but it must match the right amount and agreed delivery. Bank receipt needs a separate check. An unclear status stays unresolved; “sent” is not enough. Automatically retrying without finding out what happened to the first transfer can create a duplicate payment. Reconcile the records with receipt first, then decide the next step. [2] [3]