Skip to main content
Lerian SISBAJUD es event-first en su punto de contacto con el ledger. Consume eventos de cambio de saldo de Midaz para impulsar los bloqueos permanentes. Emite eventos operativos de negocio que otros sistemas pueden observar. No envía webhooks salientes a consumidores de terceros. Sus interfaces son el ledger de Midaz, Lerian STA, el endpoint de notificación de entrega de remesas y su superficie administrativa.

​
Eventos del ledger que consume

La integración se suscribe a los eventos de cambio de saldo de Midaz. Trata cada evento como un disparador. Un evento no decide nada por sí mismo. La integración compara la cuenta del evento con las cuentas de las que retiraron montos los bloqueos anteriores. Luego ejecuta la lógica de bloqueo para las órdenes abiertas del titular de esa cuenta. Un bloqueo permanente usa esta ruta para capturar fondos que llegan después del primer intento. Después de un bloqueo tradicional inicial parcial, un crédito posterior ese mismo día también puede activar intentos complementarios.

​
Eventos de negocio que emite

Lerian SISBAJUD emite eventos operativos de negocio sin datos personales en sus payloads:
  • Un evento block-account-created cuando una ejecución crea una retención de bloqueo. Es una señal operativa, no un portador de dinero ni de PII.
  • Un evento key-rotated (kek.rotated) cuando un operador rota la clave de cifrado de claves de una institución con Vault como proveedor de claves.
Estos eventos sirven para la observabilidad y la coordinación. Los movimientos de dinero residen en el ledger de Midaz, no en los payloads de los eventos.

​
Límite con Midaz

Midaz es el conector del ledger. A través de él, Lerian SISBAJUD:
  • envía operaciones de bloqueo y desbloqueo para las cuentas de cliente relevantes y las retenciones de bloqueo
  • crea y archiva retenciones de bloqueo según las necesita una ejecución
  • descifra el CPF/CNPJ para consultar en el CRM las cuentas del demandado. No resuelve una cuenta únicamente por token
  • lee el saldo disponible de una cuenta monitoreada
  • concilia las órdenes en monitoreo contra instantáneas de saldo del ledger

​
Semántica de entrega

  • Escrituras de bloqueo deduplicadas. El servicio deduplica las escrituras de bloqueo por institución y código de bloqueo en su propio almacén antes de llamar al ledger.
  • Eventos al menos una vez. En operación normal de la caché, Lerian SISBAJUD suprime los identificadores de evento duplicados. Si la caché no está disponible, la deduplicación falla en modo fail-open y el evento continúa.
  • Ámbito de tenant. Los eventos de cambio de saldo consumidos contienen la identidad de la institución. La integración correlaciona cada cambio de saldo solo con las órdenes de la misma institución.
  • Sin webhooks salientes a terceros. Lerian SISBAJUD no envía datos a consumidores de webhooks de terceros. También expone un endpoint operativo de notificación de entrega de remesas. Ese endpoint no es una API de ingreso de órdenes.

​
Transporte de archivos

Los archivos judiciales entran y salen a través del canal de intercambio de archivos de BACEN. Lerian STA documenta esta integración de propiedad del cliente. Lerian SISBAJUD es un producto fuente de ese transporte:
  • Entrada. Con STA_CONSUMER_ENABLED activado, el servicio consume los eventos de archivo que publica Lerian STA. Cada evento indica el objeto almacenado y su digest SHA-256. El servicio lee el objeto y verifica el digest antes de analizar el archivo. POST /remittance-files/notifications también recibe y analiza un objeto que ya está almacenado.
  • Salida. Con STA_TRANSFERS_ENABLED activado, el servicio envía cada archivo de respuesta a través de Lerian STA. Cuando está desactivado, el servicio genera los archivos de respuesta, pero no los envía.
  • Dead letter. El consumidor envía a un tópico de dead letter un evento que un reintento no puede corregir. Confirmar un evento no lo elimina. El tópico conserva los eventos durante su período de retención. POST /admin/sta-dlq/{eventId}/acknowledge deja constancia en el registro de auditoría de cómo un operador trató un evento en dead letter.