Tokenized Deposits and Programmable Payments: Moving Guarantees and Letters of Credit into Smart Contracts

Banks are testing the transfer of guarantees and letters of credit into programmable circuits. Smart contracts enable payment automation upon receiving a signal from oracles. However, in complex transactions, manual document verification and operator discretion are still necessary.

Pilots employ tokenized deposits and stablecoins to integrate settlements with trade transaction logic. These projects do not yet demonstrate readiness for scaling, cost reduction, or operation in the open international market.

JPMorgan is developing the Kinexys project (formerly Onyx) for working with programmable deposits. Asian regulators are also actively testing wholesale CBDCs. The status of such initiatives always requires clarification: from concept to industrial deployment.

What Exactly Is Amenable to Automation

In international trade and banking practice, the key instruments for securing obligations are demand guarantees and documentary letters of credit. Both mechanisms are based on formal document verification rather than analysis of the actual circumstances of the transaction, which makes them potential candidates for automation.

Demand Guarantee

A demand guarantee is honored by the bank upon receipt of a written demand from the beneficiary. In the verification process, the bank assesses only formal features: the amount, term, details, and presence of required wording. The URDG 758 rules enshrine the principle of independence of this guarantee from the underlying transaction. All verification is conducted exclusively on the external features of documents, without analysis of their actual content.

This model is ideally suited for automation through smart contracts. The program logic reduces to confirming a cryptographic signature and verifying compliance with limits within a specified time interval. There is no need for complex analysis of accompanying documents, so the system operates as a deterministic mechanism if the conditions of the demand are formalized in advance, and the authority of the data source and the procedure for suspending payment are defined by the contract.

Documentary Letter of Credit

A documentary letter of credit presupposes payment of funds after presentation of an established set of documents. Banks assess their compliance with the terms of the transaction on external features in accordance with UCP 600 rules. According to banking practice standards, staff must not delve into verification of authenticity or detailed content of documents, limiting themselves to searching only for obvious discrepancies in the presented data.

However, here there is a strict time limit for verification, not exceeding five business days. The main complexity of a letter of credit lies not in the transfer of funds, but in the procedure for determining document compliance.

According to estimates by the ICC and market participants, 60–80% of first presentations may contain at least one discrepancy; the figure depends on the region and calculation methodology. This means that a significant portion of documents require correction or additional verification before payment execution.

Limits of Formalization and Automation

This fact highlights the limit of formalizability of documentary operations. The majority of transactions require expert interpretation of the context of invoices, insurance, and transport documents. Such multifaceted work is extremely difficult to fully translate into the language of strict computer logic, as it implies qualitative assessment that goes beyond simple template-based checks.

It is important to distinguish two levels of automation: payment execution and decision-making on document compliance. The first is easily implemented through smart contracts using oracles. The second requires expert assessment and discretion, where there remains room for human judgment. Therefore, full automation without human involvement or trusted systems remains an elusive task.

Trigger: Who Confirms the Occurrence of the Condition

A smart contract executes a condition but does not observe the real world: confirmation of shipment, arrival, or acceptance comes from external data sources that serve as triggers for automatic payment. The problem of the data source reduces to trust: the contract receives a signal from an oracle, an electronic document management platform, or a registry, but cannot independently verify the actual movement of cargo or the quality of goods.

Electronic trade documents rely on the UNCITRAL Model Law on Electronic Transferable Records (MLETR) framework document, adopted in 2017. A number of jurisdictions have implemented it or used it as a basis for national regulation.

These include Bahrain (2018), Singapore (2021), the UAE (2022), Qatar (2023), and the United Kingdom, which adopted the Electronic Trade Documents Act 2023. The British law is of particular importance for international trade, since English law is widely used in cross-border commercial contracts, trade finance, and documentary operations.

Without recognition of an electronic transport document — for example, eBL, eCMR, or eAWB — in applicable national law, automation may encounter the absence of a legally significant trigger: the smart contract will record the event technically, but this does not guarantee recognition of the record before a court, bank, or regulator.

Data instead of documents — information on cargo movement, IoT device readings, confirmations from the carrier in TMS/ERP systems — can serve as a trigger, but require a clear allocation of responsibility for the reliability of the source.

Responsibility for reliability rests with the data issuer — the carrier, warehouse, inspector, or aggregator platform. In the event of an error or manipulation, the smart contract will execute payment based on a false signal, and the dispute will shift to the plane of contractual claims and insurance. A record in the registry confirms the immutability of the record and the chronology of events, not the correspondence of content to reality: immutability of the log does not equal the truthfulness of the recorded information about cargo, timelines, or quality.

Legal Nodes of Automatic Release

The independence of the obligation means that payment under a guarantee does not depend on a dispute over the underlying transaction. The bank is obliged to honor the demand upon compliance with formal conditions, even if the beneficiary has breached the underlying contract. In automation, this simplifies the logic of the smart contract: there is no need to analyze the actual circumstances of delivery; it is sufficient to verify the validity of a cryptographically signed demand.

Fraud Exception and Interim Measures

A court may enjoin payment under an independent obligation only upon proven "clear" or "egregious" fraud by the beneficiary, of which the bank was notified before execution, or upon threat of irreparable harm. Automatic execution comes into conflict with the possibility of intervention: in practice, this is addressed through delays or a "confirmation plus waiting period" architecture.

Status of the Smart Contract

The status of a smart contract depends on the agreements of the parties. The code may qualify as an independent legal obligation or as a technical instrument for executing a traditional contract.

This classification determines the approach to interpretation when a conflict arises between the algorithmic behavior of the code, including technical errors or exploits, and the text of the document. Courts, as a rule, must establish the actual intention of the parties — that is, the meaning they attributed to the contract at the time of its conclusion.

Incorporation of UCP 600 or URDG 758 makes the respective rules part of the contractual regime, but by itself does not resolve the conflict between the behavior of the code and the text of the obligation. Priority depends on the applicable law, the content of the contract, and the presence of a special clause on the relationship between text and algorithm. Direct fixation of the priority of the textual document strengthens the position in favor of its application if the result of the code's operation contradicts it.

Divergence Between Code and Document

The priority of the text of the obligation depends on the terms of the contract and applicable law. If the parties have expressly established the priority of the textual document, the behavior of the contract should generally be regarded as a technical implementation rather than as the primary source of rights and obligations. The cross-border nature of the obligation gives rise to questions of applicable law and recognition of electronic records, requiring explicit forum selection and choice-of-law clauses.

Settlement Layer: The Role of the Tokenized Deposit

A programmable payment needs a settlement asset existing in the same environment as the execution logic: the smart contract must operate with a token that is simultaneously a means of payment and an object of automatic transfer without exiting into traditional correspondent accounts.

A tokenized deposit is an obligation of a commercial bank to the holder, a digital representation of a bank deposit on a programmable platform; the claim is addressed to the issuing bank, and settlement ultimately closes on central bank money through interbank clearing settlement.

An electronic money token is an obligation of a non-bank issuer (EMI/stablecoin operator), backed by a reserve of assets; the holder bears the risk of the issuer and the reserve, not the risk of a commercial bank, and legal protection depends on the e-money regime in a specific jurisdiction.

Central bank money is a direct claim on the central bank, used for final interbank settlement; the holder (as a rule, a commercial bank or authorized infrastructure) does not bear the credit risk of the issuer, but access is limited to participants of the payment system.

In automatic execution, the technical immutability of a record in the registry means only that the transaction cannot be reversed at the consensus level; legal finality occurs only when the law recognizes the transfer as irrevocable and protected from challenge in insolvency or judicial intervention.

The gap between technical and legal finality creates risk: a record in the DLT may be permanent, but subsequently challenged by an insolvency administrator, court, or regulator, if legislation does not recognize such a transfer as final within the framework of an established settlement system.

What Pilots Show and What They Do Not Show

The typical perimeter of a pilot is a closed circuit with a limited circle of participants. Several banks, corporate clients, and one or two carriers operate in a simulated or limited-volume environment, where transaction volumes, jurisdictions, and types of documents are pre-selected.

Such a configuration allows testing the technical linkage "tokenized deposit + smart contract + oracle," but does not reproduce the full load, heterogeneity of systems, and conflict of interests that arise when scaling to the open market.

What remains untested: the behavior of the system in a dispute over the underlying transaction, upon suspicion of beneficiary fraud, upon refusal of one of the parties to confirm acceptance, upon cross-border enforcement through national courts, and upon failure or manipulation of the data source.

Pilots rarely model scenarios where an oracle transmits a false signal and the smart contract executes payment without pauses. The interaction with insolvency procedures, when an administrator challenges previously executed transfers, is also not always tested.

Lesson of the Previous Generation

Consortium platforms for digitalization of trade finance — we.trade (liquidation in 2022), Marco Polo (insolvency in 2023), Contour (closure at the end of 2023), and TradeLens (closure in 2022) — faced primarily problems of economics, governance, financing, and incentives, rather than a proven fundamental defect of DLT technology.

At the same time, Contour should not be described as a definitively non-existent network. After closure at the end of 2023, the platform was acquired by XDC Ventures in October 2025 and announced for restructuring with new financing and an updated strategy. According to reports on the deal, most previously concluded agreements in the network were not active, although individual participants, including DBS and Bangkok Bank, maintained a presence. Therefore, the correct formulation is "a previously closed and subsequently revived platform," rather than "an operating industrial network" or "a fully closed network."

The reasons for the closure or contraction of such projects include closed networks without interoperability, high custom integration costs for each participant, a consortium model requiring simultaneous connection of multiple banks and companies to achieve network effects, and the absence of a clear allocation of cost and control over the roadmap.

Programmability partially removes the problem of custom development: standard primitives "demand guarantee," "letter of credit against eUCP presentation," "atomic payment upon trigger" can be reused on top of shared infrastructure, lowering the barrier to entry for new participants.

However, programmability does not eliminate the key barriers: the need for mass adoption for network effects, harmonization of regulatory requirements across jurisdictions, trust in the platform operator, and the readiness of banks to share data and scoring logic with competitors.

Without resolving these issues, pilots will remain a demonstration of technology in controlled conditions, rather than proof of the commercial viability of programmable guarantees and letters of credit in open international trade.

Conclusions

First and foremost, demand guarantees and letters of credit with clearly formalizable triggers are amenable to automation: electronic transport documents, including eBL, eAWB, and eCMR, fixed terms, amounts, and details, where verification reduces to validation of signatures and compliance with templates of the applicable edition of eUCP.

In the text of the obligation, in addition to the code, the following must be enshrined: applicable law and jurisdiction, priority of text over contract behavior in case of divergence, a suspension mechanism upon court injunction or fraud exception, the status and responsibility of oracles and data sources, as well as explicit choice-of-law and forum selection clauses for cross-border disputes.

Frequently Asked Questions (FAQ)

What happens if the condition of the smart contract is fulfilled, but the presented documents contain discrepancies?

If the contract receives a signal from the oracle about the fulfillment of the condition, it will execute payment automatically, even if the documents contain discrepancies not identified at the level of formal validation. According to estimates by the ICC and market participants, 60–80% of first presentations under letters of credit may contain at least one discrepancy; this range depends on the region and calculation methodology. Therefore, the architecture incorporates pauses, multi-signature confirmations, or manual operator intervention before the final transfer, to avoid irreversible payment upon disputed documents.

Can an automatic payment be stopped upon suspicion of fraud, and who possesses such a right?

A court may enjoin payment under an independent obligation only upon proven "clear" or "egregious" fraud by the beneficiary, of which the bank was notified before execution, or upon threat of irreparable harm. In a programmable construct, this right is implemented through a suspension mechanism upon a signal from a trusted oracle-operator, court, or regulator, but requires explicit enshrinement in the text of the obligation and compatibility with applicable law.

How does a tokenized deposit as a settlement asset differ from a stablecoin in such a construct?

A tokenized deposit is an obligation of a commercial bank to the holder, a digital representation of a bank deposit, where settlement ultimately closes on central bank money through interbank clearing settlement. A stablecoin is an obligation of a non-bank issuer (EMI/stablecoin operator), backed by a reserve of assets; the holder bears the risk of the issuer and the reserve, not the risk of a commercial bank, and legal protection depends on the e-money regime in a specific jurisdiction.