> ## 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. This page is about the *movement* itself: what one complete movement is, what its pieces are called, and the part most people find confusing — where the money sits while a movement is still in progress.

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 is built from smaller pieces:

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

The R\$100 transfer is one transaction made of two operations — a debit of R\$100 leaving the customer, and a credit of R\$100 arriving at the merchant. Same amount, opposite directions, recorded together.

<Tip>
  Keep this word handy: an **operation is one part of a movement**. A transaction is the whole movement; the operations are its parts. You'll meet this word everywhere in core banking.
</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 — and 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 — so 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 can never be left half-recorded — this property is called **atomicity**.
</Note>

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

***

Here's the part that trips up almost everyone: 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.

To make sense of this, an account's money is described in 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, movement can be capped by **limits** — a ceiling on how much can flow. Together, these explain the question people always ask: *why can't this account spend?* Usually it's because the money is held, blocked, or over a limit — not missing.

## In short

***

* A **transaction** is one complete movement of value — the whole event.
* An **operation** is one part of it: a single debit or credit. A transaction is operations that balance.
* A movement can range from **one-to-one** to **many-to-many**; whatever its shape, it's **all-or-nothing** and always balances.
* Money in transit is **held**, not gone: a two-phase movement **reserves**, then **commits** or **cancels**.
* An account's money is **available**, **held**, or **blocked**, and can be capped by **limits** — that's spending control.

<Note>
  **See it in Lerian**

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