Software para fintech

// El problema

Un prestamista recibe las solicitudes por un formulario web y por correo, así que la comprobación de identidad, los datos bancarios y los documentos se persiguen a mano y muchos solicitantes no terminan nunca.

// Lo que construiríamos

Una aplicación iOS y Android con su portal web equivalente que verifica la identidad, vincula la cuenta bancaria, recoge los documentos y muestra al solicitante en qué punto está su expediente, con un back office para el equipo de riesgos.

// Qué incluye

// Tecnologías

• Next.js
• React Native
• PostgreSQL
• Flinks o Plaid para los datos bancarios
• API de verificación de identidad
• AWS Canada

// El problema

El volumen de soporte sube con cada campaña de marketing, y la mayoría de los tickets preguntan cosas que el centro de ayuda público ya responde.

// Lo que construiríamos

Un agente de soporte sobre un modelo de vanguardia que responde a partir del centro de ayuda publicado y pasa a una persona todo lo que tenga que ver con una cuenta concreta. Se elige porque el material de origen es público y es el camino más rápido para ponerlo en marcha.

// Qué incluye

// Tecnologías

• API de un modelo de vanguardia
• PostgreSQL con pgvector
• Next.js
• Integración con Zendesk o Intercom
• DigitalOcean

// El problema

Los analistas vuelven a teclear las cifras de ingresos y gastos de los extractos bancarios y las nóminas, lo que es lento y mete errores de tecleo en las decisiones de crédito.

// Lo que construiríamos

Un agente sobre un modelo de código abierto, servido en su propia cuenta de AWS en Canadá para que los documentos financieros no lleguen nunca a un tercero, que lee cada documento, extrae las cifras y muestra al analista cada valor junto a la línea de donde sale.

// Qué incluye

// Tecnologías

• Qwen o Llama (código abierto)
• vLLM
• Python
• PostgreSQL
• Next.js
• AWS Canada

// El problema

Una empresa de pagos y sus entidades socias llevan cada una su propio registro de transferencias y liquidaciones, y el cierre de mes es una discusión sobre qué registro es el bueno.

// Lo que construiríamos

Un libro privado con permisos donde cada parte tiene un nodo y cada transferencia y cada liquidación se escriben una vez y las leen todas, con una consola web para el personal de operaciones. Si todas confían en que una parte lleve el registro, una base de datos compartida es más barata y se lo diremos.

// Qué incluye

// Tecnologías

• Hyperledger Besu (privada, con permisos)
• Next.js
• PostgreSQL
• Kafka
• AWS

// El problema

Las firmas de asesoramiento y las aplicaciones socias quieren datos de cuentas y de carteras, y hoy los reciben en ficheros nocturnos o extrayéndolos de las pantallas.

// Lo que construiríamos

Una API para socios con consentimiento OAuth 2.0, para que cada cliente elija qué puede ver una aplicación, y TLS mutuo entre sus servidores y los de cada firma. Se construye con un objetivo de disponibilidad del 99,95%, y sus versiones se retiran según un calendario que usted publica.

// Qué incluye

// Tecnologías

• OpenAPI 3.1
• OAuth 2.0 y OpenID Connect
• TypeScript sobre Node.js
• PostgreSQL
• AWS en Canadá

// El problema

La plataforma de un prestamista funciona en servidores configurados a mano hace años, los despliegues se hacen de madrugada cruzando los dedos y los cuestionarios de seguridad de sus socios cuestan más cada año.

// Lo que construiríamos

Un traslado a nube gestionada en regiones de Canadá, configurada como código, con almacenamiento cifrado, copias probadas, despliegues por etapas, registros de acceso que sus auditores pueden leer y un plan mensual en el que la operamos, la actualizamos y le informamos.

// Qué incluye

// Tecnologías

• Terraform
• AWS Canada
• PostgreSQL
• Grafana
• GitHub Actions