Skip to main content
Brazil’s payment systems each carry their own messaging contract, certification, and operating windows. Depending on the payment system, you reach BACEN on Lerian-owned software or through a connectivity partner. Both models preserve your ledger, your accounts, and your business logic. A Brazil rail is Lerian-owned messaging software that connects your institution to BACEN or to a market infrastructure, with no intermediary. An interface is the product surface over a rail. Lerian offers its own interfaces (TED Lerian, Pix Lerian) and partner interfaces (Pix JD, Pix BTG, TED JD, Payments BTG). Partner interfaces ship as Midaz plugins: separately deployed services that extend Midaz and that Lerian licenses separately. Pix runs in production through two interfaces. The JD interface connects your institution as a direct participant through a certified PSTI. The BTG interface connects you as an indirect participant. TED runs through JD. The native Lerian rails are Lerian-owned software for a direct, non-intermediated connection to BACEN. They do not replace the JD and BTG paths.

What you get


Brazil Rails

Lerian-owned messaging straight to BACEN and its market infrastructures.

Interfaces

The product surface over a rail: the API, the ledger integration, and the operational controls.

Midaz

The ledger that records the money an interface moves.

Reporter

Renders the daily CCS remittance file Lerian CCS submits.

Streaming Hub

Delivers Lerian CCS and Lerian SCR events to a sink you own.

How the pieces fit together


The native path takes four steps:
  1. Your application calls TED Lerian. The interface gives you the API, the ledger events, and the operator workflows.
  2. TED Lerian hands the message to Lerian SPB, which reaches the STR over the RSFN.
  3. Lerian SPB dispatches the message to BACEN, with no connectivity partner in the path. BACEN confirms settlement asynchronously.
  4. The rail emits settlement facts and computes no balance of its own. Your ledger consumer records the money movement.
Lerian SPI, the native Pix rail, has the same shape: it holds no accounting position and emits settlement facts for your ledger consumer. Pix Lerian sits above it and connects Lerian SPI to the rest of your stack. The partner path takes three steps:
  1. Your application calls a plugin. Pix JD, Pix BTG, TED JD, and Payments BTG ship as Midaz plugins. Pix Lerian is Lerian’s own Pix plugin, and it also posts to Midaz.
  2. The provider carries the regulated connectivity. JD reaches BACEN’s SPI and DICT for a direct participant, and BTG connects an indirect participant.
  3. Pix JD posts every settled Pix movement to Midaz, with the external leg against the clearing account. TED JD reserves funds in Midaz as a hold, then debits them when the transfer settles. Payments BTG records boletos and bill payments against your Midaz ledger.
Pix Lerian is Lerian’s Pix plugin, and one plugin serves every path below it. Midaz is its mandatory ledger. It covers account validation, balance checks, debit and credit posting, and routing. Pix Lerian does not speak to BACEN itself. The gateway layer below it is a direct participant, a certified PSTI, or Lerian SPI. Two more chains run on files rather than payment messages. Reporter renders your daily ACCS001 remittance from your customer data. Lerian CCS reads that file, builds one batch line item per operation, and submits it through Lerian STA. Lerian CCS does not connect to BACEN directly, and it cannot build the file without Reporter. BACEN answers on the inbound file channel. An accepted record moves that customer relationship to the accepted state. Courts issue asset orders, and BACEN delivers them through its STA channel. Lerian SISBAJUD receives each order as a fixed-layout file. It runs the block or unblock against your Midaz ledger and reports each outcome to BACEN. No order enters through the API. Lerian SLC sends card settlement files to Nuclea over the RSFN, and Lerian SILOC relays card traffic to it.

What each piece owns


Adopt it one piece at a time


1

Pick the rail and the model

Choose native messaging for a direct link, or a partner interface for JD or BTG connectivity.
2

Start with one interface

Lerian sets a partner interface’s connection to Midaz at deploy time, and your application never sees it.
3

Wire your ledger consumer

On Lerian SPB, record a pending posting on str.operation.accepted. Take the final position from the settlement.* facts, and deduplicate on the (ce-source, ce-id) pair.
4

Add the regulatory rails

Add Lerian CCS, Lerian SISBAJUD, and Lerian SCR as your obligations require.

Bring your own


  • Your ledger. A native rail emits settlement facts for your ledger consumer, and it does not require a particular ledger.
  • Your certificates and keys. Lerian SLC delegates signing to a custody backend you control, and the private key never leaves your custody. Each Consignado CLT (Dataprev) tenant uses its own ICP-Brasil client certificate.
  • Your access control. Access Manager authenticates a partner plugin’s API, and the plugin validates every incoming request when you enable it.
  • Your event consumers. TED Lerian delivers control-plane events to webhooks you register. TED JD notifies your endpoint when a transfer completes, fails, or needs attention. The Consignado CLT (Dataprev) rail has its own subscription API.
  • Your operators. Enable a payment plugin in the Lerian Console, and its menu item appears in the Midaz module sidebar. If you disable it, its configuration stays.

A worked example


One TED through TED Lerian posts in two phases:
  1. Your application calls TED Lerian to send the transfer.
  2. Lerian SPB dispatches the STR message to BACEN and returns the status ACCEPTED. That status means dispatch acceptance, not settlement.
  3. The str.operation.accepted event signals that acceptance. Your ledger consumer records a pending posting.
  4. The operation moves to CONFIRMED when settlement.settled arrives. Your consumer finalizes the posting.
  5. On settlement.returned, a confirmed return reverses a settled original. Your consumer reverses the parent posting.
Pix JD does the posting for you instead. It posts every settled Pix movement to Midaz, keyed by the end-to-end ID, so a retried settlement never double-posts.

Start here


Brazil Rails

One anchor per rail, and the messaging that reaches it.

Interfaces

Every interface, and the paths in production today.

Native messaging and partner interfaces

How the two connection models compare.