Skip to main content
Lerian Consignado — Dataprev is event-first at its platform edge. It consumes commands from the credit engine and emits business facts; it makes no direct ledger calls and hosts no webhook consumers. Its authoritative contract is the event stream, not its REST surface.

​
Commands it consumes

The gateway consumes two commands from the credit engine, carried as events over the platform’s streaming backbone:
  • a margin request, asking for a worker’s available payroll margin;
  • an averbação request, asking to register a signed contract with Dataprev.
A command that decodes but is missing its identifying key — for example the worker’s CPF — is terminal: it is dead-lettered rather than relayed to Dataprev.

​
Facts it emits

The gateway emits five business facts:
  • the fetched margin for a worker;
  • an averbação-confirmed result;
  • an averbação-rejected result;
  • a proposal-accepted signal, telling the downstream lending system to originate;
  • a reconciliation record — one per escrituração or settlement record.
Every fact carries a single, package-wide schema version, stamped identically across all five rather than versioned per event.

​
Sink-agnostic delivery

The gateway writes every fact to a transactional outbox and relays from there. It owns no per-destination routing: a downstream streaming hub decides which system receives each fact. The same fact can fan out to a ledger, a reconciliation store, or a lending system without the gateway knowing or caring who consumes it.

​
No direct ledger or webhook coupling

The gateway makes no direct Midaz calls and hosts no webhook consumers. Off-platform borrower contact is out of scope: the proposal-accepted fact is the handoff boundary, after which the downstream lending system owns origination and any borrower communication.

​
On the wire

  • Money and rates cross as decimal strings, never floating-point, so no precision is lost in transit.
  • Timestamps are UTC, RFC 3339.
  • No CPF crosses the reconciliation fact. This is enforced by construction: the reconciliation record types carry no CPF field, the CPF present in the escrituração source is dropped at the normalizer, and tests assert the serialized payload contains no CPF. The contract number is the match key, so no personal identifier is needed downstream. (The margin and proposal-accepted facts do carry a CPF, because each is keyed to a specific worker or proposal.)
  • The CEF repasse settles per daily movement, not per contract, so bank-side reconciliation keys on the transfer handle rather than the contract number.

​
Delivery semantics

  • Idempotent by immutable subject. Each record and settlement carries an immutable identifier; reprocessing it is a no-op downstream.
  • At-least-once. Events are delivered at least once; redelivery and restarts dedupe to a no-op.
  • Independent legs. In reconciliation, the escrituração and repasse legs are processed independently — one failing never blocks the other.