Ventanas de liquidación
SILOC liquida sobre una base diferida neta multilateral, en días hábiles. Nuclea define las ventanas diarias de liquidación para los productos de boleto y de tarjetas. Lerian SILOC registra y aplica los mensajes de orden de transferencia que abren, avanzan, reconcilian y cierran el estado de su ciclo; no calcula la posición monetaria neta.
Certificados regulados
Registras los certificados del gateway como un certificado público más una referencia de custodia externa. El servicio no conserva clave privada alguna. Cuando registras un certificado, el servicio analiza su sujeto, serie y ventana de validez. Revocas el certificado por la API cuando lo retiras. Un estado de credencial deshabilitada detiene el gateway. Un certificado deshabilitado o revocado fail-closes la conexión en lugar de correr con credenciales inválidas.
Contingencia y recuperación
La ruta de ingestión SFN tiene resultados definidos bajo falla; no promete que cada frame se conserve ni que cada operación tenga un único efecto de extremo a extremo:
- La ingestión SFN es optativa.
SFN_INGEST_ENABLEDtiene el valor predeterminadofalse; habilítala explícitamente antes de que se inicie el consumidor. - Un envelope que no se puede decodificar, un mensaje decodificado sin
BCMSG.NUOpno vacío o unCodMsgno compatible —incluidoPAG0101— no sigue el despacho normal. Una falla no reintentable sigue la ruta de mensajes muertos y se confirma para que la partición pueda avanzar. - Una falla de despacho reintentable queda sin confirmar. Con commits de fuente seguros por offset, se vuelve a leer después de un reinicio desde el último offset confirmado; una falla transitoria persistente puede bloquear su partición hasta el reinicio.
- La entrega y el despacho son al-menos-una-vez. Para un mensaje decodificado y compatible, el servicio consulta la deduplicación durable mediante (
BCMSG.NUOp,CodMsg) antes de despachar y escribe el registro de mensaje procesado solo después de que el despacho tenga éxito. No es deduplicación solo por id de mensaje ni una garantía incondicional de exactamente una vez de extremo a extremo.
Reconciliación
La reconciliación se ejecuta en varios granos para que el estado de la conexión nunca se desvíe:
- Ledger de deduplicación de mensajes procesados. Para mensajes decodificados y compatibles con NUOp no vacío, el ledger usa la clave compuesta (
BCMSG.NUOp,CodMsg) y la registra solo después de un despacho exitoso. Los mensajes no decodificados o no compatibles no reciben un registro de mensaje procesado. - Feed de auditoría del procesamiento de mensajes. El feed de auditoría lista mensajes SFN compatibles que el servicio despachó.
- Estado por participante e historial de estado. Cada participante lleva su estado operativo. El servicio conserva cada cambio de estado como una entrada de historial de eventos de estado.
Monitoreo, alertas y auditoría
Lerian SILOC expone una superficie de operador para observar ciclos de liquidación OT, salud de la conexión y del relay, y estado de los participantes. Las superficies de ciclo y reconciliación informan estado registrado y conjuntos de reconciliación; no calculan cifras agregadas de posición en lectura.
- Ciclos de liquidación OT.
GET /api/v1/siloc/cyclesyGET /api/v1/siloc/cycles/{cycleId}listan e inspeccionan ciclos.GET /api/v1/siloc/cycles/{cycleId}/reconciliationdevuelve el resultado de la reconciliación, yGET /api/v1/siloc/cycles/{cycleId}/recalculationsdevuelve la cadena de rondas de recálculo del ciclo, incluyendo el cierre de la ventana de complemento/depósito de cada ronda. - Instrucciones de liquidación.
GET /api/v1/siloc/settlement-instructionsyGET /api/v1/siloc/settlement-instructions/{instructionId}devuelven las obligaciones de cada ciclo.POST /api/v1/siloc/rocsingiere una revisión semántica de ROC que supersede los valores previos del ciclo. - Alertas operacionales.
GET /api/v1/siloc/alertsdevuelve un feed activo por defecto, paginado por keyset. Los tipos de alerta incluyenWINDOW_CLOSING(un plazo de depósito/complemento se aproxima),RECALCULATION(un ciclo está en una ronda de recálculo),RELAY_DOWN,CONNECTION_DOWN,CERTIFICATE_EXPIRYySCHEDULE_CHANGE(un operador registró un anuncio de agenda por contingencia). Las alertas se limpian de forma atómica cuando la condición subyacente se resuelve —por ejemplo, un ciclo que liquida limpia su alertaRECALCULATIONen el camino de liquidación. PaseactiveOnly=falsepara incluir alertas desactivadas como historial. - Trilla de auditoría.
GET /api/v1/siloc/audit-recordsdevuelve una lectura literal y paginada de la trilla de auditoría —por ejemplo, para exportar el registro de una acción de operador o de un cambio de estado de participante. Los límitesfromytoson instantes RFC3339 (los valores de solo fecha se rechazan).
Agenda y contingencia
La cuadrícula de ciclos OT y el calendario de días hábiles son artefactos compilados en el servicio —la API los proyecta de forma literal; nunca parsea un cable de agenda de Núclea.
- Calendario y ventanas.
GET /api/v1/siloc/schedule/calendardevuelve el calendario de días hábiles, yGET /api/v1/siloc/schedule/windowsdevuelve la grilla canónica de ventanas OT ya compilada —un artefacto estático, no una lectura por día, que se sirve incluso con el datastore caído. - Cambios de agenda por contingencia.
POST /api/v1/siloc/schedule/changesregistra un anuncio de contingencia que el operador recibió por fuera del canal, de parte de Núclea. El cuerpo llevareason(≤500 caracteres),origin—el canal que anunció o la referencia de origen (≤256 caracteres)—,effectiveAt, el instante RFC 3339 anunciado en que el cambio entra en vigor, y unwindowSeqopcional que nombra la ventana canónica afectada. El registro es solo-agregar: un anuncio posterior nunca reescribe uno anterior. El anuncio más nuevo sí se convierte en la única alertaSCHEDULE_CHANGEactiva —registrar uno limpia la alerta previa y levanta una nueva cuyo plazo eseffectiveAtliteral.GET /api/v1/siloc/schedule/changesdevuelve los cambios registrados, del más nuevo al más antiguo.