> ## 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. # How Lerian SLC works > How Lerian SLC works: canonical intake, ASLC file build, ICP-Brasil custody signing, Nuclea transmission, and NUliquid-keyed card settlement lifecycle tracking. 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](#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 *** | Flow | Message family | | ----------------------- | --------------------------------------------------------- | | Credit settlement | ASLC027 / ASLC028 | | Debit settlement | ASLC029 / ASLC030 | | Anticipation | ASLC031 / ASLC034 | | Returns and devolutions | ASLC041 / ASLC042 / ASLC043 | | Cancellation | ASLC060–ASLC067 | | Sweep (varredura) | ASLC050 / ASLC051 | | Domicile inbound | ASLC022 / ASLC023 / ASLC024 / ASLC025 / ASLC032 / ASLC033 | ## 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. | State | Meaning | | ----------------- | ------------------------------------------------------------- | | **CREATED** | The operation has been accepted into Lerian SLC. | | **QUEUED** | It is queued for the next file build. | | **SENT** | Its file has been transmitted to Nuclea. | | **ACKNOWLEDGED** | Nuclea has acknowledged receipt. | | **ACCEPTED** | Nuclea has accepted the operation. | | **REJECTED** | Nuclea has rejected the operation. | | **FORWARDED** | The settlement notice has been forwarded to the IF Domicílio. | | **CONFIRMED** | The domicile has confirmed. | | **SETTLED** | The operation has settled. | | **D1\_CONFIRMED** | Settlement is confirmed on D+1. | | **CANCELLED** | The operation has been cancelled. | 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. | Custody backend | Where the key lives | | ---------------- | ------------------------------------------------ | | **Software key** | A software-held key in the client's environment. | | **PKCS#11 HSM** | A hardware security module. | | **Cloud KMS** | A cloud key-management service. | 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.