How Lerian Consignado — Dataprev works

Lerian Consignado combines synchronous HTTP commands with asynchronous facts and scheduled Dataprev reads. The HTTP API admits work and answers queries. The outbox publishes business facts. Background workers discover or recover state that Dataprev exposes as feeds rather than callbacks.

​

1. Configure a tenant

Before a tenant can call the rail, register:

• an ICP-Brasil A1 client certificate and private key
• OAuth2 client credentials
• the tenant’s three-digit Dataprev requester code
• optionally, the worker portal base URL offered as a formalization contact in bid proposals

Credential status returns presence, certificate fingerprint, and expiry metadata. It never returns the certificate, private key, or OAuth secret. In a managed deployment, a rail operation for a tenant without the certificate, the OAuth credentials, or the requester code answers DATAPREV_CREDENTIAL_REQUIRED. When partners originate loans in the tenant’s name, register each one as an originador. When the tenant assigns credits to funds, register each fund. A deactivated originador cannot place bids, and the gateway keeps its record.

​

2. Read worker data and margin

The margin endpoint authenticates the tenant, obtains the worker’s Dataprev authorization context, and returns the rail response without turning it into an underwriting decision. When Dataprev returns them, the answer also carries the worker, employment, and employer records. The API also exposes new employment links, termination reports, authorized FGTS records, and FGTS balance reads.

​

3. Discover auctions and submit proposals

A scheduled discovery loop lists open loan requests and publishes each new one. An optional fast lane repeats that listing every second. A client can then submit a bid through the authenticated HTTP API. The gateway retains the durable bid payload needed to prove what the client sent and later publishes the accepted-proposal witness. A bid can name an originador. The gateway refuses a bid for an unknown or deactivated originador. An originador that authenticates with its own credential bids under its own reference. Every proposal must reach the worker through at least one contact. The gateway adds a formalization portal as a contact when it finds one: on the bid first, then on the named originador, then on the tenant. When none of the three has a portal, each proposal must carry a client contact. Otherwise the gateway refuses the bid before it calls Dataprev. Portability auctions use a separate response operation and a bounded Dataprev request window.

​

4. Register and fund the contract

The registration flow:

1. registers the contract with Dataprev
2. attaches the CCB document when required
3. exposes registration status and rail documents
4. records the client’s disbursement confirmation
5. publishes immutable booking and payment facts through the outbox

A downstream lender or ledger decides what those facts mean for its own books. The gateway does not post directly to the ledger. Import a contract that is already registered on the rail outside this gateway. The import reads the contract from Dataprev and moves no money. Only an active or suspended contract can be imported. A contract the tenant already holds answers CONTRACT_ALREADY_REGISTERED. Record a correction against the registered contract when something the client already asserted turns out to be wrong. Examples are the wrong CCB file and a disbursement confirmation with the wrong evidence. A correction crosses no government boundary: the rail’s own rectification fields are retired, so the client remains the only authority. The gateway takes custody of the corrected bytes, publishes the fact that names them, and serves them back under authentication. Corrections chain: each one supersedes the event before it.

​

5. Service the contract

The API covers the rail lifecycle after registration: suspension, reactivation, term changes, installment anticipation and reversal, and exclusion. It also covers refinancing and reversal, renegotiation, portability registration, and legacy-contract operations. Portability runs in both directions. As the proponent institution, register the inbound portability. As the origin institution, exclude the contract the worker moved away. The gateway accepts that only for a contract it registered itself. It refuses anything else before it calls the rail. Reversing a refinancing works the same way. You can reverse a refinancing through this gateway only if the gateway registered it. The 7-business-day window is judged against the gateway’s own record of when that refinancing committed. The gateway reports the outstanding balance (saldo devedor) to Dataprev for the contracts it registers through averbação and the contracts it imports. The reported balance is the present value of the unpaid installments still ahead, on the Brasília date of the report. The gateway discounts each installment at the contract’s monthly rate and assumes payment on the due date. It sends a report when the debt changes, when an installment falls due without payment, and on the last business day of a month with no report. Exclusion is a recoverable operation. The initial authenticated command records the intent, and a scheduled recovery loop drives admitted work to a terminal rail state. Repeating the same idempotent command does not create a second exclusion. Refinancing, reversal, renegotiation, and origin-side portability exclusion have a recovery loop of their own for the same reason. The loop converges a command whose outcome nobody established against the rail registry instead of losing it.

​

6. Reconcile payroll and repasse

The reconciliation worker reads two independent Dataprev sources:

• bookkeeping records, keyed by the payroll competence and contract context
• CEF repasse records, which represent the settlement movement

The gateway emits one reconciliation fact per source record and tracks expected repasses. A repasse can become overdue, later resolve, or become unobservable when the gateway cannot establish a current rail view. Consumers must not treat silence as settlement.

​

7. Operate portfolios and guarantees

Additional API families cover operational calendars, employment terminations, FGTS guarantee execution, funds, originadores, assigned credits, assignments, per-tenant throughput, usage, and event-delivery subscriptions.