> ## 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.

# The direct and indirect model

> How direct and indirect Pix participation works on this rail: what an ISPB identifies, who holds the settlement account at the Banco Central, where an indirect participant's money actually lives, and how the direct participant controls each position.

Every institution on Pix participates in one of two ways. A **direct participant** has its own connection to the Banco Central's settlement infrastructure and settles Pix in its own right. An **indirect participant** has no connection of its own: it contracts a direct participant and operates through that participant's connection.

This rail makes your institution the direct participant. [Hosting indirect participants](/en/interfaces/pix-jd/hosting-indirect-participants) is the feature that lets other institutions reach Pix through you.

## Every participant has its own ISPB

***

Direct or indirect, every participant carries an **ISPB** — the eight-digit code the Banco Central assigns to every institution. Two facts about it decide most of what follows:

* **The ISPB is identity and routing.** An indirect participant's ISPB is what names it on every Pix message: it is how an inbound credit finds the right institution, and how an outbound order says on whose behalf the money moves.
* **The ISPB is not settlement.** An indirect participant's Pix is settled by the direct participant that hosts it. Having an ISPB does not give an institution a settlement account at the Banco Central.

On this rail the two ISPBs live in different places, on purpose. Your own ISPB is the deployment's identity, written once in the systemplane key `tenancy/jd_integration_binding`. Each indirect participant's ISPB goes in its registration, and nowhere else — see [Hosting indirect participants](/en/interfaces/pix-jd/hosting-indirect-participants) for what happens when the two are confused.

## One settlement account, three layers of position

***

The account that settles Pix at the Banco Central is the **Conta PI** — the Pix settlement account. There is exactly **one per direct participant** — on a deployment that operates several participants through the organization catalog, each holds its own. An indirect participant has no Conta PI; that is what makes it indirect.

So where is an indirect participant's money? Its position exists in three layers, each held by a different party:

| Layer | Held at           | What it is                                                                                                                                                     |
| ----- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1     | the Banco Central | part of the direct participant's Conta PI. The Banco Central sees one balance — yours. Every hosted institution's money is inside it                           |
| 2     | JD                | an internal limit and balance per indirect participant, which you administer. It is how the connectivity layer knows how much each hosted institution can move |
| 3     | your Midaz ledger | the position account `@pi_` followed by the institution's ISPB — one per indirect participant, created by the plugin when you register the institution         |

The third layer is where segregation actually happens. Each indirect participant settles on its own `@pi_{ispb}` account, so one institution's money is never mixed with another's — and never with your own book. What a registration creates and how the alias is derived is [Indirect participants](/en/reference/interfaces/pix-jd/indirect-participants).

One rule ties the layers together: **the layer that authorizes a payment is your ledger**. A payment that exceeds the Midaz balance is refused **before anything is sent to JD** — balance sitting at the other layers, the Conta PI at the Banco Central or an institution's limit at JD, authorizes nothing by itself. When the ledger says no, the order never leaves your side.

## How you control each position

***

The direct participant owns the lifecycle of every position, end to end:

1. **Registering creates the position.** `POST /v1/indirects` creates the `@pi_{ispb}` account in Midaz before the participation row is written. You never create the account yourself.
2. **You fund it.** The position starts at zero, and the initial load comes from `@external/BRL` — the same posting mechanics as any opening balance. Until it holds funds, every payment leaving through that indirect participant refuses for insufficient balance. The step-by-step is [fund the position](/en/interfaces/pix-jd/hosting-indirect-participants#step-10-fund-the-position).
3. **Cash-in credits it.** An inbound Pix for a customer of an indirect participant posts to that institution's `@pi_{ispb}`. The money stops with you; the institution credits its own customer in its own core after your notice.
4. **Cash-out debits it.** An outbound order sent on behalf of an indirect participant debits its `@pi_{ispb}` — never your own accounts and never another indirect's.
5. **Closing requires a zeroed position.** `close` on a participation whose `@pi` account still holds funds is refused with `409 PIX-0096`, naming the cause. Money is never trapped inside a closed position.

## Hosting indirect participants does not change your own book

***

A deployment with hosting enabled keeps operating as a plain direct participant. On every inbound credit, the resolver asks the questions in this order:

1. **"Is this receiver ISPB our own?"** If yes, it is your book: the account resolves through the CRM, exactly as on a deployment that hosts nobody.
2. **Only then, "does it match an indirect participation?"** If an `ACTIVE` participation matches, the credit posts to that institution's `@pi_{ispb}`.
3. **Neither?** The credit is refused — nothing is guessed, and nothing is posted blindly.

The order is a protection, not a preference: it guarantees that credits for your own customers can never be diverted into a hosted institution's position, even by a mis-registered participation. Enabling the feature changes nothing on your own-book flow.

## A different axis: several direct participants on one deployment

***

Hosting indirect participants is not the only way a second institution appears on this rail, and the two must not be confused. An economic group — a holding operating, say, a payment institution and a credit fintech, each with its own ISPB — can run **both** institutions as direct participants on one deployment, through the [organization catalog](/en/interfaces/pix-jd/multi-organization-and-ledgers).

The two axes differ in everything that matters:

|                                          | An indirect participant                         | An additional organization                                        |
| ---------------------------------------- | ----------------------------------------------- | ----------------------------------------------------------------- |
| What it is                               | an institution that reaches Pix **through you** | a direct participant **in its own right**, operated by your group |
| Where its money lives                    | a `@pi_` position account inside **your** book  | its **own** Midaz organization and ledgers                        |
| Who settles at the Banco Central         | you, on your Conta PI                           | itself, on its own settlement account                             |
| Its credential at the connectivity layer | none — it rides yours                           | its own, per ISPB                                                 |

An indirect participant is a **position inside your book**; an additional organization is **another book entirely** — a separate regulated institution whose records never mix with yours. One deployment can do both at once: host indirect participants under one organization while operating several organizations of the same group.

## Where to go next

***

* **[Hosting indirect participants](/en/interfaces/pix-jd/hosting-indirect-participants)** — the provisioning: the encryption key, the posture, registering each institution, and funding its position.
* **[Multi-organization and ledgers](/en/interfaces/pix-jd/multi-organization-and-ledgers)** — the other axis: running several direct participants, and several books per participant, on one deployment.
* **[Indirect participants](/en/reference/interfaces/pix-jd/indirect-participants)** — what a hosted participation is, how money reaches one, and its lifecycle.
* **[Setting up the rail](/en/interfaces/pix-jd/pix-jd-setup)** — the direct-participant provisioning chain everything above builds on.
* **[Pix via JD](/en/interfaces/pix-jd/direct-pix-via-jd)** — the rail's overview and domain map.