Arquitectura de Lender

Lender es un solo servicio. Dentro de él, ocho dominios son dueños del recorrido de crédito, un perfil de jurisdicción aporta cada regla específica del mercado y el dinero llega al ledger por una cola durable en lugar de una llamada en línea.

​

Ocho dominios, un servicio

---

Cada dominio es dueño de sus propias tablas y de sus propias operaciones. El identificador de cuenta de préstamo es la clave que los une. Lo aportas cuando desembolsas, y desde entonces cada dominio identifica el préstamo con él.

​

La unión de jurisdicción

---

Las reglas de crédito cambian según el mercado. Un perfil de jurisdicción aporta capacidades específicas de un mercado, entre ellas:

• El motor de impuestos que calcula las retenciones en el desembolso y los impuestos sobre ingresos en el devengo.
• El calendario de feriados y la convención de conteo de días.
• El método de costo efectivo detrás de la divulgación de costo.
• El registro de topes que guarda los límites regulados de tasa y de comisión.
• Las divulgaciones que exige el mercado.
• El pipeline de desembolso que corre dentro de la transacción de desembolso.
• El validador de producto y la extensión de vista previa del cronograma.
• Las políticas de actor que deciden quién puede aprobar y quién puede desembolsar.

Los perfiles se compilan dentro del servicio en lugar de configurarse en tiempo de ejecución. Vienen dos: BR para Brasil, y XX, la base genérica, que no registra crédito. La tabla de jurisdicciones en la base de datos es una proyección de lo que lleva el servicio, así que ninguna llamada de API crea una jurisdicción. Consulta Jurisdicciones.

​

Cómo se resuelve una solicitud

---

Una solicitud pasa por hasta tres compuertas antes de que corra un handler. Vincula cada tenant a una jurisdicción antes de que envíe tráfico.

​

El dinero sale por el outbox

---

Lender nunca asienta en el ledger durante tu solicitud. La ruta tiene cuatro propiedades:

1. Un evento de dinero, como un desembolso, un pago o un devengo de intereses, escribe una intención de asiento en la misma transacción de base de datos que la fila de negocio. Una caída entre las dos no es posible.
2. Un despachador lee la intención del outbox y la transmite a Midaz.
3. Cada intención lleva una clave de idempotencia determinista, así un relay reintentado colapsa en una sola transacción de ledger.
4. El enrutamiento falla en modo cerrado. Un asiento se contabiliza en la organización y el ledger que resuelve el perfil contable, y un despliegue single-tenant puede recurrir a su valor predeterminado configurado. Cuando no se resuelve ningún destino, Lender no asienta nada.

Configura el endpoint del ledger y sus credenciales antes de esperar contabilizaciones. Hasta que se resuelvan, las intenciones esperan en el outbox y nada llega al ledger. Lender en la plataforma cubre la ruta completa, incluido lo que el perfil contable aporta a ella.

​

Lo que expone el servicio

---

Lee la referencia de health y readiness para el contrato de sondas que comparten los productos Lerian.

​

Almacenes

---

Configuración y despliegue lista los ajustes detrás de cada uno.

​

Trabajo dirigido por el tiempo

---

La ejecución de devengo también corre como un job programado. Cada job tiene su propio valor predeterminado de encendido o apagado y su propia programación, y puedes sobrescribir ambos. Consulta Contabilidad y ejecuciones de devengo.

​

Próximos pasos

---