Antes de empezar
- Necesitas un token bearer de Lender (un JWT que emite tu Access Manager). Cada operación está autenticada y tiene ámbito de tenant.
- Decide a qué jurisdicción pertenece el producto. El crédito se registra bajo la jurisdicción de Brasil. La base genérica,
XX, no registra crédito. Los productos brasileños llevan campos extra que cubre el Paquete regulatorio de Brasil.
Pasos
1
Crea el producto
POST /api/v1/loan-products registra el producto con nombre. Esta es la entrada de catálogo de la que cuelgan las versiones. El cuerpo lleva el nombre, el tipo de préstamo y el código de jurisdicción, y nada más: un cuerpo con un campo que la operación no declara responde 422. Brasil tiene un alias, POST /api/v1/br/loan-products, que recibe el mismo cuerpo.2
Crea una versión
POST /api/v1/loan-products/{id}/versions congela un conjunto de términos (configuración de tasa, plazo y forma del cronograma) como una versión inmutable. Todo préstamo se remonta a la versión que usó en la originación. Nunca editas una versión, publicas una nueva. Una versión fija lleva su tasa en fixedMonthlyRate, la tasa mensual como cadena decimal. Una versión debe declarar su banda de tasa, en puntos básicos anuales efectivos, y los tipos de prestatario que admite, o no origina nada. Lender convierte una tasa mensual m en (1 + m)^12 - 1 antes de compararla con la banda, y la tasa de una versión fija debe quedar dentro de la banda de la propia versión. Los terms opcionales definen lo que la versión admite: sistemas de amortización (price, sac, american), periodicidades de pago (monthly, fortnightly, weekly), los tipos de regla de pago (interestOnly para gracia o pago único final, fixedAmount para cuota balloon), el conteo de días (monthly_30 por defecto), los montos por los que se puede pedir una solicitud, los frentes de originación, quién emite el instrumento de crédito, si los contratos pueden cederse, si la primera liberación de un contrato directo espera la CCB firmada (releaseRequiresSignedInstrument, desactivado por defecto; consulta Emite la CCB), el modo de pago anticipado, cargos por mora (una versión consignado no admite ninguno, LENDER-0114), límites de principal, plazo y cuotas, y la vigencia de la cotización de liquidación de 1 a 168 horas. Una firstDueDateWindow acota la primera fecha de vencimiento que una solicitud puede elegir. En una versión brasileña, jurisdictionExtensions acepta solo taxRegime, admittedTaxRegimes, capitalizationClauseRequired, consumerProtectionRegime, cdcLateFeeCapPct, cdcDefaultInterestMonthlyPct, normPortfolioClass, normModality y scrModality. Cualquier otra clave responde 422 (LENDER-0115).3
Adjunta cargos
POST /api/v1/loan-product-versions/{id}/charge-templates declara una plantilla de cargo en una versión. Una versión admite como máximo una plantilla origination_fee (LENDER-0241), nunca una reembolsable (LENDER-0243) ni una en otra moneda (LENDER-0244), y una revisión no puede cambiar el chargeType de la plantilla (LENDER-0246). POST /api/v1/loan-products/{id}/charges aplica una plantilla a una cuenta de préstamo. Un cargo fechado después de hoy responde 422 (LENDER-0990). Lender cobra un cargo aplicado en la próxima cuota abierta.4
Vincula un perfil contable
POST /api/v1/loan-products/{id}/accounting-profiles declara cómo el producto contabiliza en el . El perfil lleva las reglas de asiento (qué piernas de partida doble se disparan para cada evento), y cada pierna declara la nature de su cuenta, debit o credit. El plan necesita las diez reglas disbursement, repayment, prepayment, accrual, accrual_withholding, renegotiation_gain, renegotiation_loss, collection_unapplied, collection_reapply y collection_refund, y las cuatro reglas de provisión: provision_constitution y provision_reversal para la provisión adicional, y provision_incurred_constitution y provision_incurred_reversal para la pérdida incurrida. Las dos constituciones deben acreditar dos cuentas de provisión distintas, o Lender rechaza el plan con LENDER-0455. Las dos puertas de plan rechazan un plan sin esas reglas. Una pierna que contabiliza una posición del prestatario define perOperation, y su account pasa a ser un prefijo de hasta 17 letras, dígitos, _ o -. Las demás piernas nombran una cuenta compartida. La pierna de contrapartida de renegotiation_derecognition y renegotiation_recognition, el puente del art. 22, no puede ser por contrato: Lender rechaza ese plan. Un producto cuyas versiones declaran mora o una plantilla de cargo que un operador puede aplicar necesita más piernas y reglas (LENDER-0426, LENDER-0989). Un plan que contabiliza accrual_tax debe llevar también accrual_tax_recovery: sin ella, Lender lista la regla en missingEventTypes y rechaza una reestructuración con pérdida el primer día (LENDER-0459). El perfil nombra la organización y el ledger de Midaz en que contabiliza, y Lender puede buscar o crear el ledger cuando nombras solo la organización. Un perfil no puede nombrar un ledger con validación de rutas de Midaz activada (LENDER-0452), y toda versión de un producto contabiliza en un solo ledger (LENDER-0453). La activación rechaza una versión sin perfil. Un plan almacenado antes de las reglas de provisión todavía carga: GET /api/v1/accounting-profiles lista las reglas que le faltan en missingEventTypes, y lo reemplazas por un plan que las tenga. Consulta Contabilidad y corridas de devengo.5
Activa el producto
POST /api/v1/loan-products/{id}/activate pone el producto en activo y fija la versión que nombras como su versión actual. Hasta la activación, el producto no origina nada. Una versión brasileña también necesita su carteira, normPortfolioClass, antes de activarse. Cada solicitud nombra la versión que usa en la originación, así que los préstamos existentes conservan la versión con la que empezaron.Promueve una versión nueva
La activación fija la primera versión. La promoción fija todas las siguientes. Cambia la versión vigente de un producto que ya está vivo, sin bajar el producto y volver a subirlo.
POST /api/v1/loan-products/{id}/promote nombra la versión a fijar. Brasil tiene un alias, POST /api/v1/br/loan-products/{id}/promote, que se comporta de forma idéntica.
La promoción lleva las mismas dos comprobaciones de alistamiento que lleva la activación: un perfil contable presente y una versión completa para su jurisdicción. Las lleva porque es el mismo acto. Un segundo camino sin ellas sería una manera silenciosa de saltarse el primero.
Archiva un producto
PUT /api/v1/loan-products/{id}/archived archiva un producto o lo restaura, con {"archived": true} o {"archived": false}. Un producto nunca se elimina. Un producto archivado sale de las dos listas de productos, y ?archived=true lista los productos archivados. No origina nada nuevo (LENDER-0225), y activarlo responde 409 con LENDER-0133. Desarchivar restaura el estado que el producto dejó: active en la misma versión fijada, o draft cuando el producto nunca tuvo una. Los contratos ya escritos, su historial y sus tramos posteriores quedan como están. El estado de un producto es draft, active o archived.
Inspeccionar productos
Qué pasa downstream
Crear y activar productos emite
loan_product.created, loan_product_version.created, loan_product.activated, accounting_profile.configured y loan_charge.applied en el backbone de eventos. Archivar y desarchivar un producto emite loan_product.archived y loan_product.unarchived (consulta Lender en la plataforma).
Próximos pasos
Originar un préstamo
Toma un producto activo y origina un préstamo contra él.