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 del producto, el CPF o el CNPJ y el nombre del prestatario, el monto por el que se pide la solicitud, la tasa de interés mensual solicitada, el número de cuotas y una fecha prevista de desembolso. El monto es exactamente uno entre el principal, el neto que recibe el prestatario o la cuota que cabe, y la versión debe admitir esa ancla. Lender acepta hasta 600 cuotas. La tasa solicitada debe quedar dentro de la banda de tasa de la versión, leída como tasa anual efectiva. La solicitud también puede indicar el sistema de amortización (price, sac o american), la periodicidad de pago (monthly, fortnightly o weekly), reglas de pago y tu propio número de contrato. Consulta Origina un préstamo. El documento define el tipo de prestatario: un CPF es pessoaFisica, un CNPJ es pessoaJuridica, y la versión debe admitirlo. Lender busca al titular del prestatario en el CRM de Midaz de la institución del producto, registra uno cuando no existe y guarda solo el id del titular. La liberación consulta el CRM de nuevo, así que un titular borrado entretanto la detiene (LENDER-0257). Sin Midaz configurado, una solicitud de crédito directo responde 503, y no se escribe nada. La solicitud registra la primera fecha de vencimiento al crearse: una fecha que eliges dentro de la ventana de la versión, o el día que el generador de cronograma define para la fecha prevista de desembolso. Todo cronograma de la solicitud, y la liberación, dependen de esa fecha. El cuerpo no lleva al oficial asignado. Lender lo toma del sujeto autenticado de la llamada de envío y lo registra. Ninguna decisión lo comprueba.

​
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. disbursedAt es opcional, y Lender usa el ahora de negocio del tenant cuando lo omites. Consulta Registra una liberación que tu institución hizo.
Lender comprueba las reglas de abajo. Comprueba todas, excepto la regla de saldo, antes de escribir nada. Comprueba la regla de saldo dentro de la transacción de desembolso, así que un fallo allí deshace 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, varios resultados

Un desembolso es una sola transacción de base de datos. Dentro de ella ocurren estas 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 el cronograma de amortización sobre el capital desembolsado acumulado, en el sistema de amortización y la periodicidad del contrato (price y monthly, salvo que la solicitud haya pedido otro). 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.
Cuando el contrato tiene vínculos de garantía vigentes y el plan del producto declara el control guarantee_received, la misma transacción también abre ese control para cada vínculo. Todo hace commit junto, o todo se revierte junto. 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. Un contrato quincenal o semanal, y uno cuya propuesta paga filas por regla, libera una sola vez (LENDER-0261, LENDER-0262). 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.