Skip to main content
Cada institución en Pix participa de una de dos formas. Un participante directo tiene su propia conexión con la infraestructura de liquidación del Banco Central y liquida Pix por derecho propio. Un participante indirecto no tiene conexión propia: contrata a un participante directo y opera a través de la conexión de ese participante. Este riel convierte a tu institución en el participante directo. Hospedar participantes indirectos es la función que permite que otras instituciones lleguen a Pix a través de ti.

​
Cada participante tiene su propio ISPB

Directo o indirecto, cada participante lleva un ISPB — el código de ocho dígitos que el Banco Central asigna a cada institución. Dos hechos sobre él deciden la mayor parte de lo que sigue:
  • El ISPB es identidad y enrutamiento. El ISPB de un participante indirecto es lo que lo nombra en cada mensaje de Pix: es cómo un crédito entrante encuentra a la institución correcta, y cómo una orden saliente dice en nombre de quién se mueve el dinero.
  • El ISPB no es liquidación. El Pix de un participante indirecto lo liquida el participante directo que lo hospeda. Tener un ISPB no le da a una institución una cuenta de liquidación en el Banco Central.
En este riel los dos ISPB viven en lugares distintos, a propósito. Tu propio ISPB es la identidad del despliegue, escrito una sola vez en la clave del systemplane tenancy/jd_integration_binding. El ISPB de cada participante indirecto va en su registro, y en ningún otro lugar — consulta Hospedar participantes indirectos para saber qué pasa cuando los dos se confunden.

​
Una cuenta de liquidación, tres capas de posición

La cuenta que liquida Pix en el Banco Central es la Conta PI — la cuenta de liquidación de Pix. Hay exactamente una por participante directo — en un deploy que opera varios participantes mediante el catálogo de organizaciones, cada uno tiene la suya. Un participante indirecto no tiene Conta PI; eso es lo que lo hace indirecto. Entonces, ¿dónde está el dinero de un participante indirecto? Su posición existe en tres capas, cada una en manos de una parte distinta: La tercera capa es donde realmente ocurre la segregación. Cada participante indirecto liquida en su propia cuenta @pi_{ispb}, así que el dinero de una institución nunca se mezcla con el de otra — y nunca con tu propio libro. Qué crea un registro y cómo se deriva el alias es Participantes indirectos.

​
Cómo controlas cada posición

El participante directo es dueño del ciclo de vida de cada posición, de punta a punta:
  1. Registrar crea la posición. POST /v1/indirects crea la cuenta @pi_{ispb} en Midaz antes de que se escriba la fila de la participación. Tú nunca creas la cuenta.
  2. Tú la fondeas. La posición empieza en cero, y la carga inicial viene de @external/BRL — la misma mecánica de asiento que cualquier saldo de apertura. Hasta que tenga fondos, todo pago que sale a través de ese participante indirecto rechaza por saldo insuficiente. El paso a paso es fondea la posición.
  3. El cash-in la acredita. Un Pix entrante para un cliente de un participante indirecto se contabiliza en la @pi_{ispb} de esa institución. El dinero se detiene en ti; la institución acredita a su propio cliente en su propio core después de tu aviso.
  4. El cash-out la debita. Una orden saliente enviada en nombre de un participante indirecto debita su @pi_{ispb} — nunca tus propias cuentas y nunca la de otro indirecto.
  5. Cerrar exige una posición en cero. close sobre una participación cuya cuenta @pi todavía mantiene fondos se rechaza con 409 PIX-0096, nombrando la causa. El dinero nunca queda atrapado dentro de una posición cerrada.

​
Hospedar participantes indirectos no cambia tu propio libro

Un despliegue con el hospedaje habilitado sigue operando como un participante directo simple. En cada crédito entrante, la resolución hace las preguntas en este orden:
  1. “¿Este ISPB receptor es el nuestro?” Si lo es, es tu libro: la cuenta se resuelve a través del CRM, exactamente como en un despliegue que no hospeda a nadie.
  2. Solo después, “¿coincide con una participación indirecta?” Si coincide una participación ACTIVE, el crédito se contabiliza en la @pi_{ispb} de esa institución.
  3. ¿Ninguna de las dos? El crédito se rechaza — nada se supone, y nada se contabiliza a ciegas.
El orden es una protección, no una preferencia: garantiza que los créditos de tus propios clientes nunca puedan desviarse a la posición de una institución hospedada, ni siquiera por una participación mal registrada. Habilitar la función no cambia nada en el flujo de tu propio libro.

​
Un eje distinto: varios participantes directos en un deploy

Hospedar participantes indirectos no es la única forma en que una segunda institución aparece en este riel, y los dos ejes no deben confundirse. Un grupo económico — un holding que opera, por ejemplo, una institución de pago y una fintech de crédito, cada una con su propio ISPB — puede operar ambas instituciones como participantes directos en un solo deploy, a través del catálogo de organizaciones. Los dos ejes difieren en todo lo que importa: Un participante indirecto es una posición dentro de tu libro; una organización adicional es otro libro por completo — una institución regulada separada cuyos registros nunca se mezclan con los tuyos. Un deploy puede hacer ambas cosas a la vez: hospedar participantes indirectos bajo una organización mientras opera varias organizaciones del mismo grupo.

​
A dónde ir después

  • Hospedar participantes indirectos — el aprovisionamiento: la clave de cifrado, la postura, el registro de cada institución y el fondeo de su posición.
  • Multiorganización y ledgers — el otro eje: operar varios participantes directos, y varios libros por participante, en un solo deploy.
  • Participantes indirectos — qué es una participación hospedada, cómo le llega el dinero y su ciclo de vida.
  • Configurar el riel — la cadena de aprovisionamiento del participante directo sobre la que se apoya todo lo anterior.
  • Pix vía JD — el resumen del riel y el mapa de dominios.