> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# How money moves

> What counts as one movement of money, what its parts are called (transactions, operations, and holds), and where money sits before it finally settles.

You already know that money never appears or vanishes. It moves from a source to a destination, and both sides get recorded. Now for the *movement* itself: what one complete movement is, the names of its pieces, and where the money sits before a movement finishes.

Picture handing cash across a counter. The moment the cash leaves your hand and lands in the other person's, the whole exchange happened as one event. A banking system treats movement the same way: one complete handover, recorded in full, all at once.

## One movement, recorded in full

***

A **transaction** is one complete movement of value: the whole event, start to finish. When a customer sends R\$100 to a merchant, that single transaction *is* the R\$100 changing hands.

But you've already seen that every movement has two sides. So a transaction has smaller pieces:

* An **operation** is one part of the movement: a single debit or a single credit.
* A transaction consists of operations that **balance**: everything debited equals everything credited.

The R\$100 transfer is one transaction with two operations. One is a debit of R\$100 that leaves the customer. The other is a credit of R\$100 that arrives at the merchant. Same amount, opposite directions, recorded together.

<Tip>
  An **operation is one part of a movement**. A transaction is the whole movement. The operations are its parts.
</Tip>

## The shapes a movement can take

***

The simplest movement has one source and one destination, but a single transaction can spread across more accounts. However many parts it has, it always balances. The common shapes:

* **One-to-one**: one source, one destination. A plain transfer: customer out, merchant in.
* **One-to-many**: one source, several destinations. The customer pays R\$103: R\$100 goes to the merchant and R\$3 to a fee account. Three operations, still balanced (R\$103 out = R\$100 + R\$3 in).
* **Many-to-one**: several sources, one destination. A few accounts pooling money into a single fund.
* **Many-to-many**: several sources and several destinations at once, like a marketplace splitting incoming payments across sellers and fees.

The rule never changes, no matter how many parts there are: **everything that leaves must equal everything that arrives.**

<Note>
  Not every ledger supports all four shapes. Simpler systems may allow only one-to-one (or one-to-many) movements, while others handle the full many-to-many case in a single transaction. What's possible depends on the ledger you use.
</Note>

<Note>
  A transaction is **all-or-nothing**. Either every operation succeeds together, or none of them happen. The books never stay half-recorded. The name for this property is **atomicity**.
</Note>

## Money in transit: holds and two-phase movements

***

Where does the money sit *before* a transaction is final?

Many movements don't settle the instant they start. The system first **reserves** the amount: it's set aside, still in the account, but no longer free to spend. Then the transaction either **commits** (settles for good) or **cancels** (releases the reservation). This is a **two-phase** movement: reserve first, then commit or cancel.

An account's money has two parts:

* **Available balance**: what you can actually spend right now.
* **Held balance**: what's reserved for a movement that hasn't finished. Still yours, just frozen in place until it settles or releases.

<Note>
  Think of a hotel pre-authorization on your card. At check-in the hotel **reserves** an amount. It isn't gone, but you can't spend it. At check-out the charge **commits**, or the hold is **canceled** and the money frees up. Same money, two phases.
</Note>

```mermaid mermaid theme={null}
flowchart LR
  R["Reserve<br/>amount held"] -->|"settles"| C["Commit<br/>moves to destination"]
  R -->|"released"| X["Cancel<br/>returns to available"]
  classDef bal fill:#fff8e1,stroke:#f4b400,color:#333;
  class R,C,X bal;
```

## Spending control

***

Once you can see money as *available* versus *held*, controlling spending becomes natural. At any moment, an account's money sits in one of three states:

* **Available**: free to spend.
* **Held**: reserved for a movement in progress (in transit).
* **Blocked**: frozen on purpose, set aside so it can't move at all.

On top of that, **limits** can cap movement. A limit sets a ceiling on how much can flow. Together, these answer a common question: *why can't this account spend?* Usually the reason is a hold, a block, or a limit, not missing money.

## Next steps

***

<Note>
  **See it in Lerian**

  See these ideas in practice: [Transactions](/en/products/midaz/transactions), [Operations](/en/products/midaz/operations), and [Balances](/en/products/midaz/balances).
</Note>