Preguntas frecuentes

En dónde ponemos el foco. Casi todos los sistemas del rubro compiten por automatizar lo que ya tiene API: informes comerciales, firma electrónica, recaudación. Eso lo hacemos también, y no es donde se pierde el tiempo.

La mitad del calendario de un crédito hipotecario la manejan contrapartes que no tienen API: notaría, conservador de bienes raíces, banco alzante, tasador, estudio de títulos. Nadie las va a automatizar. Lo que sí se puede es hacerlas visibles: la bandeja dice qué detiene cada negocio, quién es la contraparte responsable y hace cuántos días está parado.

Mutuarias hipotecarias, bancos, administradoras y gestoras de fondos, y otros originadores de crédito —factoring, leasing, activos alternativos— que necesitan administrar el ciclo completo: originación, curse, cartera y cobranza.

El producto nació sobre mutuos hipotecarios endosables, que es el caso más exigente en cantidad de contrapartes y documentos. Los procesos más simples caben dentro.

Infatria es parte del grupo Credibid, fintech B2B chilena inscrita ante la CMF, y del grupo Numa.

En la práctica eso significa que los productos de Credibid —consultas por RUT, monitoreo de deudores, reporting al regulador— se integran como parte del sistema, no como un extra que hay que conectar después.

El ciclo completo del crédito en un solo sistema: desde que entra el negocio hasta que termina de pagarse, con el expediente como centro y la bitácora de todo lo que pasó.

Más una capa transversal de reportería, analítica y trazabilidad — y nIA. Y tres superficies: backoffice para el operador, portal web y app móvil para el cliente.

El alcance exacto y los módulos activos se definen con cada institución. El detalle pantalla por pantalla lo mostramos en la demostración, no en el sitio.

Sí. Los módulos se activan por licencia y cada institución contrata los que necesita. Un módulo que no se contrató no aparece: no sale en gris, ni con candado, ni con un aviso de venta. Quien no compró cartera no tiene por qué enterarse de que existe.

Lo que sí valida el sistema es la coherencia: un conjunto incoherente —cobranza activa con cartera apagada— no arranca, y dice exactamente qué falta.

Sí, y esa es una decisión de arquitectura, no un favor comercial: las reglas propias de cada institución van en configuración, no en código. Por eso una actualización del producto no rompe lo que se personalizó, y no hay un paquete distinto por cliente que después haya que mantener aparte.

Si una regla realmente no cabe en la configuración, entra por la vía de desarrollo a medida y queda documentada como tal.

Sí. Las pantallas que se ven en este sitio son el look and feel: el diseño, la estructura y el comportamiento. La marca es de la institución.

En el backoffice va el logotipo de la institución en el riel. En el portal web y en la app móvil van su nombre y su logo corporativo: el deudor entra a la marca de su mutuaria o de su banco, no a la nuestra. La app se publica como una instalación dedicada de la institución.

Es un módulo propio, con su pantalla completa dentro del backoffice. Tiene el riel de conversaciones anteriores —cada una con su fecha y su cantidad de mensajes— y se retoman donde se dejaron.

Además ofrece las preguntas frecuentes del área a un clic, así que nadie tiene que aprenderse una sintaxis. Y sigue estando a mano como botón flotante en cada pantalla, para quien no quiere salir de donde está trabajando.

Sí. El deudor entra con su RUT al portal web o a la app móvil y ve lo mismo que la institución tiene registrado: deuda según plan, próxima cuota, plan de pagos año por año, créditos en trámite y sus documentos para descargar.

Es la forma más barata de bajar el volumen de llamadas al ejecutivo: la respuesta ya está publicada.

Hoy la API es interna: la usan el propio backoffice y el portal. No publicamos una API para terceros, y preferimos decirlo antes que prometerla.

Cuando exista, será un producto aparte, con su propia capa de contrato y su compromiso de compatibilidad — no la interna expuesta, que es la forma más rápida de quedar atrapado en una versión.

Como prefiera la institución, y el producto es exactamente el mismo en los dos casos.

En tu infraestructura: el sistema corre dentro del perímetro de la institución, junto a los sistemas que ya tiene. La base de datos la provee el cliente, con su motor y sus políticas de respaldo, y su equipo de TI la administra.

Operada por Infatria: nos hacemos cargo completo — servidores, respaldos, monitoreo, seguridad y actualizaciones. La institución no compra hardware, no levanta ambientes y no necesita un equipo de TI para sostener el core: se dedica a hacer negocio y nosotros a que el sistema esté arriba. La información de cada institución queda separada y sellada.

La topología se elige al arrancar el sistema y no cambia cómo funciona por dentro: ninguna funcionalidad se comporta distinto según dónde esté instalada. Tampoco es una decisión para siempre — se puede empezar operado por nosotros y migrar después.

Si eliges la modalidad operada por Infatria, no. Servidores, respaldos, monitoreo, parches de seguridad y actualizaciones corren por nuestra cuenta. Lo que la institución necesita es gente que entienda su negocio de crédito, que es la que va a usar el sistema.

Si el sistema corre en tu infraestructura, sí hace falta quien administre los servidores y la base — normalmente el mismo equipo que ya opera el resto de los sistemas de la institución.

La institución, en las dos modalidades. Cuando corre en tu infraestructura la base la provees tú, con tu motor y tus políticas de respaldo; cuando la operamos nosotros, la información sigue siendo tuya y se entrega cuando la pidas.

La base queda sellada con la institución a la que pertenece. Si el sello no coincide, el sistema no opera. Es deliberado: protege contra dos errores silenciosos —un enrutado equivocado cuando operamos varias instituciones, y restaurar el respaldo de otra institución sobre esta base.

Sí. La autenticación se federa con el proveedor de identidad de la institución (Active Directory / LDAP), de modo que el alta y la baja de una persona siguen ocurriendo donde la institución ya las administra.

Los permisos se resuelven por área y por rol: cada usuario ve las secciones que le corresponden y ninguna otra.

No nos preparamos: el producto se diseñó sabiendo que la Ley 21.719 de Protección de Datos Personales entra en plena vigencia en diciembre de 2026. Sus exigencias están en los cimientos, no en una capa agregada después.

En concreto: base de licitud para tratar cada dato, minimización y retención acotada —se guarda lo que hace falta, el tiempo que corresponde—, traza de cada acceso a dato personal en una bitácora inmutable y consultable, y la capacidad de atender los derechos del titular (acceso, rectificación, cancelación y oposición) dentro del plazo legal.

Y cuando operamos nosotros la infraestructura, cada institución tiene su propia base de datos. No hay filas compartidas con una columna que separe a dos competidoras.

Dicho simple: nace cumpliendo, no se adapta después — y la institución se ocupa de lo suyo: el tratamiento de los datos de sus clientes y las decisiones de su negocio.

Cada negocio lleva su expediente con su bitácora: qué se hizo, quién lo hizo y cuándo. Las decisiones de riesgo quedan registradas con su fundamento, y la cobranza con su historia completa.

Es lo que se necesita cuando llega la auditoría interna, el fiscalizador o una reclamación del cliente — y es la razón por la que la bitácora no es opcional.

nIA es el agente que acompaña la plataforma. Está en cada pantalla, con la cara que corresponde a la situación: cuando algo se traba, cuando un negocio avanza, cuando una página no existe.

Responde preguntas sobre lo que está pasando en tu cartera —«¿dónde está trabada la cartera?», «¿qué está vencido hoy?», «¿quién detiene más negocios?»— con los datos reales de la institución, no con respuestas genéricas.

No. nIA muestra, explica y acompaña; la decisión de crédito la toman las personas y los comités de la institución, con la política que la institución configuró. Lo que hace nIA es que nadie tenga que buscar el dato en tres pantallas antes de decidir.

El alcance de nIA y el tratamiento de los datos se definen en la implementación, según la modalidad contratada y las políticas de la institución. Es uno de los puntos que revisamos explícitamente en el levantamiento, y queda por escrito antes de encender nada.

Se migra. Traemos la historia acumulada del sistema anterior —clientes, créditos, plan de pagos, documentos— conciliada contra el origen, no volcada a ciegas. La migración se valida con la institución antes de cortar.

Cuando hay información que no tiene equivalente en el modelo nuevo, se dice y se decide qué hacer con ella; no se inventa un campo para que calce.

Con el ERP contable de la institución —dentro de su propia red, sin salir a internet—, con el proveedor de firma electrónica, con la recaudación, con los informes comerciales y score, con la plataforma de comunicación con el cliente, y con los productos de Credibid para consultas por RUT y reporting al regulador.

Los proveedores los contrata la institución. Infatria integra técnicamente.

Depende de tres cosas: cuántos módulos se activan, cuántas integraciones hay que levantar y en qué estado está la información que se migra. El levantamiento inicial es corto y de ahí sale un plan con fechas, no una estimación al aire.

Si prefieres partir por una pieza —solo originación, o solo cartera— también es un camino válido y suele ser el más rápido de poner en producción.

Soporte con el mismo equipo que construyó el producto — no hay una mesa de ayuda que escala hacia una fábrica que no conoces.

Cada versión llega con notas de versión escritas para que el área de TI de la institución pueda leerlas y decidir si actualiza. Lo que rompe compatibilidad va marcado como tal; no aparece de sorpresa.

Sí, y es lo que recomendamos. Mostramos la plataforma sobre datos de demostración, entrando con los usuarios de cada equipo, para que veas el mismo negocio desde todos los puestos que lo tocan.

Agendar una demostración