Saltar al contenido principal
Lerian SLC opera bajo dos restricciones del SLC de Núclea: ventanas de liquidación diarias rígidas y credenciales reguladas de ICP-Brasil. El riel hace cumplir las ventanas, firma a través de un backend de custodia y da a los operadores endpoints para recuperar y conciliar operaciones.

Catálogo de participantes


Lerian SLC mantiene un catálogo de los participantes con los que trabaja el tenant. La prueba de conectividad y la lectura del estado operativo devuelven 404 para un participante fuera del catálogo. Lerian SLC omite una posición de compensación de un participante fuera del catálogo.
  • Participantes. POST /v1/participants registra un participante. Su tipo es ACQUIRER, SUBCREDITOR, DOMICILE_IF, SETTLEMENT_IF o BRAND.
  • Esquemas. POST /v1/participants/{id}/arrangements registra un código de marca de tarjetas bajo el que opera el participante. También registra el rol del participante en esa marca: ACQUIRER, ISSUER, BRAND, DOMICILE_IF o SETTLEMENT_IF. Un segundo esquema con el mismo código y rol devuelve 409.
  • Prueba de conectividad. POST /v1/participants/{participantIspb}/test-connectivity envía una sonda de conectividad a Núclea por el canal REST. La ruta recibe el ISPB del participante, no su ID. La sonda es AGEN001 para un participante DOMICILE_IF y AGEN999 para los demás tipos. La respuesta informa si Núclea devolvió intacto el eco de la sonda, y la latencia de ida y vuelta.

Ventanas de liquidación y grade horária


El SLC de Núclea liquida en ventanas diarias rígidas que fija su grade horária. Lerian SLC evalúa cada ventana como OPEN, PRE_CUTOFF o CLOSED, y condiciona el despacho al resultado. El riel mantiene en espera una operación QUEUED fuera de su ventana y la despacha cuando la ventana se abre. Esto evita el rechazo de Núclea por estar fuera de ventana (ESLC0029). Lerian SLC emite schedule.cutoff_approaching a medida que una ventana se acerca a su hora de corte, 30 minutos antes de forma predeterminada. Usa GET /v1/schedule para leer las ventanas y la ventana de despacho de crédito que el riel hace cumplir.
  • Encolar y retransmitir. Una operación permanece en CREATED hasta que un operador la reencole en la cola de despacho. Una retransmisión vuelve a enviar una operación QUEUED.
El riel también mantiene en espera el despacho y el reenvío de una operación mientras el último estado PAG0101 de su acreedor es SUSPENDED o SPECIAL_REGIME. Usa GET /v1/participants/{id}/operational-status para leer ese estado y si se aplica la espera.

Certificados y custodia


Lerian SLC delega la firma a un backend de custodia: una clave de software, un PKCS#11 HSM o AWS KMS. La credencial de firma es un certificado ICP-Brasil con una clave RSA de al menos 2048 bits.
  • Los despliegues SaaS fijan la custodia en AWS KMS. El riel importa el material de clave envuelto del cliente y nunca recibe la clave privada de firma en texto claro.
  • Vigencia. Lerian SLC se niega a firmar con un certificado fuera de su período de vigencia.
  • Rotación. Lerian SLC lee el certificado de firma activo en cada firma, así que una rotación surte efecto en la siguiente. El certificado de cliente mTLS se carga al arrancar, así que su rotación requiere un reinicio.
  • Las alertas de vencimiento se escalan a los 30, 15, 7 y 1 día antes del vencimiento, como eventos certificate.expiring, cuando SCHEDULE_CERT_EXPIRY_ENABLED es true.

Contingencia y recuperación


  • Colas dead-letter. El riel retiene un mensaje entrante de la RSFN o de Lerian SILOC que no puede procesar. Un mensaje retenido permanece en la cola durante 30 días. GET /admin/dlq/{queue} lista los mensajes retenidos, y una reejecución reprocesa uno. Una reejecución de un mensaje ya procesado no cambia nada.
  • Drenajes de recuperación. Los endpoints de despacho, reenvío, nuevo sondeo, retransmisión de estado y reprocesamiento vuelven a ejecutar el trabajo saliente y de retornos del propio riel sin esperar el próximo tick.
  • Reintento. Un reintento vuelve a enviar una operación REJECTED como una nueva operación vinculada a la original. Una operación que la IF Domicílio rechazó en D+1, después de liquidarse, no admite reintento.
  • Operaciones retenidas. Cuando rechazos consecutivos de la contraparte agotan el presupuesto de intentos de transmisión de una operación saliente, el riel retiene la operación y emite una alerta en lugar de reintentar indefinidamente. El endpoint de liberación la devuelve al backlog elegible, para que el próximo tick vuelva a impulsarla. Reinicia el contador de intentos, de modo que una operación recuperada recibe un presupuesto completo. Sin una corrección de la causa, vuelve a quedar retenida después de que se agote ese presupuesto.
  • Repasses de cancelación. Cuando el riel no puede determinar si una retransmisión de cancelación a la credenciadora llegó a Núclea, mantiene bloqueada la retransmisión. Después de que establezcas el resultado, el endpoint de resolución lo registra: CONFIRMED mantiene bloqueada la retransmisión, y ABANDONED permite retransmitirla de nuevo.
  • Depósitos fallidos. GET /v1/funding/acks?result=FAILED lista los depósitos que la institución informó como fallidos.

Conciliación


  • Por operación. El riel rastrea cada operación por su NUliquid. Una consulta por NUliquid lee el registro local. Si ese registro no existe, la consulta pregunta a Núclea. Esto requiere el ISPB del participante y un NUliquid de 30 días como máximo.
  • Contra Núclea. El endpoint de conciliación pide a Núclea el estado de liquidación de una operación (SLC0908) y registra la respuesta. Solo mueve una operación de FORWARDED a CONFIRMED, y requiere un motivo.
  • Por ciclo de compensación. El riel rastrea la posición de compensación por ciclo y reporta una divergencia bilateral. Marca una confirmación D+1 que también reporta una divergencia en el valor liquidado.