> ## 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 > La ruta que recorre una solicitud de préstamo: a qué se ata, 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 de una vez. Esta página sigue una solicitud desde enviada hasta desembolsada sobre el perfil genérico `XX`. Un préstamo regulado brasileño se origina por el pack regulatorio de Brasil, no por `POST /api/v1/loan-applications`. Lee el [Pack regulatorio de Brasil](/es/lender/brazil-regulatory-pack) para esa ruta. ## A qué se ata una solicitud *** Una solicitud se ata a una **versión del 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í que un contrato siempre rastrea a los términos con los que fue creado. Una versión posterior no cambia un préstamo que ya existe. Ata un **perfil contable** a esa versión antes de desembolsar. El desembolso construye su posting con los asientos del perfil, y un desembolso sin perfil falla. Consulta [Definir un producto de préstamo](/es/lender/define-a-loan-product). ## Previsualiza, si quieres *** La previsualización de cronograma calcula las cuotas y la divulgación de costo para términos prospectivos. No crea nada y no cambia nada. Úsala para mostrarle al deudor cómo se ve el préstamo antes de que alguien se comprometa. Este paso es opcional. ## Envía *** La llamada de envío crea la solicitud en `pending_approval`. Lleva la versión del producto, el deudor, el principal solicitado, la tasa de interés **mensual** solicitada, la cantidad de cuotas y una fecha esperada de desembolso. Lender acepta hasta 600 cuotas. Un campo no va en el body: 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 va a aprobar y desembolsar. ## Decide *** 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 deudor, o el oficial asignado. | Una solicitud aprobada todavía se puede retirar. `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. ## Desembolsa *** El desembolso mueve dinero, así que carga la mayor cantidad de guardas. Tres cosas van en el request: * Un header `X-Idempotency`. Lender lo exige en esta operación. * El **identificador de la cuenta de préstamo**. Es un UUID que eliges tú, y Lender no acuña uno por ti. El cronograma, las transacciones, los cargos y el rastro de auditoría se direccionan todos por él. * 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í que una falla ahí revierte todo el desembolso. | Guarda | Regla | | ---------- | -------------------------------------------------------------------------------- | | Monto | El bruto no debe exceder el monto aprobado. | | Total | El bruto de todos los tramos debe quedar dentro del monto aprobado. | | Cronología | El desembolso no debe ser anterior a la decisión de aprobación. | | Identidad | El identificador de la cuenta de préstamo debe ser el mismo en cada tramo. | | Balance | El neto debe igualar el bruto menos las retenciones que calcula la jurisdicción. | La regla de balance es la que sorprende a los integradores. Bajo el perfil genérico no hay retenciones, así que **el neto iguala el bruto**. Un neto menor deja el posting sin cuadrar y Lender rechaza el desembolso. ## Una transacción, cuatro resultados *** Un desembolso es una sola transacción de base de datos. Adentro pasan 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 principal desembolsado acumulado. Guarda el resultado como versión 1 del cronograma, con la razón 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 posting balanceada en el outbox: principal debitado al bruto, caja acreditada al neto, y un crédito por cada retención. Los cuatro se comprometen juntos, o los cuatro se revierten juntos. No hay préstamo desembolsado a medias. Si el cronograma no se puede escribir, o el posting no balancea, la solicitud queda en `approved`. ## Más de un tramo *** Puedes desembolsar una solicitud aprobada más de una vez. El estado queda en `disbursed`, Lender agrega otro evento de desembolso, y Lender escribe una **versión nueva del cronograma** sobre el principal acumulado. La versión nueva sustituye a la anterior en la lectura. El total de los tramos todavía no puede exceder el monto aprobado, y cada tramo usa el mismo identificador de la cuenta de préstamo. ## Dos llamadas, una solicitud *** Cada escritura del ciclo de vida declara el estado que espera encontrar. Cuando dos llamadas deciden la misma solicitud al mismo tiempo, una gana y la otra recibe `409 Conflict` sin cambiar nada. Un desembolso repetido que no coincide con el primero se rechaza igual. ## 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` | ## Qué 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, con su cronograma, sus transacciones, sus cargos y sus eventos de auditoría. * Una intención de posting en camino al ledger. Esa contabilización es asíncrona, así que cae poco después de que el request retorna, no durante. * Un evento de ciclo de vida en el backbone de streaming por cada transición. Continúa en [Servicing de un préstamo](/es/lender/service-a-loan). ## Próximos pasos *** Registra repagos, prepaga, reprograma y corrige una cuenta de préstamo activa. Los dominios, la costura de jurisdicción y el outbox que saca el dinero. Reglas de posting, ejecuciones de devengo y la referencia de asiento que ata una contabilización. IOF, CET, consentimiento de capitalización y el resto del perfil brasileño.