Skip to main content
Lerian SLC runs one settlement pipeline for every card operation. It takes in the operation, submits it to Núclea, and correlates Núclea’s verdict and returns. A custody backend signs every submission. The NUliquid tracks the operation after Núclea accepts it.

Intake


Operations enter Lerian SLC through the operations API:
  • Single intake. One operation as JSON. The caller’s deduplication key is externalId. A second submission under an externalId already in use returns 409 Conflict. A retried submission therefore never settles twice.
  • Batch intake. NDJSON, one operation per line, up to 50,000 lines by default. Lerian SLC counts the lines and the bytes before it saves anything, so an over-limit batch answers 413 and saves nothing. A bad line is refused alone and does not stop the batch.
The file intake also accepts an artifact that the client already signed. Lerian SLC records its checksum and metadata for audit. It does not parse or transmit the artifact. You submit three operation types: CREDIT, DEBIT, and ANTICIPATION. A CANCELLATION follows its own rules, because it carries a regulatory reason category and the identifier of the operation it cancels. Lerian SLC refuses SWEEP at intake: it builds the sweep (varredura) summary files itself. You can also cancel an operation locally while it is CREATED or QUEUED, before Núclea receives it.

Submit, sign, transmit, correlate


Lerian SLC sends two kinds of traffic to Núclea:
  • Online submissions. Credit, debit, and anticipation go to Núclea as JSON submissions: SLC0914 for a credit, SLC0913 for a debit, and SLC0912 for an anticipation. Lerian SLC polls SLC0915 for Núclea’s verdict on each submission.
  • ASLC files. Cancellations, forwards to the IF Domicílio, status relays to the credenciadora, and the sweep summaries travel as ASLC files. Lerian SLC builds each file as UTF-16BE with no BOM and validates those final bytes against the message’s XSD before building the security envelope. It compresses the file with GZIP and wraps it in the SPB security envelope, which a custody backend signs (see Signing orchestration).
Lerian SLC correlates each return with the operation that produced it, by the key the counterparty echoes. A RET line uses the 20-position control number derived from the operation’s externalId, left-padded with zeros when shorter. An ASLC023 or D+1 line uses its NUliquid. A PRO at file level uses the control number of the transmitted file. A line whose key matches nothing is skipped as uncorrelated.

When one return contradicts itself

A single return file can state two different outcomes for the same reference. Lerian SLC resolves it by policy, whatever the order of the lines in the file:
  • one outcome: applied as stated.
  • the same outcome repeated: applied exactly once.
  • an acceptance and a refusal for the same reference: the refusal wins, and Lerian SLC logs and counts the displaced acceptance.
The result is the same whichever order the two lines arrive in. The file is never aborted: every other reference in it keeps processing, and the return is still acknowledged.

Message families


Settlement flows


  • Credit, debit, and anticipation. Lerian SLC submits the operation and reads Núclea’s verdict. After Núclea accepts it, Lerian SLC forwards the settlement notice to the IF Domicílio through Núclea. It reads the IF Domicílio’s answer and relays it to the credenciadora. The IF Domicílio’s D+1 result closes the lifecycle.
  • Cancellation. The credenciadora informs a cancellation (credit ASLC060, debit ASLC064). Lerian SLC forwards it to the IF Domicílio (ASLC061, ASLC065) and reads the answer (ASLC062, ASLC066). When the IF Domicílio confirms the cancellation, Lerian SLC emits cancellation.confirmed_by_domicile.

Clearing and funding for the IF Liquidante


For the settling institution, Lerian SLC consumes Núclea’s clearing messages over the RSFN: the preview and final clearing position (SLC0001) and the bilateral-movement divergence (SLC0002). The GEN0015 message reports a file available for pickup, and PAG0101 carries a participant’s operational status. From Lerian SILOC, it receives the cycle opening (PAG0102) and close (PAG0103) and the deposit value (LDL0021). Lerian SLC keeps the clearing position per settlement cycle. When a cycle closes, it compares each participant’s settlement instruction with the final position and marks the cycle reconciled when they agree. It raises a clearing.* event for each step.
  1. Lerian SLC relays the deposit value to the client as clearing.deposit_required.
  2. The client makes the deposit on its own STR connection. Lerian SLC does not send the deposit message.
  3. The client records the result with the deposit acknowledgement, SENT or FAILED. SENT acknowledges the settlement instruction. FAILED is recorded, leaves the instruction open, and raises funding.deposit_failed.
  4. A credit or debit operation moves from CONFIRMED to SETTLED when both confirmations exist: the client’s deposit acknowledgement and the close of Núclea’s cycle.
An anticipation settles outside the multilateral cycle. It moves from CONFIRMED to SETTLED on the IF Domicílio’s confirmation, with no deposit acknowledgement and no cycle close.

Gross settlement (LBTR)


From Lerian SILOC, Lerian SLC receives the gross settlement announcements: a settlement result (LTR0001), an operation between two of the institution’s own non-liquidantes (LTR0007), and the cancellation of a result (LTR0012). The institution answers through Lerian SILOC:
  • LTR0002 confirms or diverges from a result.
  • LTR0008 confirms or rejects a non-liquidante operation.
  • LTR0009 asks for the institution’s LBTR position.
A command moves from REQUESTED to ACCEPTED, then to ANSWERED, REFUSED, or FAILED. ACCEPTED means that Lerian SILOC queued the command. It does not mean that anything settled. Lerian SLC does not compute the LBTR position. The clearing house answers the position query. Lerian SLC delivers these commands to Lerian SILOC through the Lerian SLC streaming producer. While STREAMING_ENABLED is false, Lerian SLC does not deliver them.

Operation lifecycle


Each operation follows an eleven-state lifecycle. Núclea assigns its NUliquid when the operation is accepted.

Signing orchestration


Lerian SLC builds the unsigned payload and delegates signing to a custody backend. Each registered certificate names its backend. SaaS deployments lock custody to AWS KMS. Lerian SLC never receives the signing private key in cleartext: the client wraps its key material locally against an import token, and the service imports the wrapped material into a KMS key for that tenant and participant. The service stores the public certificate and a key reference.

Transport


Lerian SLC sends its online submissions and ASLC files to Núclea over REST, secured by mTLS and a per-request JWS signature. It polls and acknowledges Núclea’s returns over the same channel.
You set the outbound transport at runtime, and REST is the default. A tenant set to Connect:Direct fails closed with a typed transport error. It does not fall back to REST.