Saltar al contenido principal
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.
La jurisdicción XX no registra crédito. Lender rechaza sus productos, versiones y solicitudes con 422. Lee el Paquete regulatorio de Brasil para lo que el perfil BR agrega a este 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. El producto debe estar activo, y la versión debe ser aquella en la que el producto origina en ese momento. La activación requiere un perfil contable en la versión. El desembolso construye su asiento a partir de las patas del perfil. Consulta Definir un producto de préstamo.

Vista previa, si la quieres


La vista previa del cronograma calcula las cuotas y la divulgación de costo para términos propuestos. Cuando registra el resultado como una oferta, devuelve el identificador de la oferta. No crea ninguna solicitud. Ú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 y el tipo de 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. La tasa solicitada debe quedar dentro de la banda de tasa de la versión. 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. Una solicitud aprobada todavía puede retirarse. rejected y withdrawn son finales, y nada sale de ellos. El monto aprobado no mueve dinero. 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. Bajo BR la retención es el IOF. Cotízalo antes de desembolsar con la vista previa de impuestos del Paquete regulatorio de Brasil.

Una transacción, cuatro resultados


Un desembolso es una sola transacción de base de datos. Dentro de ella ocurren cuatro cosas.
1

La solicitud pasa a desembolsada

Lender agrega un evento de desembolso que registra los montos, la fecha y el actor que desembolsó.
2

Lender escribe el cronograma

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.
3

Corre el pipeline de la jurisdicción

Bajo BR el pipeline calcula la retención de IOF.
4

Lender encola la intención de asiento

Lender escribe una intención de asiento balanceada en el outbox: el capital debitado al bruto, el efectivo acreditado al neto, un crédito por cada retención y un crédito por una comisión de originación retenida.
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


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 eventos por cada transición.
Continúa en Administrar un préstamo.

Próximos pasos


Administrar un préstamo

Registra pagos, anticipa, reprograma y corrige una cuenta de préstamo activa.

Arquitectura de Lender

Los dominios, la unión de jurisdicción y el outbox que saca el dinero.

Contabilidad y ejecuciones de devengo

Reglas de asiento, ejecuciones de devengo y la referencia de diario que ata una contabilización de vuelta.

Paquete regulatorio de Brasil

IOF, CET, consentimiento de capitalización y el resto del perfil brasileño.