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

# El modelo directo e indirecto

> Cómo funcionan la participación directa y la indirecta en Pix en este riel: qué identifica un ISPB, quién mantiene la cuenta de liquidación en el Banco Central, dónde se aloja realmente el dinero de un participante indirecto y cómo el participante directo controla cada posición.

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/interfaces/pix-jd/hosting-indirect-participants) 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](/es/interfaces/pix-jd/hosting-indirect-participants) 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:

| Capa | Dónde se mantiene  | Qué es                                                                                                                                                       |
| ---- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 1    | el Banco Central   | parte de la Conta PI del participante directo. El Banco Central ve un solo saldo — el tuyo. El dinero de cada institución hospedada está dentro de él        |
| 2    | JD                 | un límite y saldo interno por participante indirecto, que tú administras. Es cómo la capa de conectividad sabe cuánto puede mover cada institución hospedada |
| 3    | tu ledger de Midaz | la cuenta de posición `@pi_` seguida del ISPB de la institución — una por participante indirecto, creada por el plugin cuando registras la institución       |

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](/es/reference/interfaces/pix-jd/indirect-participants).

Una regla ata las capas: **la capa que autoriza un pago es tu ledger**. Un pago que excede el saldo en Midaz se rechaza **antes de que nada se envíe a JD** — el saldo en las otras capas, la Conta PI en el Banco Central o el límite de la institución en JD, no autoriza nada por sí solo. 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 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](/es/interfaces/pix-jd/hosting-indirect-participants#step-10-fund-the-position).
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](/es/interfaces/pix-jd/multi-organization-and-ledgers).

Los dos ejes difieren en todo lo que importa:

|                                          | Un participante indirecto                            | Una organización adicional                                           |
| ---------------------------------------- | ---------------------------------------------------- | -------------------------------------------------------------------- |
| Qué es                                   | una institución que llega a Pix **a través de ti**   | un participante directo **por derecho propio**, operado por tu grupo |
| Dónde vive su dinero                     | una cuenta de posición `@pi_` dentro de **tu** libro | su **propia** organización y ledgers en Midaz                        |
| Quién liquida en el Banco Central        | tú, en tu Conta PI                                   | ella misma, en su propia cuenta de liquidación                       |
| Su credencial en la capa de conectividad | ninguna — usa la tuya                                | la suya propia, por ISPB                                             |

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](/es/interfaces/pix-jd/hosting-indirect-participants)** — 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](/es/interfaces/pix-jd/multi-organization-and-ledgers)** — el otro eje: operar varios participantes directos, y varios libros por participante, en un solo deploy.
* **[Participantes indirectos](/es/reference/interfaces/pix-jd/indirect-participants)** — qué es una participación hospedada, cómo le llega el dinero y su ciclo de vida.
* **[Configurar el riel](/es/interfaces/pix-jd/pix-jd-setup)** — la cadena de aprovisionamiento del participante directo sobre la que se apoya todo lo anterior.
* **[Pix vía JD](/es/interfaces/pix-jd/direct-pix-via-jd)** — el resumen del riel y el mapa de dominios.