> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Operating Lerian SISBAJUD > Operating Lerian SISBAJUD: per-institution scope, reconciliation, permanent-block cadence, response windows, key and credential rotation, and envelope-encryption guarantees. Lerian SISBAJUD encrypts the personal data it keeps in its own database and bucket. It also keeps an audit trail of the changes it makes. ## Per-institution scope *** Lerian SISBAJUD runs single-tenant by default. In multi-tenant mode, the tenant is the database-isolation boundary: each tenant has its own database, and Lerian SISBAJUD reads the tenant from the `tenantId` claim. Single-tenant mode uses `DEFAULT_TENANT_ID`, which defaults to `11111111-1111-1111-1111-111111111111`. The institution is a separate unit. Lerian SISBAJUD scopes each institution's orders, files, credentials, and encryption keys. One tenant can hold many institutions, and one deployment serves them all. ## Reconciliation *** Reconciliation compares, for each block account of a monitoring order, the amount the service blocked against the ledger's available balance. A **scheduled scan** (`RECONCILIATION_ENABLED`, hourly by default) records the gaps it finds in the audit trail. With `EXECUTION_ENABLED` on, a gap also starts a recovery run for the account holder. An operator can also start a **manual reconciliation** on demand, even with the scheduled scan off. Two daily jobs close out monitoring. Both are off by default: * `MONITORING_EXPIRY_ENABLED` closes non-permanent monitoring orders whose monitoring window has passed. With it off, a partly blocked traditional order stays in monitoring and gets no response. * `PERMANENT_BLOCK_EXPIRY_ENABLED` stops reattempts on permanent blocks past their deadline. ## Permanent-block cadence *** Permanent orders re-attempt the block **on ledger balance-change events** and on a **scan every 5 seconds**, while `EXECUTION_ENABLED` is on. With `PERMANENT_BLOCK_EXPIRY_ENABLED` off, the default, reattempts do not stop at the deadline. [How Lerian SISBAJUD works](/en/rails/sisbajud/how-sisbajud-works#permanent-block) describes the deadlines. ## Response windows *** BACEN sets the block-response deadline by the send time of each remittance. A remittance sent up to 13:00 BRT is due by 19:00 BRT the same day. A remittance sent after 13:00 BRT is due by 12:00 BRT the next business day. Lerian SISBAJUD generates response files on an interval, not at fixed times. Set `RETURN_FILE_GENERATION_SCAN_INTERVAL` and `INFORMATION_RETURN_FILE_GENERATION_SCAN_INTERVAL` so each cycle meets BACEN's deadlines. Both default to one hour. ## Credentials and key rotation *** Rotation is administrative and runs per institution: * **Connector credentials.** Lerian SISBAJUD uses these credentials to reach the Midaz ledger and, in `legacy` CRM mode, the CRM. An operator sets them in the institution configuration: `POST /institutions` creates it, and `PATCH /institutions/{institutionId}` replaces the credentials. A replacement does not revoke the previous secret at its issuer. The Lerian STA credentials are service-wide: `STA_CLIENT_ID` and `STA_CLIENT_SECRET`. * **Credentials key.** `credential-kek:rotate` rotates the key that wraps the stored credentials. No credential value changes. * **Key-encryption key (KEK).** `kek:rotate` rotates the institution's KEK. With Vault as the key provider, 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. The re-wrap job (`KEK_REWRAP_BACKFILL_ENABLED`) advances them to the new version. * **Tokenization keyset.** `keyset:rotate` adds a fresh primary key to the institution's blind-index keyset. The re-hash job (`REHASH_BACKFILL_ENABLED`) moves existing hashes to the new key. A rotation returns `SBJ-0007` / **409** when another rotation is already in progress. A rotation that commits but cannot be audited returns `SBJ-0002` / **500**. The key has already advanced, so this is **not retryable**. Retrying rotates a second time and widens the audit gap. Escalate and reconcile the audit trail instead. ## Data protection *** * **Envelope encryption.** Each record carries its own data key, sealed under the institution's KEK with **AES-256-GCM**. Additional authenticated data binds each ciphertext to its institution, table, record, and field, 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. Lerian SISBAJUD encrypts free text and does not tokenize it. It does not tokenize monetary values, and it stores the order tables' monetary values as plaintext, not ciphertext. * **Audit trail.** Lerian SISBAJUD appends audit events to a gap-free, append-only log. A per-event authentication code binds each entry to its position. `GET /admin/audit/verify` re-verifies a range of entries without decrypting any payload. * **LGPD.** A subject-access request **exports** the subject's judicial orders and the metadata of the files behind them. **Crypto-erasure** honours an erasure request. It destroys the data key of each matching record, so its ciphertext can no longer be decrypted, and it clears the amounts. The row and an audit record of the erasure remain. ## Contingency *** Lerian SISBAJUD moves a failed order to **FAILED** rather than leave it in processing. It does not retry a failed order on its own. An operator can **reprocess** it, which returns it to pending. 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 that is already stored. 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** * read a subject's summary across the institution's Midaz organizations * generate, reconsolidate, or resolve the transmission of a response file * acknowledge a Lerian STA dead-letter event * configure the institution, including its connector credentials, and **rotate** its keys Turn plugin authentication on outside `local` and `development`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.