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 it settles Pix in its own right. An indirect participant has no connection of its own. It contracts a direct participant and operates through the connection of that participant. This rail makes your institution the direct participant. With Hosting indirect participants, other institutions can reach Pix through you.

​
Every participant has its own ISPB

Direct or indirect, every participant carries an ISPB. The ISPB is the eight-digit code that the Banco Central gives to every institution. Two facts about it decide most of what follows:
  • The ISPB gives identity and routing. The ISPB of an indirect participant names it on every Pix message. An inbound credit uses it to find the right institution. An outbound order uses it to say on whose behalf the money moves.
  • The ISPB is not settlement. The direct participant that hosts an indirect participant settles its Pix. 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 identity of the deployment. You write it once, in the systemplane key tenancy/jd_integration_binding. The ISPB of each indirect participant goes in its registration, and nowhere else. Hosting indirect participants tells what happens when you confuse the two.

​
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. A deployment can operate several participants through the organization catalog. Then each participant holds its own Conta PI. An indirect participant has no Conta PI. That is what makes it indirect. So where is the money of an indirect participant? Its position exists in three layers, and a different party holds each layer: Segregation happens at the third layer. Each indirect participant settles on its own @pi_{ispb} account. The money of one institution never mixes with the money of another, or with your own book. Indirect participants tells what a registration creates and how the plugin derives the alias. One rule ties the layers together: your ledger is the layer that authorizes a payment. The rail refuses a payment that exceeds the Midaz balance before it sends anything to JD. A balance at the other layers authorizes nothing by itself. That includes the Conta PI at the Banco Central and the limit of an institution at JD. When the ledger says no, the order never leaves your side.

​
How you control each position

The direct participant owns the lifecycle of every position, from start to end:
  1. Registration creates the position. POST /v1/indirects creates the @pi_{ispb} account in Midaz before it writes the participation row. You never create the account yourself.
  2. You fund it. The position starts at zero. The initial load comes from the external clearing account (for example, @external/BRL), with the same posting mechanics as any opening balance. Until the position holds funds, the rail refuses every payment that leaves through that indirect participant, for insufficient balance. For the procedure, see fund the position.
  3. Cash-in credits it. An inbound Pix for a customer of an indirect participant posts to the @pi_{ispb} of that institution. The money stops with you. After your notice, the institution credits its own customer in its own core.
  4. Cash-out debits it. An outbound order on behalf of an indirect participant debits its @pi_{ispb}. It never debits your own accounts or the position of another indirect participant.
  5. A close needs a zero position. The rail refuses close with 409 PIX-0096 while the @pi account still holds funds, and the answer names the cause. A closed position never traps money.

​
Hosting indirect participants does not change your own book

A deployment with hosting enabled continues to operate as a plain direct participant. On every inbound credit, the resolver asks its questions in this order:
  1. “Is this receiver ISPB our own?” If yes, the credit is for your book. The account resolves through the CRM, 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 the @pi_{ispb} of that institution.
  3. Neither? The rail refuses the credit. It guesses nothing and posts nothing blindly.
The order is a protection, not a preference. Credits for your own customers can never go into the position of a hosted institution, even through a participation that you registered incorrectly. When you enable the feature, nothing changes on the flow of your own book.

​
A different axis: several direct participants on one deployment

Hosting indirect participants is not the only way that a second institution appears on this rail. Do not confuse the two. An economic group can run both of its institutions as direct participants on one deployment, through the organization catalog. For example, a holding can operate a payment institution and a credit fintech, each with its own ISPB. 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, and its records never mix with yours. One deployment can do both at once. It can host indirect participants under one organization and operate several organizations of the same group.

​
Where to go next

  • Hosting indirect participants: the provisioning. It covers the encryption key, the posture, the registration of each institution, and the funding of its position.
  • Multi-organization and ledgers: the other axis. It covers several direct participants, and several books per participant, on one deployment.
  • Indirect participants: what a hosted participation is, how money gets to one, and its lifecycle.
  • Setting up the rail: the provisioning chain of the direct participant. Everything above builds on it.
  • Pix via JD: the overview of the rail and its domain map.