Skip to main content
Lerian SLC runs against two constraints of Núclea’s SLC: rigid daily settlement windows, and regulated ICP-Brasil credentials. The rail enforces the windows, signs through a custody backend, and gives operators endpoints to recover and reconcile operations.

​
Participant catalog

Lerian SLC keeps a catalog of the participants that the tenant works with. The connectivity test and the operational-status read return 404 for a participant outside the catalog. Lerian SLC skips a clearing position for a participant outside the catalog.
  • Participants. POST /v1/participants registers a participant. Its type is ACQUIRER, SUBCREDITOR, DOMICILE_IF, SETTLEMENT_IF, or BRAND.
  • Arrangements. POST /v1/participants/{id}/arrangements registers a card-scheme code that the participant operates under. It also records the participant’s role in that scheme: ACQUIRER, ISSUER, BRAND, DOMICILE_IF, or SETTLEMENT_IF. A second arrangement with the same code and role returns 409.
  • Connectivity test. POST /v1/participants/{participantIspb}/test-connectivity sends a connectivity probe to Núclea over the REST channel. The path takes the participant’s ISPB, not its ID. The probe is AGEN001 for a DOMICILE_IF participant and AGEN999 for the other types. The response reports whether Núclea echoed the probe intact, and the round-trip latency.

​
Settlement windows and grade horária

Núclea’s SLC settles on rigid daily windows set by its grade horária. Lerian SLC evaluates each window as OPEN, PRE_CUTOFF, or CLOSED, and gates dispatch on the result. The rail holds a QUEUED operation outside its window and dispatches it when the window opens. This avoids Núclea’s out-of-window rejection (ESLC0029). Lerian SLC emits schedule.cutoff_approaching as a window approaches its cutoff, 30 minutes ahead by default. Use GET /v1/schedule to read the windows and the credit dispatch window that the rail enforces.
  • Queue and retransmit. An operation stays CREATED until an operator requeues it into the dispatch queue. A retransmit resubmits one QUEUED operation.
The rail also holds the dispatch and forward of an operation while the latest PAG0101 status of its creditor is SUSPENDED or SPECIAL_REGIME. Use GET /v1/participants/{id}/operational-status to read that status and whether the hold applies.

​
Certificates and custody

Lerian SLC delegates signing to a custody backend: a software key, a PKCS#11 HSM, or AWS KMS. The signing credential is an ICP-Brasil certificate with an RSA key of at least 2048 bits.
  • SaaS deployments lock custody to AWS KMS. The rail imports the client’s wrapped key material and never receives the signing private key in cleartext.
  • Validity. Lerian SLC refuses to sign with a certificate outside its validity window.
  • Rotation. Lerian SLC reads the active signing certificate on each signature, so a rotation takes effect on the next one. The mTLS client certificate loads at startup, so its rotation needs a restart.
  • Expiry alerts escalate at 30, 15, 7, and 1 day before expiry, as certificate.expiring events, when SCHEDULE_CERT_EXPIRY_ENABLED is true.

​
Contingency and recovery

  • Dead-letter queues. The rail parks an inbound RSFN or Lerian SILOC message that it cannot process. A parked message stays on the queue for 30 days. GET /admin/dlq/{queue} lists the parked messages, and a replay reprocesses one. A replay of a message already processed changes nothing.
  • Recovery drains. The dispatch, forward, repoll, status-relay, and reprocess endpoints re-run the rail’s own outbound and return work without waiting for the next tick.
  • Retry. A retry resubmits a REJECTED operation as a new operation linked to the original. An operation that the IF Domicílio refused on D+1, after it settled, is not retryable.
  • Parked operations. When consecutive counterpart refusals exhaust an outbound operation’s transmit-attempt budget, the rail parks the operation and alerts instead of retrying forever. The un-park endpoint returns it to the eligible backlog, so the next tick re-drives it. It resets the attempt counter, so a recovered operation receives a full budget. Without a fix for the cause, it parks again after that budget is exhausted.
  • Cancellation repasses. When the rail cannot determine whether a cancellation relay to the credenciadora reached Núclea, it keeps the relay blocked. After you establish the outcome, the resolve endpoint records it: CONFIRMED keeps the relay blocked, and ABANDONED makes it relayable again.
  • Failed deposits. GET /v1/funding/acks?result=FAILED lists the deposits that the client reported as failed.

​
Reconciliation

  • Per operation. The rail tracks each operation by its NUliquid. A lookup by NUliquid reads the local record. If that record does not exist, the lookup asks Núclea. This needs the participant’s ISPB and a NUliquid at most 30 days old.
  • Against Núclea. The reconcile endpoint asks Núclea for an operation’s settlement status (SLC0908) and records the answer. It moves an operation only from FORWARDED to CONFIRMED, and it requires a reason.
  • Per clearing cycle. The rail tracks the clearing position per cycle and reports a bilateral divergence. It flags a D+1 confirmation that also reports a divergence in the settled value.