Saltar al contenido principal
Esta página te lleva desde una base de datos vacía hasta un préstamo desembolsado en siete llamadas. Cada llamada envía application/json. Envía cada campo de dinero y de tasa como una cadena decimal, nunca como un número JSON. Completa primero los Requisitos previos. Envía el mismo Bearer token en las siete llamadas. Lender toma al oficial del sujeto del token, y solo ese oficial puede aprobar y desembolsar la solicitud.
Este recorrido registra un préstamo brasileño con el régimen tributario none, que no calcula IOF y mantiene simples los montos del paso 7. Lee el Paquete regulatorio de Brasil para un producto que retiene IOF. Un contrato con descuento en nómina pertenece al contexto delimitado de consignado privado. Lee Consignado privado para su vocabulario y sus temas de ciclo de vida.

Las siete llamadas


1. Crear el producto


POST /api/v1/loan-products
loanType toma personal, commercial o card. jurisdictionCode es BR. Cualquier otro código devuelve 422. La respuesta lleva el nuevo id. El producto está en draft.

2. Crear una versión


POST /api/v1/loan-products/{productId}/versions
La versión es la instantánea inmutable de términos a la que se vincula una solicitud.
  • currency no tiene valor predeterminado. Aporta un código ISO-4217 válido en mayúsculas. La versión es la fuente de verdad de la moneda desde aquí hasta el ledger.
  • rateBand es obligatorio. Es la banda de precio que la versión autoriza, en puntos básicos anuales. Una solicitud cuya tasa queda fuera de ella se rechaza.
  • admittedBorrowerKinds nombra a quién le presta la versión. Una lista vacía u omitida no admite a ningún prestatario.
  • normPortfolioClass es la carteira. Una versión brasileña sin carteira no se puede activar en el paso 4.
  • Una versión fija no lleva vínculo flotante. Con rateMode: fixed, omite floatingRateTableId, floatingSpreadBps y requiresFloatingRate. Lender rechaza una versión fija que lleve alguno de ellos.
  • jurisdictionCode es obligatorio, y debe coincidir con el del producto. Una versión no puede mover un producto a otra jurisdicción.
La respuesta lleva el versionId.

3. Vincular un perfil contable


POST /api/v1/loan-products/{productId}/accounting-profiles El perfil mapea cada evento contable a cuentas contables generales. La activación rechaza un producto sin perfil, así que vincúlalo ahora.
Envía una regla por evento contable. Siete eventos necesitan una regla: disbursement, repayment, prepayment, accrual, collection_unapplied, collection_reapply y collection_refund. Los otros tipos de evento son opcionales. Menos de siete reglas se rechaza antes de que corra el handler. Un producto bajo las reglas brasileñas de pérdida crediticia también necesita provision_constitution y provision_reversal, o su provisión medida no se asienta en el ledger. La activación no las verifica. Cada pata declara exactamente uno de role o component, y ninguna cuenta aparece en ambos lados de la misma regla. Cuatro eventos también llevan una forma de pata fija: collection_reapply toma unapplied_cash como su único débito. Cada crédito que lleva debe aparecer también como crédito en repayment o prepayment, con la misma cuenta y el mismo rol. disbursement y repayment necesitan cada uno al menos un débito y un crédito. Mantén la regla disbursement en dos patas, como arriba. Lender llena la pata cash con el monto neto y cada otra pata estructural con el monto bruto. Una pata component toma una retención calculada, y el régimen tributario none no calcula ninguna, así que la regla de dos patas es la que balancea en este recorrido. Lee Definir un producto de préstamo para la superficie de producto más amplia.

4. Activar el producto


POST /api/v1/loan-products/{productId}/activate
La activación fija la versión en la que se originan las nuevas solicitudes. Rechaza un producto que no tiene perfil contable, y una versión brasileña que no tiene carteira. Una solicitud sobre un producto que no está activo se rechaza.

5. Crear la solicitud


POST /api/v1/loan-applications Envía el header X-Idempotency. Lender lo requiere en esta llamada y en los pasos 6 y 7. Un reintento con el mismo valor repite la primera respuesta y no escribe nada nuevo.
  • borrowerId es un UUID. borrowerKind toma pessoaFisica o pessoaJuridica, y la versión debe admitirlo.
  • requestedInterestRate es la tasa mensual como cadena decimal a escala 8. Debe ser mayor que 0 y no mayor que 1. Lender construye el cronograma a partir de esta tasa y la compara con la banda de tasa de la versión en puntos básicos anuales: "0.01500000" al mes son 1800 bps al año, dentro de la banda del paso 2.
  • requestedInstallments está entre 1 y 600.
  • previewScheduleSnapshotId es opcional. Para citar la cotización que le mostraste al prestatario, envía el scheduleOfferSnapshotId que devolvió POST /api/v1/loan-applications/preview-schedule.
  • No hay campo assignedOfficerId. Lender lo define desde el sujeto del token.
La solicitud vuelve en pending_approval, con el código de jurisdicción y la versión de perfil que Lender resolvió desde la versión de producto.

6. Aprobar


POST /api/v1/loan-applications/{id}/approve
approvedAmount se vuelve el techo de todo lo que desembolsas. La solicitud pasa a approved y lleva el registro de decisión.

7. Desembolsar


POST /api/v1/loan-applications/{id}/disburse
Con el régimen tributario none, netDeliveredAmount debe ser igual a grossRequestedAmount. Lender acepta un desembolso solo cuando el neto es igual al bruto menos las retenciones, menos la comisión de originación retenida. Este régimen no calcula retenciones, y este recorrido no retiene comisión.
loanAccountId es un UUID que aportas tú. Lender no lo acuña. Identifica la cuenta de préstamo bajo la que se administra este contrato, y es inmutable a lo largo de tramos posteriores de la misma solicitud. jurisdictionExtensions lleva lo que lee el pipeline brasileño: el instante del desembolso, la versión del paso 2 y el valor de X-Idempotency de esta llamada como requestId. El desembolso falla cuando falta uno. Lender también verifica que:
  • netDeliveredAmount no exceda grossRequestedAmount.
  • grossRequestedAmount sea igual a approvedAmount, porque este es el único desembolso de la solicitud. Una liberación en tramos declara trancheNumber, y su total acumulado no excede approvedAmount.
  • decisionAt y disbursedAt no sean anteriores a la creación de la solicitud, y disbursedAt no sea anterior a la decisión de aprobación.
  • La jurisdicción y la versión de perfil todavía coincidan con el par que Lender resolvió en el paso 5.

Confirmar que el préstamo existe


La respuesta del desembolso lleva la solicitud en disbursed con su evento de desembolso. Luego lee la cuenta de préstamo: La respuesta también lleva profileVersion, la versión del perfil de jurisdicción, no una versión de producto. No lleva moneda. El préstamo usa el currency que definiste en la versión de producto de préstamo en el paso 2. Si configuraste el relay del ledger de Midaz, el asiento de desembolso llega al ledger cuando el despachador del outbox transmite la intención. Eso pasa poco después de la llamada, no dentro de ella. En caso contrario, la intención permanece en el outbox.

Próximos pasos


Administrar un préstamo

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

Cómo funciona el devengo

El reconocimiento de intereses corre con su propia programación. Inicia una ejecución de devengo, o habilita el heartbeat.