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 ledger, 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, not a rule. An event decides nothing by itself. It wakes the permanent-block logic to re-evaluate a monitored account and attempt the outstanding block. A reiteração 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. Each event carries the tenant identity. The integration correlates each balance change only to orders of the same institution. Per-institution isolation holds across the event boundary.

​
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 — an operational signal, not a money or PII carrier.
  • A key-rotated event when an institution rotates its master encryption key.
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 only for the CRM query and never logs it; it does not resolve an account by token alone
  • reads the available balance of a monitored account
  • reconciles monitoring orders against ledger balance snapshots
The downstream block code makes block writes idempotent. A retried block does not double-post.

​
Delivery semantics

  • Idempotent block writes. The downstream block code keys each block write. A replay does not double-post.
  • 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; downstream block-code idempotency is the backstop against duplicate block application.
  • Tenant on every event. The institution identity travels with each event. This keeps per-institution isolation intact from end to end.
  • 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 consumer of that transport. Lerian STA delivers the inbound remittance object and its integrity claim-check; POST /remittance-files/notifications then synchronously receives and parses the already-delivered object. Lerian SISBAJUD executes the order and returns the result files.