Skip to main content
Lerian SISBAJUD is event-first where it meets the ledger. It consumes balance-change events from Midaz to drive permanent blocks. It emits operational business events that other systems can observe. It sends no outbound webhooks to third-party consumers. Its interfaces are the Midaz ledger, Lerian STA, the remittance-delivery notification endpoint, and its administrative surface.

​
Ledger events it consumes

The integration subscribes to Midaz balance-change events. It treats each event as a trigger. An event decides nothing by itself. The integration matches the event’s account against the accounts that earlier blocks drew from. It then runs the block logic for the open orders of that account’s holder. A permanent block uses this path to capture funds that arrive after the first attempt. After a partial initial traditional block, a credit later that day can also trigger complementary attempts.

​
Business events it emits

Lerian SISBAJUD emits operational business events with no personal data in their payloads:
  • A block-account-created event when an execution creates a block holding. It is an operational signal, not a money or PII carrier.
  • A key-rotated event (kek.rotated) when an operator rotates an institution’s key-encryption key with Vault as the key provider.
These events serve observability and coordination. The money movements live in the Midaz ledger, not in the event payloads.

​
Midaz boundary

Midaz is the ledger connector. Through it, Lerian SISBAJUD:
  • submits block and unblock operations for the relevant customer accounts and block holdings
  • creates and archives block holdings as an execution needs them
  • decrypts the CPF/CNPJ to query CRM for the defendant’s accounts. It does not resolve an account by token alone
  • reads the available balance of a monitored account
  • reconciles monitoring orders against ledger balance snapshots

​
Delivery semantics

  • Deduplicated block writes. The service deduplicates block writes by institution and block code in its own store before it calls the ledger.
  • At-least-once events. Under normal cache operation, Lerian SISBAJUD suppresses duplicate event identifiers. If the cache is unavailable, deduplication fails open and the event proceeds.
  • Tenant scope. Consumed balance-change events carry the institution identity. The integration correlates each balance change only to orders of the same institution.
  • No outbound third-party webhooks. Lerian SISBAJUD does not push to third-party webhook consumers. It also exposes an operational remittance-delivery notification endpoint. That endpoint is not an order-entry API.

​
File transport

Judicial files enter and leave over BACEN’s file-exchange channel. Lerian STA documents this client-owned integration. Lerian SISBAJUD is a source product of that transport:
  • Inbound. With STA_CONSUMER_ENABLED on, the service consumes the file events that Lerian STA publishes. Each event names the stored object and its SHA-256 digest. The service reads the object and checks the digest before it parses the file. POST /remittance-files/notifications also receives and parses an object that is already stored.
  • Outbound. With STA_TRANSFERS_ENABLED on, the service submits each response file through Lerian STA. When it is off, the service generates response files but does not submit them.
  • Dead letter. The consumer sends an event that a retry cannot fix to a dead-letter topic. Acknowledging an event does not remove it. The topic keeps events for its retention period. POST /admin/sta-dlq/{eventId}/acknowledge records how an operator treated a dead-lettered event in the audit trail.