Arquitectura de Lender

Lender es un solo servicio. Dentro de él, cinco 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.

​

Cinco 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. Lender no acuña ese identificador. 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, así que ningún dominio nombra un mercado. Todo lo específico de un mercado llega a través de un perfil de jurisdicción, que aporta un conjunto fijo de capacidades:

• 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. Hoy vienen dos: BR para Brasil, y XX, una base genérica sin impuestos y sin topes. 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

---

Cada solicitud pasa por las mismas tres compuertas antes de que corra un handler. Vincula cada tenant a una jurisdicción antes de que envíe tráfico. Lender rechaza una solicitud de un tenant sin vínculo.

​

El dinero sale por el outbox

---

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

1. Un desembolso, un devengo de intereses y una cotización de pago anticipado brasileña liquidada escriben cada uno 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

---

No todo empieza con una solicitud. La ejecución de devengo también corre como un job programado. Cada job permanece apagado hasta que lo habilitas, y tú defines su programación. Consulta Contabilidad y ejecuciones de devengo.

​

Próximos pasos

---