Loan management system

A credit operation runs for months or years. It touches product, risk, operations, and accounting at every stage. Most institutions assemble it from a product catalog here, an origination tool there, and servicing in the core. Lerian composes it from separate pieces that each own one boundary. Lender runs the credit journey, Midaz holds the balances, and the Consignado CLT (Dataprev) rail owns the Dataprev boundary. Each piece hands the next one a recorded fact, never a guess.

​

What you get

---

​

How the pieces fit together

---

1. Your channel calls Lender over HTTP. Loan products, applications, loan accounts, accrual runs, and the Brazilian regulatory records all sit under /api/v1. There is no client library to install.
2. For a payroll loan, Lender emits a command on its command topic. The rail reads that command and calls Dataprev with the tenant’s requester code, OAuth credentials, and ICP-Brasil certificate.
3. The rail publishes business facts back onto its own topic. Lender consumes those facts and moves the loan application through its stages.
4. A disbursement or an interest accrual writes a durable posting intent. The intent lands in the same database transaction that changes the domain state.
5. The ledger relay posts the balanced double-entry transaction to Midaz through the official SDK. Each posting carries a deterministic idempotency key, so a retried post collapses to one Midaz transaction.
6. The relay reaches Midaz through Access Manager. It authenticates with machine-to-machine credentials and a short-lived JWT, per tenant.
7. Lender publishes its own facts on its own event topic. Streaming Hub follows that topic and delivers each matched event to a destination you own.

Routing fails closed. The accounting profile resolves the organization and the ledger that receive each posting. When routing resolves no target, Lender refuses to post rather than book into an empty or wrong ledger. One optional input closes the loop. When you reconcile with Matcher, Lender consumes the completed match run and translates the verdict into a servicing stage transition and the matching posting intent. That integration is configuration-gated, and both sides must agree on the CloudEvents source before you enable it.

​

What each piece owns

---

​

Adopt it one piece at a time

---

​

Bring your own

---

• Your channels. The REST API is the whole client surface, so you call Lender from the stack you already run.
• Your secrets custody. The relay reads its machine-to-machine credentials from AWS Secrets Manager, or from HashiCorp Vault KV v2 when you select it.
• Your identity protocols. Access Manager’s identity provider supports OAuth 2.0 and OIDC, SAML 2.0, SCIM 2.0 provisioning, and LDAP against an external directory.
• Your event consumers. A Streaming Hub subscription delivers to a webhook, a pull cursor, Amazon SQS, RabbitMQ, or Amazon EventBridge.
• Your reconciliation sources, through Matcher. See Reconciliation.

​

A worked example

---

This example follows a private-sector payroll loan from the first call to the ledger entry.

1. Your channel creates the loan application in Lender against a loan product version.
2. Lender emits the margin request command. The rail performs the worker margin read against Dataprev and returns the rail response, without turning it into an underwriting decision.
3. You price the loan and approve it under your own credit policy. Lender records the contracted rate, the CET, the IOF, and the installment plan as facts, and binds them to the product version.
4. Brazilian origination adds regulated steps. Lender records the CET disclosure. It also records the capitalization consent, with the clause text and the hash it recomputes.
5. The rail registers the contract with Dataprev, attaches the CCB document, and publishes the booking and payment facts. Lender consumes the contract registration and the disbursement confirmation.
6. Lender commits the disbursement event, the origination schedule, and the posting intent in one database transaction. The relay posts the balanced transaction to Midaz shortly after the response.
7. Each accrual run posts the same way, on the same idempotency guarantee. If you reconcile, a completed match run moves the servicing stage and creates the matching posting intent.

​

Start here

---