Skip to main content
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 each order against the Midaz ledger. It then returns result files to BACEN. This page covers the three order kinds most institutions meet first: block, unblock, and permanent block. The integration also fulfils judicial transfer, precautionary (cautelar) account block, annulment, cancellation, guarantee liquidation, information requests, and confidentiality-breach orders.

​
Order intake by file

BACEN delivers a remittance file. The service accepts 5301, 5303, and 5308 in production, and 5311, 5313, and 5318 in homologation. Each code identifies a distinct file flow and parser. After a remittance object has been delivered, POST /remittance-files/notifications synchronously receives and parses that already-delivered object. 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. Each record is 684 characters and uses ISO-8859-1 encoding. The leading positions set each record type. A header and a trailer mark the file boundaries. 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:

​
Block execution (bloqueio)

For a block order, Lerian SISBAJUD decrypts the encrypted CPF/CNPJ only to query CRM and never logs it; 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. Each account produces an outcome: the blocked amount against the ordered amount. This outcome feeds both the response file 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 until its deadline. This captures funds that arrive after the first attempt. Reattempts are event-driven, not scheduled. A ledger balance-change event wakes each reattempt. When a monitored account balance rises, the integration blocks the still-outstanding amount. Monitoring has a bound. A permanent order runs until the CNJ 60-day reiteration ceiling or its own deadline, whichever applies. The integration then sweeps the expired order closed.

​
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. The integration 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) that reports whether the remittance passed structural validation.
  • Fulfilment result files that carry the per-order, per-account outcomes of the blocks and unblocks.
The file-exchange transport itself is the client-owned integration that Lerian STA describes. Lerian SISBAJUD is one of its downstream source products. It consumes the inbound judicial files that STA delivers.