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, 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. Activa la lógica de bloqueo permanente para reevaluar una cuenta monitoreada e intentar el bloqueo pendiente. Una reiteração 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. Cada evento contiene la identidad del tenant. La integración correlaciona cada cambio de saldo solo con las órdenes de la misma institución. El aislamiento por institución se mantiene a través del límite del evento.

​
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 cuando una institución rota su clave maestra de cifrado.
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 solo para la consulta del CRM y nunca lo registra en logs. 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
El código de bloqueo downstream hace que las escrituras de bloqueo sean idempotentes. Un bloqueo reintentado no se contabiliza dos veces.

​
Semántica de entrega

  • Escrituras de bloqueo idempotentes. El código de bloqueo downstream aplica una clave a cada escritura de bloqueo. Una repetición no se contabiliza dos veces.
  • 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. La idempotencia del código de bloqueo downstream es el respaldo contra la aplicación duplicada de bloqueos.
  • Ámbito de tenant. Los eventos de cambio de saldo consumidos contienen la identidad de la institución. En despliegues multi-tenant, los eventos emitidos también la contienen. En despliegues single-tenant, un evento block-account-created puede omitir la extensión ce-tenantid de CloudEvents cuando el contexto de runtime está vacío.
  • 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 consumidor de producto fuente de ese transporte. Lerian STA entrega el objeto de remesa entrante y su comprobante de integridad. Luego, POST /remittance-files/notifications recibe y analiza de forma síncrona el objeto ya entregado. Lerian SISBAJUD ejecuta la orden y devuelve los archivos de resultado.