Skip to main content
Lerian SLC runs one settlement pipeline for every card operation. The pipeline takes in one operation and builds its ASLC file. The client’s custody signs the file. Lerian SLC transmits the file to Nuclea and correlates the returns. The NUliquid tracks the operation through its lifecycle.

​
Intake

Operations enter Lerian SLC through two canonical modes:
  • Canonical API — a REST/JSONL intake for operations in Lerian’s canonical shape. external_id is the caller’s deduplication key: a second submission under an external_id already in use is refused with 409 Conflict naming the existing operation, so a retried submission never settles twice.
  • Direct ASLC XML — an upload of ready ASLC XML for callers that already produce it.
An audited pass-through mode also accepts artifacts that the client already signed and forwards them under audit. You submit three operation types today: CREDIT, DEBIT, and ANTICIPATION. A CANCELLATION enters through its own path, because it carries a regulatory reason code and the identifier of the operation it cancels. SWEEP (varredura) is a canonical type Lerian SLC emits itself; it is not accepted at intake.

​
Build, sign, transmit, correlate

Each operation flows through one pipeline:
  1. Validate the operation against Nuclea’s XSDs.
  2. Build the ASLC file as UTF-16BE, no BOM, up to a configurable record ceiling that defaults to 50,000 records per file. The build splits the file automatically above that ceiling. Cancellation files are exempt: they are never split.
  3. Seal the file. First compress it with GZIP. Then build the SPB security envelope, which the client’s custody signs (see Signing orchestration below).
  4. Transmit the file to Nuclea over the channel configured for the tenant: Connect:Direct over the private RSFN network, or REST with mTLS. The REST channel adds a per-request JWS signature because it crosses the public internet; Connect:Direct does not need one, since the payload is already SPB-signed and the network is private.
  5. Correlate Nuclea’s returns back to the operations that produced them. Each return seam uses the key the counterparty echoes: a RET line by its 20-position control number — the zero-left-padded form of your external_id — an ASLC023 or D+1 line by its NUliquid, and a PRO at file level by the transmitted slice’s control number. A line whose key matches nothing is skipped as uncorrelated. The returns are the PRO / ERR / RET files and the ASLC028 status message.

​
When one return contradicts itself

A single return file can state two different outcomes for the same reference, and the XSDs cannot reject that shape. Lerian SLC resolves it by policy, not by the order the lines appear 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 the displaced acceptance is reported for reconciliation.
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 (acquirer). Operations enter through the canonical intake. Lerian SLC builds the credit file (ASLC027), then signs and transmits it. It correlates the ASLC028 status and the PRO/ERR/RET returns. The NUliquid tracks each operation through its lifecycle.
  • Debit and anticipation. The same intake-build-sign-transmit pipeline runs for the debit (ASLC029 / ASLC030) and anticipation (ASLC031 / ASLC034) families. The status returns and NUliquid tracking mirror the credit flow.
  • Cancellation. The acquirer informs a cancellation (credit ASLC060, debit ASLC064). Lerian SLC relays it to the IF Domicílio (ASLC061). The domicile returns its processing outcome (ASLC062). Lerian SLC returns the outcome to the acquirer (ASLC063 / ASLC067). It then emits a cancellation-confirmed-by-domicile event with the NUliquid.

​
IF Domicílio inbound

As the domicile institution, Lerian SLC receives credit and debit settlement notices (ASLC022 / ASLC024 / ASLC032). It confirms them (ASLC023 / ASLC025 / ASLC033). It issues returns and devolutions (ASLC041 / ASLC042 / ASLC043). A webhook keyed by the NUliquid signals the credit to the merchant and carries the return evidence.

​
Clearing and funding for the IF Liquidante

For the settling institution, Lerian SLC consumes the inbound clearing messages over the RSFN. These are the file-receipt acknowledgement (GEN0015), the preview and final clearing position (SLC0001), the bilateral-movement divergence (SLC0002), and the participant’s operational status (PAG0101). Lerian SLC builds the clearing position per settlement cycle and reconciles it against the expected instructions. It parses and surfaces the SLC0002 bilateral divergence. It raises events for preview-available, final-available, deposit-required, and deposit-deadline-approaching.

​
Operation lifecycle

The NUliquid tracks every operation through an 11-state lifecycle. Files carry their own 10-state lifecycle, from build through transmission and return correlation.

​
Signing orchestration

Lerian SLC materializes the unsigned ASLC XML and then delegates signing to a custody backend chosen per tenant. The private key never leaves the client’s custody, and Lerian never signs on the client’s behalf. SaaS deployments lock custody to cloud KMS through client-side-wrapped key import. The client wraps and imports its own key. The service stores only the public certificate and a key reference — never the private material.

​
Transport

Lerian SLC submits the online operations to Nuclea over REST — mTLS and a per-request JWS signature secure that channel (the SLC0908 / SLC0912 / SLC0915 online series). Inbound returns are polled and acknowledged over the same REST channel. File transmission is the one surface with a per-tenant choice: REST or Connect:Direct over the private RSFN. REST adds the per-request JWS because it crosses the public internet; Connect:Direct does not need it, since the payload already carries its SPB signature and the network is private.
The Connect:Direct wire client is not provisioned yet. A tenant configured for it fails closed with a typed transport error rather than silently falling back to REST, so REST is the only channel that carries files today.