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

# How Lerian SISBAJUD works

> How Lerian SISBAJUD works: judicial-order file intake, block execution against the Midaz ledger, permanent block, unblock, and BACEN response files.

BACEN's file-exchange channel delivers every judicial order to Lerian SISBAJUD as a **remittance file**. Orders enter the integration as remittance files, not as API order payloads. The integration receives the file, parses it into canonical orders, and fulfils the block and unblock orders against the **Midaz** ledger. It then returns response files to BACEN. This page covers the three order kinds most institutions meet first: **block**, **unblock**, and **permanent block**. The integration also answers information requests.

## Order intake by file

***

BACEN delivers a **remittance file**. Order files use the codes `5301` and `5308` in production, and `5311` and `5318` in homologation. BACEN's validation verdicts on the response files come back as `5303` and `5310` in production, and `5313` and `5320` in homologation. Each code identifies a distinct file flow.

A remittance file reaches the service in one of two ways:

* **Lerian STA events.** With `STA_CONSUMER_ENABLED` on, the service consumes the file events that Lerian STA publishes.
* **Notification endpoint.** `POST /remittance-files/notifications` synchronously receives and parses a remittance object that is already stored. It accepts `5301`, `5303`, and `5308`, and their homologation codes.

Lerian SISBAJUD hashes the plaintext, envelope-encrypts it, stores the ciphertext, and normalizes the file into canonical judicial orders.

The block-remittance flow (`5301` in production and `5311` in homologation) uses a **fixed-width** format with ISO-8859-1 encoding. The 2026 layout uses 684-character records, and the CNJ v1.11 layout uses 410-character records. `SISBAJUD_REMITTANCE_LAYOUTS` sets which layouts the service accepts. The leading positions set each record type. A header and a trailer mark the file boundaries. In the 2026 layout, a per-order **permanent-block indicator** marks each block record:

| Indicator | Meaning |
| - | - |
| **T** | Traditional block: an initial, non-permanent attempt. After a partial initial block, the service keeps trying to block the rest until the end of the reception day (UTC). |
| **P** | Permanent block with no deadline. |
| **D** | Permanent block with a determined deadline. |

## Block execution (bloqueio)

***

For a block order, Lerian SISBAJUD decrypts the encrypted CPF/CNPJ to query CRM. It does not resolve accounts by token alone. It then resolves the defendant accounts and executes the requested block through Midaz. An execution can create per-account block holdings.

Every ledger transaction that Midaz accepts must be balanced. That invariant applies per accepted ledger transaction. It does not make an entire judicial order or a particular block or unblock leg a single double-entry transaction.

The service records the block on each account. The order outcome feeds the **response file** to BACEN.

## Permanent block

***

A permanent order (indicator **P** or **D**) does not stop after the first attempt. It stays in monitoring and re-attempts the block for the outstanding amount. This captures funds that arrive after the first attempt. A ledger balance-change event triggers a reattempt, and a scan every 5 seconds also processes open block orders. Both run only when `EXECUTION_ENABLED` is on.

Reattempts stop at the court deadline when it falls within 60 days of the first execution. Otherwise they stop 60 days after the first execution, the CNJ **reiteration ceiling**. The stop takes effect when the permanent-block expiry job runs (`PERMANENT_BLOCK_EXPIRY_ENABLED`). With `PERMANENT_BLOCK_EXPIRY_ENABLED` off, the default, reattempts do not stop at the deadline.

## Unblock (desbloqueio)

***

An unblock order releases previously held funds according to the order. It can release amounts across per-account block holdings. Each accepted ledger transaction must be balanced. An unblock order is not necessarily one ledger transaction. A background job picks up pending unblock orders while `EXECUTION_ENABLED` is on.

## Response files

***

Lerian SISBAJUD generates response files for BACEN:

* A **block response** (file type `5302` in production, `5312` in homologation) answers block and unblock orders.
* An **information response** (file type `5309` in production, `5319` in homologation) answers information requests.

Response-file generation picks up orders in a final state. With `STA_TRANSFERS_ENABLED` on, it submits each response file through Lerian STA.

The file-exchange transport itself is the client-owned integration that [Lerian STA](/en/rails/sta/what-is-lerian-sta) describes. Lerian SISBAJUD is one of its downstream source products.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.