Skip to main content
Lerian SILOC exposes typed operations over the /api/v1/siloc surface. Over one connection to Nuclea, it receives SILOC messages and routes each one, and it sends the institution’s own requests. The service also keeps the participant, certificate, and coverage records that support this work.

​
Gateway connection lifecycle

A complete SILOC MQ connection descriptor activates inbound SFN processing. The service then opens and maintains one messaging-gateway connection to Nuclea’s SILOC over the national financial-system network. Four guards protect the connection:
  • a circuit breaker that trips on repeated failure,
  • automatic reconnect with a capped backoff,
  • a credential-disabled stop that halts the gateway after a certificate revocation, and
  • a readiness probe that reports the gateway’s connection and health.
Without the descriptor, the service starts with no live SILOC connectivity, and a partial descriptor prevents the service from starting. See Environment variables. With the complete descriptor configured, the service decrypts and decodes inbound messages from the regulated envelope before it routes them.

​
Inbound SFN dispatch

After decoding, the ingress selects a route from a closed (CodProdt, CodMsg) policy: The SLC relay acts on arrival. The service parks every other routed message and applies it later: PAG0101 when STATUS_REPLAY_ENABLED=true, and the rest when OT_REPLAY_ENABLED=true. LDL0020, LDL0006, and every other product/code pair fail closed to an operator exception, and the service never relays them as settlement funding. An undecodable envelope or a message with a blank BCMSG.NUOp follows the same fail-closed path.

​
At-least-once dispatch with durable deduplication

The source can redeliver a message, so the SLC relay is at-least-once. For a successfully decoded SLC funding frame with a nonblank BCMSG.NUOp, the service checks durable deduplication by BCMSG.NUOp before relay. The policy treats that operation number as globally unique. The service does not use a message-ID-only key. The service writes the processed-message record only after a successful relay and before it acknowledges the source. It creates no such record for an undecoded or unsupported message. A failure before the service writes that record can leave the message eligible for another delivery. Do not treat this behavior as an unconditional end-to-end exactly-once guarantee.

​
Failure outcomes

  • A retryable failure, such as a datastore outage, returns the frame to the receive queue, and the service receives it again after MQ_BACKOUT_DELAY. A frame refused more than MQ_BACKOUT_THRESHOLD times moves to MQ_BACKOUT_QUEUE. The service records it for an operator and raises INBOUND_QUARANTINED.
  • A non-retryable failure, such as a malformed envelope or an unsupported (CodProdt, CodMsg) pair, fails closed to a durable operator exception. The service acknowledges the message only after that exception record commits.
  • When the relay to Lerian SLC is down, the service parks the funding frame as a relay failure and raises RELAY_DOWN. An operator replays it after the relay recovers.
  • Before it applies a parked message, the service validates it against the official XSD. The service never applies a message that the schema refuses, and it raises INBOUND_SEMANTIC_REJECTED. While the validator gives no answer, the message waits and the service raises XSD_VALIDATOR_DOWN.
  • The processed-message record protects only the successfully decoded and supported messages described above. It does not promise retention of every frame or exactly-once effects across every downstream system.

​
Ingestion observability

  • List relayed messages: the audit feed of the funding messages that the service relayed to Lerian SLC.
  • Read relay status: the relay’s health (HEALTHY, DEGRADED, or DOWN), whether card settlement is blocked, and the last-relayed timestamp.

​
Outbound requests

The service sends the institution’s own requests to Nuclea: transfers, collateral movements, queries, confirmations, and participant status changes. A submit answers 202 with the control number that Nuclea echoes, and the answer arrives later on the inbound path. Each request moves from SUBMITTED (stored) to DISPATCHED (accepted by the queue manager). It then moves to ANSWERED, REFUSED (returned by Nuclea with an error), or FAILED (the service cannot deliver it as stored). A request still DISPATCHED after its answer deadline raises UNANSWERED_REQUEST.

​
Participant directory

Lerian SILOC keeps a directory of the SILOC participants it settles for. You register, list, get, and update a participant, and read a participant’s status. Each participant carries its ISPB and its role. The service keeps a participant’s operational status per product, and the câmara’s PAG0101 messages set it. Registering or updating a participant, or a change to its status, emits a participant fact. Registration writes are idempotent through the X-Idempotency header, so a retried registration does not create a duplicate. The operational status uses SILOC’s seven-value status domain:

​
Regulated certificates

The service holds the connection’s regulated certificates as references, not as secrets. You register a public certificate together with an external custody reference. The service parses the certificate for its subject, serial, and validity window, and stores no private key. You then list, get, and revoke certificates over the same surface.

​
Capability coverage

A read-only capability listing describes the settlement-coverage capabilities as a transparency surface. For each message type, it reports the direction, the implementation state, and the disposition.