> ## 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

> See how Lender posts to the Midaz ledger, emits lifecycle events on the streaming backbone, isolates tenants per schema, and reports telemetry data.

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. A disbursement and each interest accrual become a balanced <GDoubleEntry>double-entry</GDoubleEntry> transaction bound for the <GLedger>ledger</GLedger>. So does a prepayment that settles a Brazilian loan account against a prepayment quote. The path preserves that posting intent and delivers it idempotently. The ledger reaches consistency once the outbox delivery succeeds and the dispatcher posts, which may lag or stay pending while routing is unavailable.

<Steps>
  <Step title="A domain event produces a posting intent">
    When a loan is disbursed, interest accrues, or a Brazilian prepayment quote settles, 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">
    When the Midaz ledger relay is configured, an outbox dispatcher posts the balanced double-entry transaction through the official SDK. Otherwise, the durable intent remains in the outbox. 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>

When the ledger relay is configured, 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

***

When streaming is enabled and a broker is configured, Lender publishes the **22 business events of the documented credit journey** over the platform streaming backbone (RedPanda, through Lerian's streaming library). Every event is **outbox-backed** and **tenant-scoped**, so downstream products and your own services can react to the credit journey as it unfolds.

Lender's CloudEvents source is the fixed literal `lender`. Set `STREAMING_CLOUDEVENTS_SOURCE=lender` — streaming requires that value, and the source also namespaces every topic. A subscriber therefore reads:

| Wire element       | Value                                                                                       |
| ------------------ | ------------------------------------------------------------------------------------------- |
| Kafka topic        | `lender.<resource>.<event>` — for example `lender.loan_application.disbursed.v2`            |
| `ce-source` header | `lender`                                                                                    |
| `ce-type` header   | `studio.lerian.<resource>.<event>` — for example `studio.lerian.loan_application.disbursed` |
| Partition key      | the tenant                                                                                  |

Subscribe by topic. The topics group by domain:

| Domain             | Topics                                                                                                                                                                                               |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Products           | `lender.loan_product.created`, `lender.loan_product.activated`, `lender.loan_product_version.created`, `lender.accounting_profile.configured`, `lender.loan_charge.applied`                          |
| Origination        | `lender.loan_application.submitted.v2`, `lender.loan_application.approved.v2`, `lender.loan_application.rejected.v2`, `lender.loan_application.withdrawn.v2`, `lender.loan_application.disbursed.v2` |
| Servicing          | `lender.repayment.recorded`, `lender.repayment_reversal.recorded`, `lender.loan_schedule.prepayment_applied`, `lender.loan_schedule.rescheduled`                                                     |
| Brazil pack        | `lender.loan_account.pdd_stage_transitioned`, `lender.loan_account.debt_balance_changed`, `lender.prepayment_quote.created`, `lender.prepayment_settlement.recorded`                                 |
| Consignado privado | `lender.consignado_exclusao.requested`, `lender.consignado_redirecionamento.requested`, `lender.payroll_deduction.refund_required`, `lender.guarantee_recovery_cash.allocated`                       |

Because the events ride the same outbox as the ledger relay, they share one durability guarantee: the local state change and the event commit together in a single database transaction. The posting intent joins them when the change produces one. The outbox dispatcher applies the ledger posting afterward, when it relays the intent to Midaz — so Lender's state and the Midaz booking are eventually consistent rather than committed in the same transaction.

<Info>
  The **consignado privado** journey also consumes facts from the payroll-deduction gateway, on that product's own topics. 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>