> ## 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 en la plataforma

> Cómo Lender se contabiliza en el ledger de Midaz, emite eventos del ciclo de vida en el backbone de streaming, aísla tenants y reporta telemetría.

export const GDoubleEntry = ({children}) => <Tooltip headline="Partida doble" tip="Cada movimiento financiero se registra como al menos dos operaciones: un débito de una cuenta y un crédito en otra, asegurando que el sistema siempre esté balanceado." cta="Ver glosario" href="/es/glossary">
    {children}
  </Tooltip>;

export const GLedger = ({children}) => <Tooltip headline="Ledger" tip="El libro financiero central que registra todas las transacciones, saldos y operaciones de una organización — la fuente única de verdad para las finanzas de una unidad de negocio." cta="Ver glosario" href="/es/glossary">
    {children}
  </Tooltip>;

Lender es un primitivo de Lerian: corre sobre la plataforma, no al lado de ella. Cuatro costuras con la plataforma importan cuando lo operas — la ruta de posting al ledger, el flujo de eventos, la multi-tenancy y la observabilidad.

## La ruta de posting a Midaz

***

Lender es la fuente de verdad de la jornada de crédito; [Midaz](/es/midaz/about-midaz) es la fuente de verdad de los saldos. Un desembolso y cada devengo de interés se vuelven una transacción de <GDoubleEntry>partida doble</GDoubleEntry> balanceada destinada al <GLedger>ledger</GLedger>. También un prepago que liquida una cuenta de préstamo brasileña contra una cotización de prepago. La ruta preserva esa intención de posting y la entrega de forma idempotente. El ledger alcanza consistencia una vez que la entrega del outbox tiene éxito y el dispatcher contabiliza, lo que puede demorarse o quedar pendiente mientras el enrutamiento no esté disponible.

<Steps>
  <Step title="Un evento del dominio produce una intención de posting">
    Cuando un préstamo se desembolsa, se devenga interés o se liquida una cotización de prepago brasileña, Lender persiste una **intención de posting** durable en la misma transacción de base de datos que cambia el estado del dominio. La intención se escribe en un **outbox** transaccional, de modo que sobrevive a una caída entre "el estado cambió" y "se contabilizó en el ledger".
  </Step>

  <Step title="El relay contabiliza una transacción balanceada en Midaz">
    Cuando el relay del ledger de Midaz está configurado, un dispatcher del outbox contabiliza la transacción de partida doble balanceada mediante el SDK oficial. De lo contrario, la intención durable queda en el outbox. Los asientos vienen del **perfil contable** del producto.
  </Step>

  <Step title="La idempotencia es durable">
    Cada posting lleva una clave de idempotencia determinista calculada por Lender. Un posting reintentado colapsa a la misma transacción de Midaz; la propia ventana de idempotencia de Midaz es un respaldo, no la guarda principal.
  </Step>

  <Step title="El enrutamiento falla cerrado">
    La transacción se contabiliza en la organización de ledger y el ledger que resuelve el perfil contable. Si el enrutamiento no puede resolver un destino no vacío, el posting **falla cerrado** (fail-closed) — Lender se niega a contabilizar en lugar de escribir en un destino vacío o equivocado.
  </Step>
</Steps>

Cuando el relay del ledger está configurado, Lender llega a Midaz a través de [Access Manager](/es/platform/access-manager/access-manager): se autentica con credenciales máquina-a-máquina (M2M) y un JWT de vida corta, por tenant.

## Eventos del ciclo de vida

***

Cuando el streaming está habilitado y hay un broker configurado, Lender publica los **22 eventos de negocio de la jornada de crédito documentada** sobre el backbone de streaming de la plataforma (RedPanda, a través de la librería de streaming de Lerian). Cada evento está **respaldado por el outbox** y es **de alcance por tenant**, para que los productos downstream y tus propios servicios puedan reaccionar a la jornada de crédito a medida que avanza.

El source de CloudEvents de Lender es el literal fijo `lender`. Configura `STREAMING_CLOUDEVENTS_SOURCE=lender` — streaming exige ese valor, y el source también sirve de namespace para cada topic. Así, un suscriptor lee:

| Elemento del wire  | Valor                                                                                       |
| ------------------ | ------------------------------------------------------------------------------------------- |
| Topic de Kafka     | `lender.<resource>.<event>` — por ejemplo `lender.loan_application.disbursed.v2`            |
| Header `ce-source` | `lender`                                                                                    |
| Header `ce-type`   | `studio.lerian.<resource>.<event>` — por ejemplo `studio.lerian.loan_application.disbursed` |
| Clave de partición | el tenant                                                                                   |

Suscríbete por topic. Los topics se agrupan por dominio:

| Dominio            | Topics                                                                                                                                                                                               |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Productos          | `lender.loan_product.created`, `lender.loan_product.activated`, `lender.loan_product_version.created`, `lender.accounting_profile.configured`, `lender.loan_charge.applied`                          |
| Originación        | `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`                                                     |
| Paquete Brasil     | `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`                       |

Como los eventos viajan por el mismo outbox que el relay del ledger, comparten una sola garantía de durabilidad: el cambio de estado local y el evento se confirman juntos en una sola transacción de base de datos. La intención de posting se les suma cuando el cambio produce una. El dispatcher del outbox aplica la contabilización en el ledger después, cuando transmite la intención a Midaz — de modo que el estado de Lender y la contabilización en Midaz son eventualmente consistentes, no se confirman en la misma transacción.

<Info>
  La jornada de **consignado privado** también consume hechos del gateway de descuento en nómina, en los topics de ese producto. Consulta [Consignado privado](/es/lender/consignado-privado).
</Info>

## Multi-tenancy

***

Como todo producto Lerian, Lender está construido para aislamiento total de tenants desde su base.

* Persistencia **schema-por-tenant** cuando la multi-tenancy está habilitada, de modo que los datos de un tenant nunca comparten tabla.
* Eventos y postings al ledger **de alcance por tenant** — cada evento emitido y cada transacción de Midaz lleva el tenant al que pertenece.
* En modo multi-tenant, el relay del ledger resuelve un cliente de Midaz **por tenant**, y el perfil contable aporta el destino de ledger por tenant (por eso el enrutamiento falla cerrado cuando falta un destino).

Consulta [Multi-tenancy](/es/multi-tenancy) para el modelo a nivel de plataforma.

## Observabilidad

***

Lender emite logs estructurados, trazas OpenTelemetry y métricas sobre el mismo stack de observabilidad que el resto de la plataforma, incluyendo métricas de base de datos, de aserciones y de recuperación de panics. Consulta [Observabilidad](/es/platform/observability).

## Próximos pasos

***

<Card title="Contabilidad y ejecuciones de devengo" icon="calculator" href="/es/lender/accounting-and-accrual-runs" horizontal>
  Profundiza en las reglas de posting, las ejecuciones de devengo y las referencias de asiento.
</Card>

<Card title="Configuración y despliegue" icon="gear" href="/es/lender/configuration-and-deploy" horizontal>
  Mira las dependencias y la configuración que requieren la ruta de posting y el flujo de eventos.
</Card>