What Lerian SISBAJUD does — and does not — do
- It is the judicial-order fulfilment boundary between the Judiciary and the institution’s ledger. It receives court orders by file and finds the affected accounts. It runs the block or unblock on the Midaz ledger and reports each outcome to BACEN.
- It does not accept court orders through its API. Court orders enter only as remittance files through BACEN’s STA channel.
POST /remittance-files/notificationsis an operational endpoint: it synchronously receives and parses a remittance object already delivered through that channel; it is not an order-entry endpoint. The remaining HTTP surface is administrative and observational. - It freezes funds without deleting them. A block execution can create one or more per-account block holdings, and an unblock can release held amounts across those holdings. Every ledger transaction accepted by Midaz must be balanced; this does not mean an entire judicial order or an individual block or unblock is one double-entry transaction.
- It is multi-tenant from the ground up. One deployment serves many institutions. It isolates each institution, so no order or file crosses an institution boundary.
Who it serves
Lerian SISBAJUD serves banks and financial institutions. Each one must honour judicial asset orders under the CNJ/BACEN SISBAJUD regime. Each institution keeps its own credentials, encrypted data, and ledger connection. One deployment serves many institutions at once, and none of them sees another’s orders.
Glossary
For how Lerian SISBAJUD sits alongside the other native rails and the partner interfaces, see Native messaging and partner interfaces.

