Skip to main content
SILOC liquida sobre una base de neto diferido, por día hábil. Con su conexión MQ de SILOC configurada, el servicio mantiene abierta la conexión de gateway y envía sus mensajes admitidos. No mantiene ninguna posición contable.

​
Ventanas de liquidación

SILOC liquida sobre una base neta multilateral diferida, en días hábiles. Nuclea define las ventanas de liquidación diarias para los productos de boleto y tarjetas. Lerian SILOC registra y aplica los mensajes de orden de transferencia que abren, avanzan, concilian y cierran el estado de su ciclo. No calcula la posición neta monetaria.

​
Certificados regulados

Registras los certificados del gateway como un certificado público más una referencia de custodia externa. El servicio no mantiene ninguna clave privada. Cuando registras un certificado, el servicio analiza su asunto, número de serie y ventana de validez. Revocas el certificado a través de la API cuando lo retiras. Un estado de credencial deshabilitada detiene el gateway. Un certificado deshabilitado o revocado falla de forma cerrada la conexión en lugar de seguir funcionando con credenciales inválidas.

​
Contingencia y recuperación

La ruta de ingesta de SFN tiene resultados definidos ante fallos. No promete retener cada frame. Tampoco promete que cada operación tenga un único efecto de extremo a extremo:
  • El procesamiento entrante de SFN empieza cuando configuras el descriptor de conexión MQ de SILOC completo. Sin un disparador de conexión, el servicio arranca sin conectividad SILOC en vivo. Establecer MQ_HOST, MQ_CHANNEL, MQ_QUEUE_MANAGER, MQ_SEND_QUEUE o MQ_RECEIVE_QUEUE activa la validación del descriptor completo en el arranque. Proporcionar solo una parte del descriptor falla de forma cerrada e impide que el servicio arranque.
  • Un envelope indecodificable, un mensaje decodificado sin un BCMSG.NUOp no vacío, o un par (CodProdt, CodMsg) no admitido falla de forma cerrada hacia una excepción operativa. El servicio admite PAG0101 para OT y SLC: difiere el estado del participante. El servicio no admite LDL0020 ni LDL0006, y nunca los retransmite como financiamiento de liquidación.
  • Un fallo de envío reintentable permanece sin confirmar. Con confirmaciones de fuente seguras por offset, el servicio vuelve a leerlo después de un reinicio, desde el último offset confirmado. Un fallo transitorio persistente puede detener su partición hasta el reinicio.
  • La retransmisión a SLC es al menos una vez. Para un frame de financiamiento de SLC decodificado correctamente, el servicio verifica la desduplicación duradera mediante BCMSG.NUOp antes de retransmitir y escribe el registro de mensaje procesado solo después de que la retransmisión tenga éxito. Esto no es una desduplicación basada únicamente en el ID de mensaje, ni una garantía incondicional de exactamente una vez de extremo a extremo.

​
Conciliación

La conciliación se ejecuta en varias granularidades para que el estado de la conexión nunca se desvíe:
  • Ledger de desduplicación de mensajes procesados. Para los frames de financiamiento de SLC decodificados correctamente con un NUOp no vacío, el ledger usa BCMSG.NUOp y lo registra solo después de una retransmisión exitosa. Los mensajes no decodificados y no admitidos no reciben un registro de mensaje procesado.
  • Feed de auditoría de procesamiento de mensajes. El feed de auditoría enumera los mensajes de SFN admitidos que el servicio envió.
  • Estado por participante e historial de estados. Cada participante lleva su estado operativo. El servicio conserva cada cambio de estado como una entrada del historial de eventos de estado.

​
Monitoreo, alertas y auditoría

Lerian SILOC expone una superficie de operador para observar los ciclos de liquidación de OT, la salud de la conexión y la retransmisión, y el estado de los participantes. Las superficies de ciclo y conciliación reportan el estado registrado y los conjuntos de conciliación. No calculan cifras de posición agregadas al leer.
  • Ciclos de liquidación de OT. GET /api/v1/siloc/cycles y GET /api/v1/siloc/cycles/{cycleId} enumeran e inspeccionan los ciclos. GET /api/v1/siloc/cycles/{cycleId}/reconciliation devuelve el resultado de la conciliación, y GET /api/v1/siloc/cycles/{cycleId}/recalculations devuelve la cadena de rondas de recálculo del ciclo, incluido el cierre de la ventana de complemento/depósito de cada ronda.
  • Instrucciones de liquidación. GET /api/v1/siloc/settlement-instructions y GET /api/v1/siloc/settlement-instructions/{instructionId} devuelven las patas de obligación de cada ciclo. POST /api/v1/siloc/rocs ingiere una revisión semántica de ROC que reemplaza los valores anteriores del ciclo.
  • Alertas operativas. GET /api/v1/siloc/alerts devuelve un feed paginado por keyset que incluye solo las alertas activas. Los tipos de alerta incluyen WINDOW_CLOSING (se acerca un plazo de depósito/complemento), RECALCULATION (un ciclo está en una ronda de recálculo), RELAY_DOWN, CONNECTION_DOWN, CERTIFICATE_EXPIRY y SCHEDULE_CHANGE (un operador registró un anuncio de cambio de cronograma de contingencia). Las alertas se limpian de forma atómica cuando se resuelve la condición subyacente. Por ejemplo, un ciclo que liquida limpia su alerta RECALCULATION en la ruta de liquidación. Pasa activeOnly=false para incluir las alertas desactivadas como historial.
  • Registro de auditoría. GET /api/v1/siloc/audit-records devuelve una lectura paginada y textual del registro de auditoría, por ejemplo para exportar el registro de una acción de operador o un cambio de estado de participante. Los límites from y to son instantes RFC3339 (los valores de solo fecha se rechazan).

​
Cronograma y contingencia

La cuadrícula del ciclo de OT y el calendario de días hábiles son artefactos compilados del servicio. La API los proyecta de forma textual y nunca analiza un wire de cronograma de Núclea.
  • Calendario y ventanas. GET /api/v1/siloc/schedule/calendar devuelve el calendario de días hábiles, y GET /api/v1/siloc/schedule/windows devuelve la cuadrícula canónica compilada de ventanas de OT. La cuadrícula es un artefacto estático, no una lectura por día, y el servicio la devuelve incluso cuando el almacén de datos está caído.
  • Cambios de cronograma por contingencia. POST /api/v1/siloc/schedule/changes registra un anuncio de contingencia que el operador recibió fuera de banda desde Núclea. El cuerpo lleva reason (≤500 caracteres), origin (el canal del anuncio o la referencia upstream, ≤256 caracteres), effectiveAt, el instante RFC 3339 anunciado en que el cambio entra en vigor, y un windowSeq opcional que nombra la ventana canónica afectada. El registro es de solo anexado: un anuncio posterior nunca reescribe uno anterior. El anuncio más reciente sí se convierte en la única alerta activa SCHEDULE_CHANGE. Registrar uno limpia la alerta anterior y genera una nueva cuyo plazo es effectiveAt de forma textual. GET /api/v1/siloc/schedule/changes devuelve los cambios registrados, del más reciente al más antiguo.
Registra un cambio de cronograma por contingencia: