Saltar al contenido principal
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. Con Hospedar participantes indirectos, otras instituciones pueden llegar a Pix a través de ti.

​
Cada participante tiene su propio ISPB

Directo o indirecto, cada participante lleva un ISPB. El ISPB es el código de 8 caracteres, letras mayúsculas o dígitos, que el Banco Central da a cada institución. Dos hechos sobre él deciden la mayor parte de lo que sigue:
  • El ISPB da identidad y enrutamiento. El ISPB de un participante indirecto lo nombra en cada mensaje de Pix. Un crédito entrante lo usa para encontrar a la institución correcta. Una orden saliente lo usa para decir en nombre de quién se mueve el dinero.
  • El ISPB no es liquidación. El participante directo que hospeda a un participante indirecto liquida su Pix. 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. Lo escribes 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. Hospedar participantes indirectos explica qué pasa cuando confundes los dos.

​
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. Un deploy puede operar varios participantes mediante el catálogo de organizaciones. En ese caso, cada participante tiene su propia Conta PI. Un participante indirecto no tiene Conta PI. Eso es lo que lo hace indirecto. La posición de un participante indirecto existe en tres capas, y una parte distinta mantiene cada capa: La segregación ocurre en la tercera capa. Cada participante indirecto liquida en su propia cuenta @pi_{ispb}. El dinero de una institución nunca se mezcla con el de otra, ni con tu propio libro. Participantes indirectos explica qué crea un registro y cómo el plugin deriva el alias. Tu ledger es la capa que autoriza un pago. El riel rechaza un pago que excede el saldo en Midaz antes de enviar nada a JD. Un saldo en las otras capas no autoriza nada por sí solo. Eso incluye la Conta PI en el Banco Central y el límite de una institución en JD. Cuando el ledger dice que no, la orden nunca sale de tu lado.

​
Cómo controlas cada posición

El participante directo es dueño del ciclo de vida de cada posición, de principio a fin:
  1. El registro crea la posición. POST /v1/indirects crea la cuenta @pi_{ispb} en Midaz antes de escribir la fila de la participación. Tú nunca creas la cuenta.
  2. Tú la fondeas. La posición empieza en cero. La carga inicial viene de la cuenta de compensación externa (por ejemplo, @external/BRL), con la misma mecánica de asiento que cualquier saldo de apertura. Hasta que la posición tenga fondos, el riel rechaza todo pago que sale a través de ese participante indirecto, por saldo insuficiente. Para el procedimiento, consulta 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. Después de tu aviso, la institución acredita a su propio cliente en su propio core.
  4. El cash-out la debita. Una orden saliente en nombre de un participante indirecto debita su @pi_{ispb}. Nunca debita tus propias cuentas ni la posición de otro participante indirecto.
  5. Un cierre necesita una posición en cero. El riel rechaza close con 409 PIX-0096 mientras la cuenta @pi todavía tenga fondos, y la respuesta nombra la causa. Una posición cerrada nunca atrapa dinero.

​
Hospedar participantes indirectos no cambia tu propio libro

Un despliegue con el hospedaje habilitado continúa operando como un participante directo simple. En cada crédito entrante, la resolución hace sus preguntas en este orden:
  1. “¿Este ISPB receptor es el nuestro?” Si lo es, el crédito es para tu libro. La cuenta se resuelve a través del CRM, 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 riel rechaza el crédito. No supone nada y no contabiliza nada a ciegas.
El orden es una protección, no una preferencia. Los créditos de tus propios clientes nunca pueden ir a la posición de una institución hospedada, ni siquiera por una participación que registraste mal. Cuando habilitas la función, nada cambia 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. No confundas las dos. Un grupo económico puede operar ambas instituciones del grupo como participantes directos en un solo deploy, a través del catálogo de organizaciones. Por ejemplo, un holding puede operar una institución de pago y una fintech de crédito, cada una con su propio ISPB. 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, y sus registros nunca se mezclan con los tuyos. Un deploy puede hacer ambas cosas a la vez. Puede hospedar participantes indirectos bajo una organización y operar varias organizaciones del mismo grupo.

​
A dónde ir después