Decentralised Finance

Financial functions implemented through protocols, pools and smart contracts

What “decentralised” does and does not mean

Decentralised finance (DeFi) describes arrangements that use distributed ledgers and smart contracts to provide functions such as exchange, lending and asset management. A user may interact with code rather than a conventional intermediary, but people and organisations can still control upgrades, fee settings, interfaces, oracles and emergency pauses. The practical question is who can change the rules, who can stop a loss, and who answers a customer when the code behaves as written but the outcome is harmful.

The Financial Stability Board (FSB) notes that DeFi often performs familiar financial functions and can inherit or amplify familiar vulnerabilities, including leverage, liquidity mismatch, interconnectedness and operational fragility. A bank should analyse the economic exposure before treating the absence of a traditional intermediary as the absence of risk.

Three common functions

An automated market maker holds assets in a pool and uses a rule to quote exchange prices. Users who supply liquidity may earn fees but can be exposed to asset-price movement, pool imbalance, contract faults and the inability to withdraw during stress. A displayed fee yield is not a guaranteed return.

A lending protocol accepts collateral and permits borrowing under rules for valuation, margin and liquidation. Price feeds, liquidation incentives and market depth matter as much as the contract code. A sudden price move can cause many positions to liquidate together, while delayed or manipulated oracle data can trigger the wrong outcome.

A composed service calls another protocol or uses its token as collateral. This can create convenient end-to-end transactions, but risk can travel through a chain of dependencies. A bank evaluating one application should map its stablecoin, oracle, bridge, governance and liquidity dependencies, not only the app's own contract address.

The dependencies and control points in a DeFi lending and exchange arrangement.

Where control actually sits

A bank's diligence should identify the development team, governance process, admin keys, upgrade mechanism, front-end operator and parties providing material data or liquidity. If a multisignature group can change code, that group is an operating dependency. If a web interface disappears, a user may still have a protocol position but no simple way to service it. If a bridge holds assets on one network and issues a representation on another, the bridge's custody and security become part of the exposure.

IOSCO's DeFi recommendations take a lifecycle and risk-based approach to understanding arrangements and identifying responsible persons where relevant. They do not imply that all arrangements have the same degree of decentralisation or that a bank can ignore applicable local law. The bank's legal team must assess the actual activities, assets and jurisdictions.

Worked example: collateral value falls

Assume a customer pledges a volatile token to borrow a stablecoin through a protocol accessible from a bank-linked interface. The token price falls sharply. The oracle reports a new value, the position passes its liquidation threshold, and a third party repays debt in exchange for collateral under the protocol's rules.

The bank needs to know what it promised. Did it only provide a link, distribute a product, hold custody, fund a leg or give advice? Each role creates a different customer and control question. The interface should show the collateral rule, liquidation trigger, fees and lack of guaranteed recovery before the customer commits. Operations should be able to reconstruct the position, oracle observation, contract version, transaction sequence and customer disclosure if the result is disputed.

A stress rehearsal should delay the oracle, withdraw pool liquidity and pause a bridge. The outcome may not be a neat reversal. Some losses are irreversible; some can be compensated only by a responsible party that has agreed and is able to pay. A bank should not imply that an on-chain audit trail itself creates a redress right.

Measuring the risk, not the activity

Total value locked, transaction count and advertised yield can be useful context, but they do not measure whether a service is safe or profitable for a bank. More useful indicators include concentration of liquidity providers, collateral quality, liquidation slippage, oracle outages, governance changes, unresolved code findings, bridge dependence, failed withdrawals and the proportion of customer positions that can be independently reconstructed.

The bank should document its exposure limit, monitoring owner and exit trigger. If it cannot identify the parties and dependencies needed to execute an exit, it should treat the claimed decentralisation as an unresolved operating risk, not as a control.

Takeaway

DeFi changes the way financial functions are delivered. It does not remove leverage, liquidity, custody, market conduct or customer-service risk. Evaluate the full protocol stack and the bank's actual role before offering access or accepting exposure.

Sources and review scope

These sources analyse DeFi functions and international policy themes. Product permissions and customer obligations depend on current local law and the actual arrangement.