Skip to main content
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 é 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 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: 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.

​
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.
  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. Os dois eixos diferem em tudo o que importa: 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 — 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 — o outro eixo: rodar vários participantes diretos, e vários livros por participante, em um deploy.
  • Participantes indiretos — o que uma participação hospedada é, como o dinheiro chega a uma, e o ciclo de vida dela.
  • Configurar o trilho — a cadeia de provisionamento do participante direto sobre a qual tudo acima se apoia.
  • Pix via JD — a visão geral do trilho e o mapa de domínios.