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, and it emits operational business events that other systems can observe. It has no external webhook consumers — its edges are the ledger and its own administrative surface.

​
Ledger events it consumes

The integration subscribes to Midaz balance-change events. It treats these as a trigger, not a rule: an event does not by itself decide anything, it wakes the permanent-block logic to re-evaluate a monitored account and attempt the still-outstanding block. This is how a reiteração captures funds that arrive after the first attempt. Each event carries the tenant identity, so a balance change is correlated only to orders belonging to 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 it opens a dedicated block account for an order — an operational signal, not a money or PII carrier.
  • A key-rotated event when an institution’s master encryption key is rotated.
These events are for observability and coordination; the money movements themselves live in the Midaz ledger, not in the event payloads.

​
Midaz boundary

Midaz is the ledger connector. Through it, Lerian SISBAJUD:
  • blocks and unblocks funds by moving them between the customer account and the per-order block account;
  • creates and archives a dedicated block account per order;
  • resolves an account by its fiscal-identifier token;
  • reads the available balance of a monitored account; and
  • reconciles monitoring orders against ledger balance snapshots.
All ledger writes are idempotent by a unique code, so a retried order never double-posts.

​
Delivery semantics

  • Idempotent writes. Every write operation is keyed by a unique code; replaying it is a no-op.
  • At-least-once events. Consumed events are delivered at least once and deduplicated by event identifier, so a redelivered balance change does not trigger a duplicate reattempt.
  • Tenant on every event. The institution identity travels with each event, keeping per-institution isolation intact end to end.
  • No external webhooks. Lerian SISBAJUD does not push to third-party webhook consumers; integration is through the ledger and the administrative API.

​
File transport

Judicial files enter and leave over BACEN’s file-exchange channel — the client-owned integration documented in Lerian STA. Lerian SISBAJUD is a source-product consumer of that transport: Lerian STA delivers the inbound remittance file and its integrity claim-check, and Lerian SISBAJUD parses, fulfils, and returns the result files.