El ciclo de vida de la solicitud
Una solicitud pasa por estados con nombre. Cada transición es una operación distinta, y cada una guarda un registro de decisión o de desembolso:
Pasos
1
Previsualizar el cronograma (opcional)
POST /api/v1/loan-applications/preview-schedule calcula el cronograma de amortización para términos propuestos sin originar nada. Cuando registra la cotización como oferta, devuelve el scheduleOfferSnapshotId de la oferta, que la solicitud puede citar. Úsalo para mostrar cuotas y divulgaciones antes de que alguien se comprometa.2
Enviar la solicitud
POST /api/v1/loan-applications crea la solicitud contra la versión actual del producto. Declara el tipo de prestatario, y la tasa solicitada debe caer dentro de la banda de tasa de la versión.3
Decidir
Resuelve la solicitud con exactamente una de las siguientes:
POST /api/v1/loan-applications/{id}/approve: acéptala, con un registro de decisión.POST /api/v1/loan-applications/{id}/reject: recházala, con un registro de decisión.POST /api/v1/loan-applications/{id}/withdraw: retírala mientras está pendiente de aprobación o, después de la aprobación, antes del desembolso.
4
Desembolsar
POST /api/v1/loan-applications/{id}/disburse registra los fondos entregados. Toma la clave X-Idempotency que toma toda escritura de esta página. Por eso, un reintento con la misma clave repite la primera respuesta y no registra un segundo desembolso.Una sola transacción de base de datos confirma el evento de desembolso, el cronograma de originación y una intención de asiento balanceada. Cuando la llamada retorna, el préstamo es una cuenta de préstamo activa que administras de aquí en adelante.La contabilización en el ledger no está dentro de esa transacción. Con el relay del ledger configurado, un despachador del outbox transmite la intención a Midaz poco después de la respuesta, a través del perfil contable del producto. De lo contrario, la intención permanece en el outbox. Consulta la ruta de asiento.Toda escritura toma una clave de idempotencia
Crear una solicitud y moverla (aprobar, rechazar, desistir, desembolsar) exigen todas el encabezado
X-Idempotency. Lender lee la clave con esa grafía y con ninguna otra. Rechaza Idempotency-Key y X-Idempotency-Key por nombre, para que un cliente nunca quede desprotegido en silencio por haber adivinado el encabezado. Enviar una de esas junto con el encabezado del contrato no es problema. El rechazo solo se dispara cuando X-Idempotency está ausente.
La guarda falla cerrada. Cuando el almacén de idempotencia no puede responder, Lender rechaza el pedido con
503 en vez de dejarlo pasar sin protección.
Crear cuesta una clave a propósito: sin ella, un cliente que agota el tiempo al crear y llama de nuevo abre una segunda solicitud para el mismo prestatario. Es el duplicado más barato de producir en el servicio y el más caro de deshacer. Es caro porque las dos copias se ven legítimas y solo una persona sabe decir cuál es la verdadera.
En las cuatro escrituras de ciclo de vida, puedes conciliar un pedido que termina sin resolverse y reenviarlo bajo una clave nueva. Lee la solicitud por id y pregunta si ya sostiene el estado que querías. El desembolso es la excepción, donde una clave nueva no es una recuperación segura en absoluto. Una segunda liberación legítima declara su tramo.
El producto tiene que estar activo
La originación lee el estado de activación del producto de préstamo y rechaza un producto que no está activo, con
LENDER-0225 y un 422. El rechazo se ubica en los tres pasos que deciden crédito nuevo: crear la solicitud, aprobarla y liberar el dinero por la API. Por eso, un producto apagado después de presentada la solicitud la detiene antes de que salga el dinero.
Crear una solicitud también tiene que nombrar la versión vigente del producto, o Lender la rechaza con LENDER-0226 y un 422. Esa comprobación corre en la creación y en ningún otro lado, porque una solicitud se queda de por vida en la versión en que nació. Promover una versión nueva nunca mata entonces las solicitudes detenidas en la anterior, y cada una sigue contabilizando en la versión que nombró. Mira Definir un producto de préstamo.
Dos caminos quedan fuera de esta puerta a propósito:
- El carril del consignado, que registra un contrato que los sistemas del propio cliente ya inscribieron en la nómina. Rechazar un hecho que ya ocurrió dejaría al libro negando un contrato que el prestatario tiene en la mano.
- Una renegociación sustancial, cuyo contrato de reemplazo hereda la versión de producto del contrato al que reemplaza. El contrato de reemplazo hereda esa versión esté ese producto activo o no y sea esa versión la vigente o no. Renegociar es servicing de crédito ya escrito. Solo una solicitud nueva es crédito nuevo.
Lo que obtienes
El desembolso produce una cuenta de préstamo, la vista de administración del contrato vivo, que lleva su cronograma, sus transacciones, sus cargos y su historial de auditoría. Continúa en Administrar un préstamo.
Lo que ocurre downstream
El ciclo de vida emite
loan_application.submitted, loan_application.approved, loan_application.rejected, loan_application.withdrawn y loan_application.disbursed, cada uno en la versión de esquema 2.0.0. El desembolso registra una intención de asiento durable y la transmite al ledger solo cuando configuras el relay del ledger. Consulta la ruta de asiento.
La originación brasileña agrega pasos regulados (divulgación de CET y consentimiento de capitalización) que cubre el Paquete regulatorio de Brasil. El flujo de consignado con descuento en nómina forma su propio contexto delimitado brasileño. Consulta Consignado privado.
Próximos pasos
Administrar un préstamo
Registra pagos, anticipa, reprograma y corrige una cuenta de préstamo activa.