Skip to main content
Lerian SISBAJUD handles the operational realities of judicial asset blocking. It fulfils and reports each order per institution, re-attempts permanent orders for weeks, and keeps personal data out of plaintext. It also proves every change it makes, because the law demands that proof. Per-institution isolation frames all of this.

​
Per-institution isolation

Lerian SISBAJUD is multi-tenant. The tenant is the database-isolation boundary. Lerian SISBAJUD reads it from the tenantId claim, and single-tenant mode uses the explicitly supplied DEFAULT_TENANT_ID. It has no effective string default, so a usable single-tenant deployment must set a valid UUID. The institution is a separate unit. Lerian SISBAJUD isolates each institution’s orders, files, credentials, and encryption keys. One tenant can hold many institutions, and one deployment serves them all with no cross-institution visibility.

​
Reconciliation

Reconciliation works at the grain of one monitoring order against a ledger balance snapshot. A scheduled scan compares outstanding orders to the ledger and records any gap it finds. An operator can also start a manual reconciliation on demand. A separate daily sweep closes monitoring orders that pass their ceiling or deadline, so nothing lingers past its legal life.

​
Permanent-block cadence

Permanent orders re-attempt the block on ledger balance-change events. The CNJ 60-day reiteration ceiling, or the order’s court deadline, bounds each order. There is no scheduled reattempt pass. A deposit wakes the reattempt directly, and a daily expiry sweep closes orders whose deadline has lapsed.

​
Credentials and key rotation

Two things rotate per institution, and both are administrative:
  • Connector credentials. Lerian SISBAJUD uses these credentials to reach the ledger and the file-exchange channel. An operator registers and rotates them.
  • Key-encryption key (KEK). An operator rotates the institution’s KEK, and the rotation emits a kek.rotated event. Each record’s data key (DEK) sits under the KEK. A rotation therefore bumps the active KEK version without re-encrypting any field. Data keys sealed under the previous version stay readable, and a background re-wrap then advances them to the new version. A rotation that another rotation is already running returns SBJ-0007 / 409. A rotation that commits but cannot be audited returns SBJ-0002 / 500 — the KEK has already advanced, so this is not retryable: retrying rotates a second time and widens the audit gap. Escalate and reconcile the audit trail against the kek.rotated event instead.

​
Data protection

Lerian SISBAJUD protects personal data at rest by design:
  • Envelope encryption. Each record carries its own data key, sealed under the institution’s KEK with AES-256-GCM. Per-field additional authenticated data binds each ciphertext to one field and record, so no one can swap a ciphertext between fields or records.
  • Searchable tokenization. A blind index supports exact-match indexing on fiscal identifiers (CPF/CNPJ) and the process number without plaintext storage. It does not replace account discovery: to query CRM, Lerian SISBAJUD decrypts the CPF/CNPJ only as needed and never logs it. Lerian SISBAJUD encrypts free text only and never tokenizes it. It does not tokenize monetary values, and it stores the order tables’ monetary values as plaintext, not ciphertext.
  • Tamper-evident audit trail. Lerian SISBAJUD appends every state change to a gap-free, cryptographically protected log. A per-event authentication code binds each entry to its position. Merkle leaf hashes let an operator verify the trail without decrypting any payload.
  • LGPD. A subject-access request exports the data the institution holds on a subject. Crypto-erasure honours an erasure request. It destroys the record’s key and tombstones its plaintext values, so the personal data becomes irrecoverable, while the audit record of the change survives.

​
Contingency

Lerian SISBAJUD drives failed orders to a FAILED terminal state, not stuck in processing, and an operator can reprocess them. The SLA-status and processing-statistics views show where orders stand. Connector resolution fails closed. If the integration cannot safely resolve an account or a credential, it refuses the operation rather than act on an ambiguous target.

​
HTTP surface

Orders arrive only by file, so the HTTP surface submits no court orders. Most endpoints are administrative and observational. POST /remittance-files/notifications is operational: it synchronously receives and parses a remittance object already delivered through the file-exchange channel; it does not accept an order payload. An operator can:
  • list orders and files, and read the detail of a single order or file
  • reprocess failed orders
  • run a reconciliation and read its status
  • view SLA status and processing statistics
  • verify the audit trail
  • handle LGPD requests — create them, resolve them, run an erasure, and export a subject’s data
  • register non-compliance justifications
  • configure the institution, and register or rotate connector credentials