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

# Direct Pix via JD

> Direct Pix via JD: participate as a direct participant on SPI and DICT through JD's regulated connectivity, using Lerian's unified Pix Lerian API.

**Direct Pix via JD** is the connectivity path for **direct participants** in Pix. JD's regulated infrastructure connects your institution to BACEN's SPI and DICT. Your institution owns its Pix participation. JD provides the certified connectivity that reaches BACEN's network.

Lerian's Pix integration abstracts the connectivity provider behind a single API. The same Pix documentation applies to every provider:

* **[What is Pix?](/en/interfaces/pix/pix-overview)**: the rail itself, with modalities, SPI, DICT, and participation models.
* **[Pix Lerian](/en/interfaces/pix-lerian)**: the unified interface for DICT management, transfers, refunds, collections, and BR Codes.
* **[Plugin use cases](/en/interfaces/pix/pix-use-cases)**: end-to-end scenarios that combine Pix with fees, transaction routes, and the ledger.
* **[Indirect participants](/en/reference/interfaces/pix-jd/indirect-participants)**: how a smaller institution reaches SPI through your direct participation, where its money settles, and what registering one costs permanently.

## How Pix movements land in Midaz

***

The direct participation plugin posts every settled Pix movement to Midaz as a ledger transaction. The external leg goes against the clearing account (for example, `@external/BRL`). Settled movements include cash-out, cash-in, refunds (devolução), MED effectuation legs, and Pix Automático settlement. Midaz records the accounting entry. The payer and payee identity (bank, branch, account, holder name and document, Pix key) lives only in the plugin's own transaction record. Every BACEN reference lives only in that record.

Correlation between the two systems works through identifiers, not metadata:

* The **end-to-end ID (E2E)** is the idempotency key of the Midaz posting, so a retried settlement can never double-post to the ledger. Follow-up legs of the same E2E (a devolução or a MED effectuation) derive their key from the E2E with a flow suffix. They never collide with the original posting.
* The plugin stores the **Midaz posting ID** on its own transaction record. It uses that ID to commit or cancel the pending debit of a two-phase cash-out.

To see the banking detail behind a ledger entry, query the plugin's transaction API by the plugin transaction id or the E2E ID. The Midaz transaction itself carries no counterparty data and no custom metadata. The ledger stays pure accounting.

<Note>
  Lerian provisions the provider-specific configuration for direct participation via JD with your integration. To set up direct Pix participation, [get in touch with our team](https://lerian.studio/contact).
</Note>