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

> The judicial-order lifecycle — file intake and parsing, block execution against the Midaz ledger, the daily-reattempt permanent block, unblock, and the syntactic-validation and fulfilment result files returned to BACEN.

Every judicial order reaches Lerian SISBAJUD as a **remittance file** delivered through BACEN's file-exchange channel — never through its API. The integration receives the file, parses it into canonical orders, fulfils each order against the **Midaz** ledger, and returns result files to BACEN. This page covers the three order kinds the integration fulfils end to end: **block**, **unblock**, and **permanent block**.

## Order intake by file

***

BACEN delivers a **remittance file** (file type `5301` in production, `5311` in homologation). On receipt, Lerian SISBAJUD hashes the plaintext, envelope-encrypts it, stores the ciphertext, and then parses the file into canonical judicial orders.

The remittance is a **fixed-width** format: each record is 684 characters, ISO-8859-1 encoded. Records are typed by their leading positions — a header and trailer bound the file, and the body carries the order records (block and reiteration, unblock, and permanent-block interruption among them). A per-order **permanent-block indicator** marks each block record:

| Indicator | Meaning                                                |
| --------- | ------------------------------------------------------ |
| **T**     | Traditional block — a one-time attempt, not permanent. |
| **P**     | Permanent block with no deadline.                      |
| **D**     | Permanent block with a determined deadline.            |

## Block execution (bloqueio)

***

For a block order, Lerian SISBAJUD resolves the defendant's account or accounts by their **fiscal-identifier token**, then moves the full court-ordered amount from each customer account into a dedicated, **per-order block account** on the Midaz ledger. The movement is a balanced double-entry posting: no value is created or destroyed, it is relocated to an account where it is held unavailable.

The per-account outcome — how much was blocked against how much was ordered — feeds both the **response file** returned to BACEN and the tamper-evident audit trail.

## Permanent block (reiteração)

***

A permanent order (indicator **P** or **D**) does not stop after the first attempt. It stays in monitoring and **re-attempts the block daily**, business-day aware, so that funds arriving after the first attempt are captured. Reattempts are driven by ledger balance-change events: when a monitored account's balance rises, the integration attempts to block the still-outstanding amount.

Monitoring is bounded — a permanent order runs until the CNJ **60-day reiteration ceiling** or the order's own deadline, whichever applies, after which the expired order is swept closed.

## Unblock (desbloqueio)

***

An unblock order reverses a prior freeze: Lerian SISBAJUD returns the ordered value from the per-order block account back to the customer account, again as a balanced double-entry movement, and reports the outcome in the return file.

## Response and return files

***

Lerian SISBAJUD generates and transmits result files back to BACEN over the same file-exchange channel:

* A **syntactic-validation result** (file type `5303` in production, `5313` in homologation), reporting whether the remittance was structurally accepted.
* **Fulfilment result** files carrying the per-order, per-account outcomes of the blocks and unblocks.

The file-exchange transport itself is the client-owned integration described in [Lerian STA](/en/rails/native/sta/what-is-lerian-sta); Lerian SISBAJUD is one of its downstream source products, consuming the inbound judicial files it delivers.