Soluciones · Servicios financieros
Una aplicación para servicios financieros se juzga por lo que ocurre en sus bordes: qué se escribe en el registro, qué ocurre cuando el cliente solicita de vuelta sus datos, qué se ve en la información precontractual y qué ocurre cuando una tarea programada no se ejecuta. Construimos la mecánica; la política de crédito sigue siendo tuya.
Ya construidoUna plataforma de crédito en producción, verificable externamente hoy: la parte pública es una aplicación compilada de forma estática con 50 pantallas, entre ellas cuatro calculadoras — crédito, elegibilidad, refinanciación, calendario de pagos — páginas por tipo de crédito, información precontractual y una ruta por la que el cliente solicita sus datos personales; la parte de negocio es un backend modular en TypeScript con 16 módulos y 18 tablas en el esquema de datos, entre ellas contrato, pago, registro de auditoría, solicitud relativa a los datos personales, documento cargado, instantánea diaria de indicadores y ejecución de tarea programada. El mapa del sitio de producción enumera 227 direcciones, y las rutas rumanas y las rusas responden ambas — verificadas por mí el 06.09.2026. La reserva que decimos: la prueba procede del código y de las respuestas públicas, no del comportamiento interno del servidor — no hemos verificado en qué versión se ejecuta producción ni que los 16 módulos estén activos en vivo.
Una empresa de crédito no necesita un sitio web. Necesita una cadena completa: la solicitud entra online, pasa por un flujo de decisión, genera un contrato, produce un calendario de pagos y deja rastro en auditoría. Cada eslabón que falta en la cadena se convierte en una persona que copia datos de un lugar a otro, y en servicios financieros cada copia manual es también un problema de cumplimiento, no solo de tiempo.
La estructura que construimos refleja esto directamente en los datos. En la plataforma que citamos, el esquema tiene 18 tablas, y su lista dice más que cualquier descripción de arquitectura: solicitud, contrato, pago, código de un solo uso, sesión, solicitud de llamada, plantilla de notificación, registro de notificaciones, instantánea diaria de indicadores, ejecución de tarea programada, artículo, redirección de dirección, ajuste de visibilidad, nota interna, registro de auditoría, documento cargado, solicitud sobre datos personales. El backend está dividido en 16 módulos, entre ellos uno dedicado exclusivamente a los derechos del interesado.
La parte pública no es decorado: cuatro calculadoras — préstamo, elegibilidad, refinanciación y calendario de pagos — más páginas separadas por tipo de préstamo y la información precontractual. En el crédito al consumo, la información precontractual no es una página de imagen: es la obligación de mostrar las condiciones antes de que la persona se comprometa. La tratamos como un requisito del producto, no como un texto legal pegado al final. Las rutas en rumano permanecen sin prefijo, y las rusas van por un segmento propio, con etiquetas canónicas y alternativas generadas a partir del idioma de la ruta activa.
Y el límite que hay que decir antes del contrato: el flujo de decisión sobre las solicitudes — las reglas, los umbrales, la aprobación — es tuyo. Nosotros construimos la mecánica por la que la solicitud circula, se documenta y se convierte en contrato. No escribimos la política de crédito y no asumimos la evaluación de un solicitante; son decisiones con consecuencias jurídicas que pertenecen a la institución autorizada.
Qué incluye
La solicitud entra online y vive como una entidad propia, con estado visible y con una pantalla de seguimiento para el cliente. Los documentos cargados tienen su propia tabla, el contrato tiene la suya, el pago la suya. La diferencia con un formulario que envía un correo electrónico es que, dentro de tres meses, se puede responder desde los datos a la pregunta «qué pasó con la solicitud del 12 de marzo».
El contrato y el calendario no se componen manualmente en un documento aparte: salen de los datos de la solicitud aprobada. Es la única variante en la que la cifra del contrato y la cifra del calendario no pueden diferir, y el cliente que llama con el documento en la mano habla de lo mismo que el operador que mira el sistema.
Préstamo, elegibilidad, refinanciación y calendario de pagos — pantallas separadas, públicas, sin autenticación. En el crédito al consumo, la calculadora es la primera interacción real: la persona quiere ver la cuota antes de hablar con alguien. Y la refinanciación es una calculadora distinta de la del préstamo, no la misma con otras etiquetas.
Página propia, no un párrafo en el pie de página. El motivo es práctico: si la información no está en el recorrido que sigue la persona antes de firmar, no cumple su función ni para ella ni para la institución. El texto es tuyo y de tus juristas; nosotros construimos el lugar, el momento y la trazabilidad.
Existe una página pública mediante la cual el cliente solicita sus datos personales, un módulo de backend dedicado y una pantalla de administración para las solicitudes recibidas, además de una tabla en la que viven. La consecuencia práctica: el plazo legal de respuesta puede cumplirse sin que nadie abra la base de datos manualmente — y se puede demostrar, dentro de un año, que se cumplió.
El registro de auditoría es una tabla propia, distinta de las notas internas de los operadores. La separación importa en una verificación: una es el registro técnico de lo que ocurrió, la otra es lo que escribió un compañero sobre un dossier. Mezcladas, la primera se vuelve ilegible y la segunda se vuelve documento.
Existe una tabla para las ejecuciones de las tareas programadas y otra para los instantáneos diarios de indicadores. En una plataforma financiera, una tarea que no ha corrido tres noches seguidas es un problema más grave que una página caída: no se ve desde fuera, pero mueve las cifras. Por eso la ejecución se escribe, no se presume.
Las rutas en rumano se mantienen sin prefijo, las rusas van por un segmento propio, con etiquetas canónicas y alternativas generadas a partir del idioma de la ruta activa. En el mapa del sitio de producción hay 227 direcciones. Para una empresa de crédito de la República de Moldavia, la parte rusa no es una traducción de cortesía — es la mitad de los solicitantes.
Verificaciones previas a la publicación, migraciones de base de datos ejecutadas con comando separado en producción, generación de secretos, copia de seguridad y restauración de la base — todo como scripts en el repositorio, no como pasos de un documento. En un sistema que gestiona contratos y pagos, «restauración» debe ser un comando que has probado, no una intención.
Traseul
Qué significa una solicitud presentada, una solicitud aprobada, un pago cobrado; qué ocurre con una solicitud a la que no se respondió; qué se cierra cuando un servicio externo no responde. Entregamos el documento de vocabulario e invariantes, porque en una plataforma financiera un término usado en dos sentidos se convierte, más tarde, en dos cifras distintas en dos informes.
El registro de auditoría y la evidencia de documentos no se añaden al final; forman parte de la primera versión que funciona. Entregamos el flujo completo desde la solicitud hasta el contrato, con su rastro, sobre datos de prueba — no pantallas que se ven bien sobre una base vacía.
Las pantallas públicas, las calculadoras, las páginas por tipo de crédito y la información precontractual, con las direcciones en rumano sin prefijo y las rusas en su propio segmento, con etiquetas canónicas correctas. Entregamos el mapa del sitio generado a partir de datos y la verificación de que ambas versiones responden.
Verificación previa a la publicación, migraciones en producción con comando separado, generación de secretos, copia de seguridad y restauración — probadas, no solo escritas. Entregamos el repositorio, el documento de puesta en funcionamiento y los accesos. La restauración de la base se demuestra en la entrega, una vez, delante de vosotros.
Los datos
Las reglas difieren de una industria a otra. Estas son las que se aplican en servicios financieros.
Un caso
La situación
El requisito inicial en un proyecto de crédito suena casi siempre igual: «un sitio web con formulario de solicitud». El problema aparece en el segundo mes, cuando alguien pregunta dónde está el contrato, quién modificó el dossier y cómo respondemos a una solicitud de acceso a datos personales dentro del plazo legal.
Qué construimos
Construimos la plataforma en dos mitades, en el mismo depósito. La parte pública es una aplicación compilada de forma estática, con 50 pantallas: cuatro calculadoras — crédito, elegibilidad, refinanciación, gráfico de pagos — páginas por tipo de crédito, información precontractual, seguimiento del estado de la solicitud y una página por la que el cliente pide sus datos personales. La parte de negocio es un backend modular en TypeScript, con 16 módulos — entre ellos autenticación, derechos por rol, flujo de solicitudes, documentos, pagos, notificaciones, tareas programadas y uno dedicado a los derechos de la persona afectada — sobre un esquema con 18 tablas: solicitud, contrato, pago, código de un solo uso, sesión, documento subido, registro de auditoría, solicitud sobre datos personales, ejecución de tarea programada, instantánea diaria de indicadores y el resto.
Qué salió
La cadena es completa: la solicitud entra, circula, produce contrato y gráfico, y cada paso deja rastro. Las solicitudes sobre datos personales tienen su propio recorrido, con pantalla de administración, así que el plazo legal se puede cumplir y demostrar. La parte pública es verificable desde fuera: 227 direcciones en el mapa del sitio, con ambas versiones de idioma activas.
Qué no dice el caso
La prueba viene del código y de las respuestas públicas, no del comportamiento interno del servidor: no hemos verificado en qué versión corre producción ni que los 16 módulos estén activos en live. El flujo de decisión sobre las solicitudes — reglas, umbrales, aprobación — pertenece al cliente; nosotros construimos la mecánica, no la política de crédito.
Preguntas
Vosotros. Las reglas, los umbrales y la aprobación son la política de la institución autorizada, no del proveedor de software. Nosotros construimos la mecánica por la que la solicitud circula, se documenta, se convierte en contrato y gráfico de pagos, y deja rastro. Un proveedor que asume la decisión de crédito vende algo que no tiene derecho a vender.
Hay una página pública por la que lo pide, un módulo de backend dedicado, una pantalla de administración y una tabla en la que vive la solicitud. Así se puede responder a tiempo y se puede demostrar después. Lo que no es una decisión técnica: qué se puede borrar y qué debe conservarse conforme a la legislación financiera — eso se establece con vuestros juristas, antes de la implementación.
A partir de los datos de la solicitud aprobada, junto con el calendario de pagos — ambos de la misma fuente, para que no puedan diferir. Lo que queda de vuestra parte es el contenido del contrato y sus condiciones. Un contrato compuesto manualmente en un documento aparte es el lugar clásico donde aparecen dos cifras diferentes para el mismo préstamo.
Porque en el crédito al consumo la información debe estar en el recorrido que sigue la persona antes de comprometerse, no en un pie de página. La tratamos como parte del producto: el lugar, el momento y la trazabilidad son nuestros, el texto es de vuestros juristas.
Al menos las que correspondan a decisiones diferentes. En la plataforma que citamos son cuatro — crédito, elegibilidad, refinanciación, calendario de pagos — porque la refinanciación no es el mismo cálculo que un crédito nuevo, y el calendario responde a otra pregunta que la cuota. Una sola calculadora con muchos campos es más difícil de usar que cuatro simples.
No, y es una regla, no una preferencia: construimos y probamos con datos de prueba. El acceso a datos reales, cuando es necesario, se hace con personas designadas, durante un periodo establecido y con rastro en el registro. En un sistema financiero, «tuve que mirar en producción» es una frase que debe aparecer en un registro, no en una conversación.
Se ve, porque las ejecuciones se registran en una tabla propia, junto con las instantáneas diarias de indicadores. Es importante precisamente porque una tarea que no se ejecutó no produce ningún síntoma visible desde fuera — el sitio responde, las pantallas se ven bien, pero las cifras ya no se mueven.
Ninguna cifra de volumen, de interés, de número de solicitudes o de clientes, aunque se muestre públicamente en su sitio — porque es su afirmación, no nuestra medición. Lo que podemos mostrar es la estructura: cuántos módulos, qué tablas, qué pantallas públicas, qué se verifica al publicar. La misma regla se aplicará también a vuestro trabajo.
La parte pública se puede verificar ahora: el mapa del sitio tiene 227 direcciones, y las versiones rumana y rusa de una calculadora responden ambas. La parte de backend se lee del código — módulos y esquema de datos — no del comportamiento del servidor: no hemos verificado en qué versión funciona producción ni que todos los módulos estén activos en vivo, y preferimos escribirlo antes que dejar la impresión contraria.
Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.