> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Integrating with Lerian SILOC

> Integrating with Lerian SILOC: MQ-configured SFN processing, supported-message dispatch, participant CloudEvents, and API conventions.

Lerian SILOC is event-driven at its edges. With a configured SILOC MQ connection, it consumes supported SFN messages from Nuclea and emits participant facts onto the platform. It has **no client-facing webhook consumers**. Downstream systems subscribe to the streaming topics rather than receive callbacks.

## What it consumes

***

Inbound SFN processing starts when you configure the complete SILOC MQ connection descriptor. If no connection trigger is present, the service starts without live SILOC connectivity. Setting `MQ_HOST`, `MQ_CHANNEL`, `MQ_QUEUE_MANAGER`, `MQ_SEND_QUEUE`, or `MQ_RECEIVE_QUEUE` triggers validation of the complete descriptor at startup. Providing only part of the descriptor fails closed and prevents the service from starting. With the complete descriptor configured, Lerian SILOC decrypts and decodes inbound messages from the regulated envelope, then applies a closed **(`CodProdt`, `CodMsg`)** policy. For `OT` and `SLC`, it routes `PAG0102`, `LDL0021`, and `PAG0103`. `OT` frames defer durably while `SLC` frames relay to Lerian SLC. `PAG0101` defers participant status for either product. `LDL0020`, `LDL0006`, and every other pair fail closed to an operator exception.

## Ingestion and delivery semantics

***

* SLC relay is **at-least-once**. For a successfully decoded SLC funding frame with a nonblank `BCMSG.NUOp`, the durable deduplication key is **`BCMSG.NUOp`**, not a message ID alone.
* The service writes that processed-message record only after a successful relay. It creates no processed-message record for an undecoded or unsupported message. A failure before the record is written can result in another delivery, so this behavior is not an unconditional end-to-end exactly-once guarantee.

## What it emits

***

* **Participant facts.** Lerian SILOC publishes `siloc.participant.registered` and `siloc.participant.updated` as CloudEvents on the platform's streaming backbone. Downstream systems track the participant directory without polling.

## No Midaz touchpoint

***

Lerian SILOC has **no** direct ledger integration. It holds no accounting position and performs no monetary arithmetic. It routes bytes and emits facts. This rail does not book money. The settlement of the net position happens at SILOC and the STR. Any ledger posting lives with the service that owns the money movement.

## Money-path boundary

***

The separate STR rail, [Lerian SPB](/en/rails/spb/what-is-lerian-spb), executes the **STR deposit leg**, the monetary settlement at BACEN. SILOC does not. Lerian SILOC carries the SILOC messages and administers the connection. It never moves money.

## API conventions

***

* **Base path** is `/api/v1/siloc`, and errors follow the RFC 9457 problem-detail format.
* **Auth** follows the platform's standard bearer-token scheme.
* **Participant registration is idempotent** through an idempotency key, so a retried registration does not create a duplicate.
* **Certificates are references, not secrets.** A registered certificate carries a public certificate and an external custody reference. It stores or returns no private key.