> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Lender in the platform

> How Lender posts to the Midaz ledger, emits lifecycle events on the streaming backbone, isolates tenants, and reports telemetry.

export const GDoubleEntry = ({children}) => <Tooltip headline="Double-entry accounting" tip="Every financial movement is recorded as at least two operations: a debit from one account and a credit to another, ensuring the system always balances." cta="See glossary" href="/en/glossary">
    {children}
  </Tooltip>;

export const GLedger = ({children}) => <Tooltip headline="Ledger" tip="The core financial book that records all transactions, balances, and operations for an organization — the single source of truth for a business unit's finances." cta="See glossary" href="/en/glossary">
    {children}
  </Tooltip>;

Lender is a Lerian primitive: it runs on the platform, not beside it. Four platform seams matter when you operate it — the ledger posting path, the event stream, multi-tenancy, and observability.

## The Midaz posting path

***

Lender is the source of truth for the credit journey; [Midaz](/en/midaz/about-midaz) is the source of truth for balances. Every financial event a loan produces is booked to the <GLedger>ledger</GLedger> as a balanced <GDoubleEntry>double-entry</GDoubleEntry> transaction — and the path is built to never lose a booking and never book to the wrong place.

<Steps>
  <Step title="A domain event produces a posting intent">
    When a loan is disbursed, a repayment is recorded, interest accrues, or a transaction is reversed, Lender persists a durable **posting intent** in the same database transaction that changes domain state. The intent is written to a transactional **outbox**, so it survives a crash between "state changed" and "ledger booked."
  </Step>

  <Step title="The relay posts a balanced transaction to Midaz">
    An outbox dispatcher drives the ledger relay, which posts the balanced double-entry transaction to Midaz through the official SDK. The legs come from the product's **accounting profile**.
  </Step>

  <Step title="Idempotency is durable">
    Each posting carries a deterministic idempotency key computed by Lender. A retried post collapses to the same Midaz transaction; Midaz's own idempotency window is a backstop, not the primary guard.
  </Step>

  <Step title="Routing fails closed">
    The transaction books into the ledger organization and ledger the accounting profile resolves. If routing cannot resolve a non-empty target, the post **fails closed** — Lender refuses to book rather than write into an empty or wrong target.
  </Step>
</Steps>

Lender reaches Midaz through [Access Manager](/en/platform/access-manager/access-manager): it authenticates with machine-to-machine (M2M) credentials and a short-lived JWT, per tenant.

## Lifecycle events

***

Lender publishes a catalog of **14 business events** over the platform streaming backbone (RedPanda, through Lerian's streaming library). Every event is **outbox-backed**, **tenant-scoped**, and carries a CloudEvents `source` set by your deployment, which also namespaces the streaming topic names, so downstream products and your own services can react to the credit journey as it unfolds. Subscribe on the source your deployment configures rather than a fixed literal.

| Domain      | Events                                                                                                                                             |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Products    | `loan_product.created`, `loan_product_version.created`, `loan_product.activated`, `accounting_profile.configured`, `loan_charge.applied`           |
| Origination | `loan_application.submitted`, `loan_application.approved`, `loan_application.rejected`, `loan_application.withdrawn`, `loan_application.disbursed` |
| Servicing   | `repayment.recorded`, `repayment_reversal.recorded`, `loan_schedule.prepayment_applied`, `loan_schedule.rescheduled`                               |

Because the events ride the same outbox as the ledger relay, event delivery and ledger booking share one durability guarantee: state, postings, and events commit together.

<Info>
  The Brazilian **consignado privado** journey contributes its own events on top of this catalog — margin, averbação, and reconciliation signals. See [Consignado privado](/en/lender/consignado-privado).
</Info>

## Multi-tenancy

***

Like every Lerian product, Lender is built for full tenant isolation from the ground up.

* **Schema-per-tenant** persistence when multi-tenancy is enabled, so tenant data never shares a table.
* **Tenant-scoped** events and ledger postings — every emitted event and every Midaz transaction carries the tenant it belongs to.
* Under multi-tenant mode, the ledger relay resolves a **per-tenant** Midaz client, and the accounting profile supplies the per-tenant ledger target (which is why routing fails closed when a target is missing).

See [Multi-tenancy](/en/multi-tenancy) for the platform-wide model.

## Observability

***

Lender emits structured logs, OpenTelemetry traces, and metrics on the same observability stack as the rest of the platform, including database, assertion, and panic-recovery metrics. See [Observability](/en/platform/observability).

## Next steps

***

<Card title="Accounting and accrual runs" icon="calculator" href="/en/lender/accounting-and-accrual-runs" horizontal>
  Go deeper on posting rules, accrual runs, and journal references.
</Card>

<Card title="Configuration and deploy" icon="gear" href="/en/lender/configuration-and-deploy" horizontal>
  See the dependencies and configuration the posting path and event stream require.
</Card>