> ## 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. # Cómo funciona la originación > El camino que recorre una solicitud de préstamo: a qué se vincula, las cuatro decisiones del ciclo de vida, la única transacción que la desembolsa y la cuenta de préstamo que deja. La originación convierte una solicitud de crédito en una cuenta de préstamo viva. Tiene cuatro decisiones y una transacción que hace todo a la vez. Esta página sigue una solicitud desde enviada hasta desembolsada en el perfil genérico `XX`. Un préstamo brasileño regulado se origina a través del paquete de Brasil en lugar de `POST /api/v1/loan-applications`. Lee el [Paquete regulatorio de Brasil](/es/products/lender/brazil-regulatory-pack) para ese camino. ## A qué se vincula una solicitud *** Una solicitud se vincula a una **versión de producto**, nunca a un producto por sí solo. La versión fija la moneda, los términos de tasa y la base de devengo, así un contrato siempre se remonta a los términos bajo los que se creó. Una versión posterior no cambia un préstamo que ya existe. Vincula un **perfil contable** a esa versión antes de desembolsar. El desembolso construye su asiento a partir de las patas del perfil, y un desembolso sin perfil falla. Consulta [Definir un producto de préstamo](/es/products/lender/define-a-loan-product). ## Vista previa, si la quieres *** La vista previa del cronograma calcula las cuotas y la divulgación de costo para términos propuestos. No crea nada y no cambia nada. Úsala para mostrarle a un prestatario cómo se ve el préstamo antes de que alguien se comprometa. Este paso es opcional. ## Enviar *** La llamada de envío crea la solicitud en `pending_approval`. Lleva la versión de producto, el prestatario, el capital solicitado, la tasa de interés **mensual** solicitada, el número de cuotas y una fecha de desembolso esperada. Lender acepta hasta 600 cuotas. El body no lleva el **oficial asignado**. Lender lo toma del sujeto autenticado de la llamada de envío. Las decisiones posteriores se verifican contra ese oficial, así que envía con la identidad que también aprobará y desembolsará. ## Decidir *** Exactamente una decisión resuelve una solicitud pendiente. | Decisión | Resultado | Quién puede actuar | | -------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | Aprobar | `approved`, con el monto aprobado y una marca de tiempo de decisión | La política de aprobación de la jurisdicción. Bajo el perfil genérico, el oficial asignado. | | Rechazar | `rejected` | El oficial asignado. | | Retirar | `withdrawn` | El prestatario, o el oficial asignado. | Una solicitud aprobada todavía puede retirarse. `rejected` y `withdrawn` son finales, y nada sale de ellos. El monto aprobado es un límite, no un pago. Acota cada desembolso que sigue. ## Desembolsar *** El desembolso mueve dinero, así que lleva la mayor cantidad de resguardos. Tres cosas van en la solicitud: * Un header `X-Idempotency`. Lender lo requiere en esta operación. * El **identificador de cuenta de préstamo**. Es un UUID que eliges tú, y Lender no acuña uno por ti. Ese identificador localiza el cronograma, las transacciones, los cargos y el registro de auditoría. * El monto bruto solicitado y el monto neto entregado. Lender verifica cinco reglas. Verifica las primeras cuatro antes de escribir nada. Verifica la regla de balance dentro de la transacción de desembolso, así una falla ahí revierte todo el desembolso. | Resguardo | Regla | | ---------- | ---------------------------------------------------------------------------------- | | Monto | El bruto no debe exceder el monto aprobado. | | Total | El bruto de todos los tramos debe mantenerse dentro del monto aprobado. | | Cronología | El desembolso no debe ser anterior a la decisión de aprobación. | | Identidad | El identificador de cuenta de préstamo debe ser el mismo en cada tramo. | | Balance | El neto debe ser igual al bruto menos las retenciones que calcula la jurisdicción. | Bajo el perfil genérico no hay retenciones, así que **el neto es igual al bruto**. Un neto menor deja el asiento sin balancear y Lender rechaza el desembolso. ## Una transacción, cuatro resultados *** Un desembolso es una sola transacción de base de datos. Dentro de ella ocurren cuatro cosas. Lender agrega un evento de desembolso que registra los montos, la fecha y el actor que desembolsó. Lender calcula un cronograma de amortización Price (francés) sobre el capital desembolsado acumulado. Lo guarda como versión 1 del cronograma, con el motivo de cambio `origination`. Bajo el perfil genérico el pipeline no calcula nada, así que no agrega ninguna retención al desembolso. Lender escribe una intención de asiento balanceada en el outbox: el capital debitado al bruto, el efectivo acreditado al neto y un crédito por cada retención. Las cuatro hacen commit juntas, o las cuatro se revierten juntas. No hay préstamo a medio desembolsar. Si el cronograma no puede escribirse, o el asiento no balancea, la solicitud permanece en `approved`. ## Más de un tramo *** Puedes desembolsar una solicitud aprobada más de una vez. El estado permanece en `disbursed`, Lender agrega otro evento de desembolso y Lender escribe una **nueva versión del cronograma** sobre el capital acumulado. La nueva versión reemplaza a la anterior en la lectura. El total de todos los tramos aún no puede exceder el monto aprobado, y cada tramo usa el mismo identificador de cuenta de préstamo. ## Dos llamadores, una solicitud *** Cada escritura del ciclo de vida declara el estado que espera encontrar. Cuando dos llamadores deciden la misma solicitud al mismo tiempo, uno gana y el otro recibe `409 Conflict` sin cambiar nada. Un desembolso repetido que no coincide con el primero se rechaza de la misma forma. ## El modelo de estados *** | Desde | Decisión | Hacia | | ------------------------------- | ----------- | ----------- | | `pending_approval` | aprobar | `approved` | | `pending_approval` | rechazar | `rejected` | | `pending_approval` o `approved` | retirar | `withdrawn` | | `approved` o `disbursed` | desembolsar | `disbursed` | ## Lo que tienes al final *** * Una solicitud que lee `disbursed`, con un evento de desembolso por tramo. * Una cuenta de préstamo bajo el identificador que aportaste, que lleva su cronograma, sus transacciones, sus cargos y sus eventos de auditoría. * Una intención de asiento en camino al ledger. Esa contabilización es asíncrona, así que aterriza poco después de que la solicitud retorna, no durante ella. * Un evento de ciclo de vida en el backbone de streaming por cada transición, cuando el streaming está habilitado y hay un broker configurado. Continúa en [Administrar un préstamo](/es/products/lender/service-a-loan). ## Próximos pasos *** Registra pagos, anticipa, reprograma y corrige una cuenta de préstamo activa. Los dominios, la unión de jurisdicción y el outbox que saca el dinero. Reglas de asiento, ejecuciones de devengo y la referencia de diario que ata una contabilización de vuelta. IOF, CET, consentimiento de capitalización y el resto del perfil brasileño.