Skip to main content
Lerian SILOC is event-driven at its edges. When enabled, 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

SFN ingestion is opt-in: SFN_INGEST_ENABLED defaults to false, so the consumer starts only when you explicitly enable it. When enabled, Lerian SILOC decrypts and decodes inbound messages from the regulated envelope and accepts PAG0102, LDL0021, LDL0020/LDL0020R2, LDL0006/LDL0006R2, and PAG0103. It does not route PAG0101.

​
Ingestion and delivery semantics

  • Delivery and dispatch are at-least-once. For a successfully decoded, supported message with a nonblank BCMSG.NUOp, the durable deduplication key is (BCMSG.NUOp, CodMsg), not a message ID alone.
  • The service writes that processed-message record only after a successful dispatch. 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 — siloc.participant.registered and siloc.participant.updated — published 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, 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.