In 1974 Herstatt, a German bank, failed to meet a settlement transaction with a counterparty resulting in loses to the counterparty. Herstatt was duly punished with the suspension of its banking license. As a consolation, cross-currency settlement risk came to be known as Herstatt risk
In a previous post link, I suggested a Distributed Ledger Platform, DLP, could be developed as an alternative to a Bitcoin based remittance platform when parties cooperating are know. Briefly, different remittance partners handling different corridors, can use a permissioned DLP to avoid the volatility and delays that a pure cryptocurrency system would introduce. Ripple, was used as example of a permissioned ledger but other platforms such as HyperLedger, Eris or others listed in Tim Swanson report could have been used.
For many payment, and trading transactions, there is an intermediate step between execution and settlement: clearing, a catch-all for the processes that drives the commitments of the transaction into actual exchange of assets between parties. The window of settlement represent settlement risk. Clearing can reduce settlement risk, for examples on forward and futures transactions, a clearing institution can requiring the posting of margin to at least reduce the impact of unfulfilled commitments. The actual exposure risk will depend on the type of settlement agreed. A settlement can be of type “Delivery vs Payment” where the exchange happens simultaneously or “Delivery vs Free” where a leg of the exchange is deferred. These two methods present a risk-vs-efficiency trade-off as a deferred settlement allows for batching, efficiently moving only the netting of debits and credits. ACH in the US uses this type of batching. For minimum risk exposure, real-time-gross-settlement system, RTGS, offer immediate payment but there is no netting functionality. FedWire, CHAPS and Target-2 for the dollar, pound and euro respectively are representative of these settlement systems.
In the proposed DLP based remittance , although we are starting from a base where operators are known and have pre-existing agreements, reducing counterparty risk is still advisable.
A simple operational measure is adjusting the maximum exposure to a counterparty, in Ripple, for instances, the maximum amount of exposure can be set on the gateway and adjusted with changes in risk perception. Indirect counterparty risk should also be considered, this requires understanding how the particular DLP finds ‘trust paths’ to ensure there are no hidden exposures e.g is there any trust transitivity? If Alice extends trust line to Bob, and Bob extends another line to Charlie, can Alice find herself exposed to Charlie? In Ripple for example, this will not be the case unless Alice’s gateway has established direct trust lines for both Bob and Charlie
Another measure is to reduce the settlement amount at risk, by increasing the frequency of settlements, in the limit of this approach as we increase the frequency it would yield the equivalent of a RTGS. Such a feature would be a desirable feature in a DLP
If settlement requires external systems with an-avoidable delays, while waiting for payment, an operator can use an intermediary asset that would remove ‘temporarily’ counterparty risk. This assets could be IOUs from other counterparties. Cryptocurrencies can also serve here as an intermediate form of settlement albeit at the cost of volatility exposure. Don’t want volatility exposure? A fiat-pegged cryptocurrency such as NuBits or bitUSD would remove this risk at the expense of yet another type of risk; peg break risk, rare event risk, but real nonetheless. The underlying message here is, like many other risk scenarios, settlement risk cannot be eliminated, only clipped or reduced