Skip to main content
Every institution on Pix participates in one of two ways. A direct participant has its own connection to the Banco Central’s settlement infrastructure and settles Pix in its own right. An indirect participant has no connection of its own: it contracts a direct participant and operates through that participant’s connection. This rail makes your institution the direct participant. Hosting indirect participants is the feature that lets other institutions reach Pix through you.

​
Every participant has its own ISPB

Direct or indirect, every participant carries an ISPB — the eight-digit code the Banco Central assigns to every institution. Two facts about it decide most of what follows:
  • The ISPB is identity and routing. An indirect participant’s ISPB is what names it on every Pix message: it is how an inbound credit finds the right institution, and how an outbound order says on whose behalf the money moves.
  • The ISPB is not settlement. An indirect participant’s Pix is settled by the direct participant that hosts it. Having an ISPB does not give an institution a settlement account at the Banco Central.
On this rail the two ISPBs live in different places, on purpose. Your own ISPB is the deployment’s identity, written once in the systemplane key tenancy/jd_integration_binding. Each indirect participant’s ISPB goes in its registration, and nowhere else — see Hosting indirect participants for what happens when the two are confused.

​
One settlement account, three layers of position

The account that settles Pix at the Banco Central is the Conta PI — the Pix settlement account. There is exactly one per direct participant — on a deployment that operates several participants through the organization catalog, each holds its own. An indirect participant has no Conta PI; that is what makes it indirect. So where is an indirect participant’s money? Its position exists in three layers, each held by a different party: The third layer is where segregation actually happens. Each indirect participant settles on its own @pi_{ispb} account, so one institution’s money is never mixed with another’s — and never with your own book. What a registration creates and how the alias is derived is Indirect participants.

​
How you control each position

The direct participant owns the lifecycle of every position, end to end:
  1. Registering creates the position. POST /v1/indirects creates the @pi_{ispb} account in Midaz before the participation row is written. You never create the account yourself.
  2. You fund it. The position starts at zero, and the initial load comes from @external/BRL — the same posting mechanics as any opening balance. Until it holds funds, every payment leaving through that indirect participant refuses for insufficient balance. The step-by-step is fund the position.
  3. Cash-in credits it. An inbound Pix for a customer of an indirect participant posts to that institution’s @pi_{ispb}. The money stops with you; the institution credits its own customer in its own core after your notice.
  4. Cash-out debits it. An outbound order sent on behalf of an indirect participant debits its @pi_{ispb} — never your own accounts and never another indirect’s.
  5. Closing requires a zeroed position. close on a participation whose @pi account still holds funds is refused with 409 PIX-0096, naming the cause. Money is never trapped inside a closed position.

​
Hosting indirect participants does not change your own book

A deployment with hosting enabled keeps operating as a plain direct participant. On every inbound credit, the resolver asks the questions in this order:
  1. “Is this receiver ISPB our own?” If yes, it is your book: the account resolves through the CRM, exactly as on a deployment that hosts nobody.
  2. Only then, “does it match an indirect participation?” If an ACTIVE participation matches, the credit posts to that institution’s @pi_{ispb}.
  3. Neither? The credit is refused — nothing is guessed, and nothing is posted blindly.
The order is a protection, not a preference: it guarantees that credits for your own customers can never be diverted into a hosted institution’s position, even by a mis-registered participation. Enabling the feature changes nothing on your own-book flow.

​
A different axis: several direct participants on one deployment

Hosting indirect participants is not the only way a second institution appears on this rail, and the two must not be confused. An economic group — a holding operating, say, a payment institution and a credit fintech, each with its own ISPB — can run both institutions as direct participants on one deployment, through the organization catalog. The two axes differ in everything that matters: An indirect participant is a position inside your book; an additional organization is another book entirely — a separate regulated institution whose records never mix with yours. One deployment can do both at once: host indirect participants under one organization while operating several organizations of the same group.

​
Where to go next