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.

​

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. 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. 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. Every proposal must reach the worker through at least one contact. The gateway adds the tenant’s formalization portal as a contact when the tenant registers one. A bid may override that portal for its own submission. The gateway refuses a proposal with no registered portal and no client contact 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. 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 incoming 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. 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, assigned credits, assignments, per-tenant throughput, usage, and event-delivery subscriptions.