Skip to main content
SILOC settles on a deferred-net, business-day basis, and Lerian SILOC works within that one operational reality. The service keeps the gateway connection open and, when SFN ingestion is enabled, dispatches its supported messages. It holds no accounting position.

Settlement windows


SILOC settles on a deferred multilateral net basis, on business days. Nuclea defines the daily settlement windows for boleto and card products. Lerian SILOC records and applies the transfer-order messages that open, advance, reconcile, and close its cycle state; it does not calculate the monetary net position.

Regulated certificates


You register the gateway’s certificates as a public certificate plus an external custody reference. The service holds no private key. When you register a certificate, the service parses its subject, serial, and validity window. You revoke the certificate over the API when you retire it. A credential-disabled state halts the gateway. A disabled or revoked certificate fail-closes the connection instead of running on invalid credentials.

Contingency and recovery


The SFN ingestion path has defined outcomes under failure; it does not promise that every frame is retained or that every operation has a single end-to-end effect:
  • SFN ingestion is opt-in. SFN_INGEST_ENABLED defaults to false; enable it explicitly before the consumer starts.
  • An undecodable envelope, a decoded message without a nonblank BCMSG.NUOp, or an unsupported (CodProdt, CodMsg) pair fails closed to an operator exception. PAG0101 is supported for OT and SLC: it defers participant status. LDL0020 and LDL0006 are unsupported and are never relayed as settlement funding.
  • A retryable dispatch failure remains unacknowledged. With offset-safe source commits, it is read again after a restart from the last committed offset; a persistent transient failure can stall its partition until restart.
  • SLC relay is at-least-once. For a successfully decoded SLC funding frame, the service checks durable deduplication by BCMSG.NUOp before relay and writes the processed-message record only after relay succeeds. This is not message-ID-only deduplication and is not an unconditional end-to-end exactly-once guarantee.

Reconciliation


Reconciliation runs at several grains so the connection’s state never drifts:
  • Processed-message dedup ledger. For successfully decoded SLC funding frames with a nonblank NUOp, the ledger uses BCMSG.NUOp and records it only after a successful relay. Undecoded and unsupported messages do not receive a processed-message record.
  • Message-processing audit feed. The audit feed lists supported SFN messages that the service dispatched.
  • Per-participant status and status history. Each participant carries its operational status. The service keeps every status change as a status-event history entry.

Monitoring, alerts, and audit


Lerian SILOC exposes an operator surface for watching OT settlement cycles, connection and relay health, and participant status. The cycle and reconciliation surfaces report recorded state and reconciliation sets; they do not calculate aggregate position figures on read.

Schedule and contingency


The OT cycle grid and business-day calendar are compiled artifacts on the service — the API projects them verbatim; it never parses a Núclea schedule wire.
  • Calendar and windows. GET /api/v1/siloc/schedule/calendar returns the business-day calendar, and GET /api/v1/siloc/schedule/windows returns the compiled canonical OT window grid — a static artifact, not a per-day read, served even when the datastore is down.
  • Contingency schedule changes. POST /api/v1/siloc/schedule/changes records a contingency announcement the operator received out of band from Núclea. The body carries reason (≤500 chars), origin — the announcing channel or upstream reference (≤256 chars) — effectiveAt, the announced RFC 3339 instant the change takes effect, and an optional windowSeq naming the affected canonical window. The record is append-only: a later announcement never rewrites an earlier one. The newest announcement does become the single active SCHEDULE_CHANGE alert — recording one clears the prior alert and raises a new one whose deadline is effectiveAt verbatim. GET /api/v1/siloc/schedule/changes returns the recorded changes, newest first.
Record a contingency schedule change: