> ## Documentation Index > Fetch the complete documentation index at: https://cts-docs.cosmos.network/llms.txt > Use this file to discover all available pages before exploring further. # Programmable Escrow > Connecting approved release conditions to a tokenized deposit, so the escrow file and bank record remain aligned. Escrow is conditional money. A payment is held until agreed conditions are met, then released to a named beneficiary for an agreed amount. The condition distinguishes escrow from an ordinary deposit. It also makes escrow operationally expensive: the condition lives in one system, while the money lives in another. ## The problem of divided records In a conventional arrangement, the records are split. The escrow file holds the evidence, beneficiary details, and release decision. The bank's systems hold the deposit, payment request, authorization, and posted transaction. Neither record is complete on its own. When an instruction changes, staff reconcile the two records by hand. They compare the new instruction with the supporting evidence, confirm the change and release decision, and confirm the updated bank authorization. This manual reconciliation delays closings. It is also the step that payment-redirection fraud attacks: ambiguity in the authoritative payment instruction gives a fraudulent instruction somewhere to hide. ## What programmable escrow changes Programmable escrow is a connection between approved payment details and the tokenized deposit itself. The beneficiary, amount, release decision, and returned rail status travel with the payment request instead of being reassembled from separate systems. One file identifier connects the approved request, bank authorization, and rail status, so staff follow a single history through each system. A request that conflicts with the approved file pauses until the file is updated, rather than proceeding on an unverified instruction. ## What does not change The control structure remains unchanged. * The escrow agent retains release authority * The depository bank retains payment authorization * The bank's existing controls apply before any payment is made * The core ledger records the deposit liability | Element | Conventional | Programmable | | ----------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | Deposit and escrow file | Core records the balance, escrow software separately holds allocations, evidence, and approvals | The tokenized deposit connects the approved file details to the deposit record | | Release authority | Escrow agent records the decision in escrow software | The approved release decision travels with the payment request | | Payment authorization | The bank authorizes and sends over the selected rail | Unchanged | | Changed instructions | Staff compare revised instructions across systems | A conflicting request pauses until the approved file is updated | | Reconciliation | Staff match escrow file, bank records, and rail status | One connected history | The representation of the data changes. The authority to release it does not. This page describes the model rather than a shipped configuration. The escrow workflow, the metadata a bank or escrow agent can append, and the setup steps still need to be documented. Contact [sales@cosmoslabs.io](mailto:sales@cosmoslabs.io) to discuss an escrow use case. ## Related * [Tokenized Deposits](/use-cases/tokenized-deposits) for what the escrow balance is held as * [Banking Core Integrations](/banking-core-integrations/overview) for how the deposit stays reconciled