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

# O modelo direto e indireto

> Como funcionam as participações direta e indireta no Pix neste trilho: o que um ISPB identifica, quem detém a conta de liquidação no Banco Central, onde o dinheiro de um participante indireto de fato fica e como o participante direto controla cada posição.

Toda instituição no Pix participa de uma de duas formas. Um **participante direto** tem conexão própria com a infraestrutura de liquidação do Banco Central e liquida Pix por direito próprio. Um **participante indireto** não tem conexão própria: ele contrata um participante direto e opera pela conexão desse participante.

Este trilho torna a sua instituição o participante direto. [Hospedar participantes indiretos](/pt/interfaces/pix-jd/hosting-indirect-participants) é a funcionalidade que permite que outras instituições alcancem o Pix por você.

## Todo participante tem o próprio ISPB

***

Direto ou indireto, todo participante carrega um **ISPB** — o código de oito dígitos que o Banco Central atribui a cada instituição. Dois fatos sobre ele decidem a maior parte do que vem a seguir:

* **O ISPB é identidade e roteamento.** O ISPB de um participante indireto é o que o nomeia em cada mensagem Pix: é como um crédito recebido encontra a instituição certa, e como uma ordem de saída diz em nome de quem o dinheiro se move.
* **O ISPB não é liquidação.** O Pix de um participante indireto é liquidado pelo participante direto que o hospeda. Ter um ISPB não dá a uma instituição uma conta de liquidação no Banco Central.

Neste trilho os dois ISPBs vivem em lugares diferentes, de propósito. O seu próprio ISPB é a identidade do deploy, escrita uma vez na chave do systemplane `tenancy/jd_integration_binding`. O ISPB de cada participante indireto vai no cadastro dele, e em nenhum outro lugar — veja [Hospedar participantes indiretos](/pt/interfaces/pix-jd/hosting-indirect-participants) para o que acontece quando os dois são confundidos.

## Uma conta de liquidação, três camadas de posição

***

A conta que liquida Pix no Banco Central é a **Conta PI** — a conta de liquidação do Pix. Existe exatamente **uma por participante direto** — em um deploy que opera vários participantes pelo catálogo de organizações, cada um tem a sua. Um participante indireto não tem Conta PI; é isso que o torna indireto.

Então onde está o dinheiro de um participante indireto? A posição dele existe em três camadas, cada uma mantida por uma parte diferente:

| Camada | Mantida em            | O que é                                                                                                                                                          |
| ------ | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1      | o Banco Central       | parte da Conta PI do participante direto. O Banco Central vê um saldo — o seu. O dinheiro de cada instituição hospedada está dentro dele                         |
| 2      | JD                    | um limite e um saldo internos por participante indireto, que você administra. É como a camada de conectividade sabe quanto cada instituição hospedada pode mover |
| 3      | o seu ledger no Midaz | a conta de posição `@pi_` seguida do ISPB da instituição — uma por participante indireto, criada pelo plugin quando você cadastra a instituição                  |

A terceira camada é onde a segregação de fato acontece. Cada participante indireto liquida na própria conta `@pi_{ispb}`, então o dinheiro de uma instituição nunca se mistura com o de outra — nem com o seu próprio livro. O que um cadastro cria e como o alias deriva está em [Participantes indiretos](/pt/reference/interfaces/pix-jd/indirect-participants).

Uma regra amarra as camadas: **a camada que autoriza um pagamento é o seu ledger**. Um pagamento que excede o saldo no Midaz é recusado **antes de qualquer coisa ser enviada à JD** — saldo parado nas outras camadas, a Conta PI no Banco Central ou o limite da instituição na JD, não autoriza nada por si só. Quando o ledger diz não, a ordem nunca sai do seu lado.

## Como você controla cada posição

***

O participante direto é dono do ciclo de vida de cada posição, de ponta a ponta:

1. **O cadastro cria a posição.** `POST /v1/indirects` cria a conta `@pi_{ispb}` no Midaz antes que a linha da participação seja gravada. Você nunca cria a conta por conta própria.
2. **Você coloca saldo nela.** A posição começa em zero, e a carga inicial vem de `@external/BRL` — a mesma mecânica de lançamento de qualquer saldo de abertura. Até que ela tenha fundos, todo pagamento que sai por aquele participante indireto recusa por saldo insuficiente. O passo a passo está em [coloque saldo na posição](/pt/interfaces/pix-jd/hosting-indirect-participants#step-10-fund-the-position).
3. **O cash-in a credita.** Um Pix recebido para um cliente de um participante indireto é lançado na `@pi_{ispb}` daquela instituição. O dinheiro para com você; a instituição credita o próprio cliente no próprio core depois do seu aviso.
4. **O cash-out a debita.** Uma ordem de saída enviada em nome de um participante indireto debita a `@pi_{ispb}` dele — nunca as suas próprias contas e nunca a de outro indireto.
5. **Encerrar exige a posição zerada.** Um `close` em uma participação cuja conta `@pi` ainda tem fundos é recusado com `409 PIX-0096`, nomeando a causa. O dinheiro nunca fica preso dentro de uma posição encerrada.

## Hospedar participantes indiretos não muda o seu próprio livro

***

Um deploy com a hospedagem habilitada continua operando como um participante direto comum. Em cada crédito recebido, a resolução faz as perguntas nesta ordem:

1. **"Este ISPB do recebedor é o nosso?"** Se sim, é o seu livro: a conta resolve pelo CRM, exatamente como em um deploy que não hospeda ninguém.
2. **Só então, "corresponde a uma participação indireta?"** Se uma participação `ACTIVE` corresponde, o crédito é lançado na `@pi_{ispb}` daquela instituição.
3. **Nenhum dos dois?** O crédito é recusado — nada é adivinhado, e nada é lançado às cegas.

A ordem é uma proteção, não uma preferência: ela garante que créditos dos seus próprios clientes nunca possam ser desviados para a posição de uma instituição hospedada, nem por uma participação cadastrada errado. Habilitar a funcionalidade não muda nada no fluxo do seu próprio livro.

## Um eixo diferente: vários participantes diretos em um deploy

***

Hospedar participantes indiretos não é a única forma de uma segunda instituição aparecer neste trilho, e os dois não devem ser confundidos. Um grupo econômico — uma holding que opera, digamos, uma instituição de pagamento e uma fintech de crédito, cada uma com o próprio ISPB — pode rodar as **duas** instituições como participantes diretos em um deploy, pelo [catálogo de organizações](/pt/interfaces/pix-jd/multi-organization-and-ledgers).

Os dois eixos diferem em tudo o que importa:

|                                              | Um participante indireto                            | Uma organização adicional                                              |
| -------------------------------------------- | --------------------------------------------------- | ---------------------------------------------------------------------- |
| O que é                                      | uma instituição que alcança o Pix **por você**      | um participante direto **por direito próprio**, operado pelo seu grupo |
| Onde o dinheiro dele fica                    | uma conta de posição `@pi_` dentro do **seu** livro | a **própria** organização e os próprios ledgers no Midaz               |
| Quem liquida no Banco Central                | você, na sua Conta PI                               | ela mesma, na própria conta de liquidação                              |
| A credencial dele na camada de conectividade | nenhuma — ele usa a sua                             | a própria, por ISPB                                                    |

Um participante indireto é uma **posição dentro do seu livro**; uma organização adicional é **outro livro por inteiro** — uma instituição regulada separada cujos registros nunca se misturam com os seus. Um deploy pode fazer os dois ao mesmo tempo: hospedar participantes indiretos sob uma organização enquanto opera várias organizações do mesmo grupo.

## Para onde ir agora

***

* **[Hospedar participantes indiretos](/pt/interfaces/pix-jd/hosting-indirect-participants)** — o provisionamento: a chave de criptografia, a postura, o cadastro de cada instituição e o saldo da posição dela.
* **[Multiorganização e ledgers](/pt/interfaces/pix-jd/multi-organization-and-ledgers)** — o outro eixo: rodar vários participantes diretos, e vários livros por participante, em um deploy.
* **[Participantes indiretos](/pt/reference/interfaces/pix-jd/indirect-participants)** — o que uma participação hospedada é, como o dinheiro chega a uma, e o ciclo de vida dela.
* **[Configurar o trilho](/pt/interfaces/pix-jd/pix-jd-setup)** — a cadeia de provisionamento do participante direto sobre a qual tudo acima se apoia.
* **[Pix via JD](/pt/interfaces/pix-jd/direct-pix-via-jd)** — a visão geral do trilho e o mapa de domínios.