Dónde empieza realmente un proyecto fintech
Una aplicación fintech suele describirse por sus funciones: cuenta, pago, panel, aprobación o informe. El trabajo técnico empieza por el significado de cada estado. ¿Cuándo se ha aceptado una solicitud, cuándo se ha enviado a un socio y cuándo se puede afirmar que la operación terminó? ¿Qué sistema confirma ese estado y qué puede ver el usuario final? Sin respuestas claras, una interfaz elegante puede limitarse a ocultar incertidumbre.
La primera etapa dibuja el proceso desde la solicitud hasta el resultado final, incluidos rechazo, espera y corrección manual. Registra roles, fuentes de datos, servicios externos, motivos de cambio de estado y decisiones humanas. También fija límites: mercado, tipo de producto, volumen previsto, disponibilidad de socios y sensibilidad de los datos. Solo entonces puede decidirse qué desarrollar, qué aprovechar de servicios existentes y qué debe verificar el cliente mediante revisión jurídica o contractual.
Fuente de verdad e historial de cambios
Un mismo dato puede aparecer en un portal de clientes, un sistema interno, un registro contable y un proveedor externo. Esas copias no tienen la misma autoridad. Cada campo importante necesita una fuente principal, una regla de sincronización y un procedimiento ante discrepancias. Si un dato se corrige, debe ser posible saber quién lo cambió, cuándo, por qué y cómo llegó la corrección a los demás sistemas. Es una cuestión de modelo de datos, no solo de registros técnicos.
El historial debe ayudar a investigar una reclamación o un incidente. No conviene copiar información sensible en todos los registros sin criterio. Los eventos necesitan nombres con significado, un identificador de correlación estable y separación entre detalle técnico interno y explicación para el cliente. Retención y permisos se definen al diseñar. Una pista de auditoría que nadie puede interpretar no ayuda ni al usuario ni al equipo que investiga un problema.
Resultados desconocidos y solicitudes repetidas
Una llamada de red puede agotar el tiempo aunque la otra parte haya completado la operación. La aplicación no debe tratar automáticamente cada espera como un fracaso ni repetir la acción sin comprobar. Necesita un estado de resultado en verificación, un identificador de operación y una forma de conocer el desenlace real. Clics repetidos, entrega duplicada de mensajes y reintentos tras una caída son comportamientos normales que hay que diseñar, no pruebas opcionales poco frecuentes.
La idempotencia es más que una opción del endpoint. Hay que definir qué constituye la misma operación comercial, cuánto tiempo se conserva su identificador y qué ocurre si otra solicitud cambia los datos. Una compensación o reparación manual debe respetar el estado real de ambos lados de la integración. Antes de lanzar, sirve una tabla de estados, transiciones permitidas y comportamiento esperado ante cada fallo. Sin ella, el sistema puede superar una prueba de pago exitoso y fallar en la excepción más importante.
Integraciones y contratos de datos
Un producto financiero puede conectar identidad, pagos, informes, soporte y aprobaciones internas. Cada interfaz cambia a su ritmo y tiene límites y fallos propios. El contrato debe describir formato, significado de campos, versiones, marcas de tiempo, reglas de reintento y responsabilidad por los cambios. Los eventos necesitan reglas de orden y duplicados; las API síncronas, expectativas de latencia y comportamiento durante una caída. El diseño también debe ser comprensible para quien responde por el proceso.
Un piloto debería probar la conexión más arriesgada en un entorno real del socio cuando sea posible. La documentación de ejemplo quizá no refleje límites, datos de prueba o respuestas ante esperas. Las pruebas de contrato ayudan a detectar cambios antes de afectar a clientes, pero no sustituyen la observación operativa. También importan los identificadores entre sistemas: un caso debe poder seguirse sin buscar manualmente en registros inconexos. El número de integraciones no mide por sí mismo la calidad del producto.
Permisos, seguridad y protección de datos
Usuarios finales, personal de soporte, aprobadores y administradores necesitan permisos diferentes. Se definen por acciones y datos concretos, no solo por nombres de pantallas. Un cambio sensible puede requerir otra aprobación o separación de funciones. Secretos y tokens no pertenecen al código del cliente ni a la analítica. Los registros deben facilitar el diagnóstico sin convertirse en otra copia descontrolada de datos personales o de pago. El modelo de permisos debe soportar nuevas funciones y cambios de roles.
OWASP ASVS ofrece un marco abierto para verificar controles técnicos de seguridad en aplicaciones web; el alcance y rigor se eligen según el riesgo. Si un producto almacena, procesa o transmite datos de tarjetas, o puede afectar a ese entorno, el alcance aplicable de PCI DSS requiere una determinación aparte con partes cualificadas. Una página general no puede declarar que una aplicación cumple un estándar. La seguridad se evalúa en la arquitectura y organización reales, incluidos accesos, cambios y respuesta a incidentes.
Contexto normativo y resiliencia operativa
Las obligaciones dependen del tipo de entidad financiera, producto y jurisdicción. En Europa, el marco DORA sobre resiliencia operativa digital puede ser relevante para una entidad incluida en su ámbito; el equipo jurídico y de cumplimiento responsable debe evaluar el impacto real. Los ingenieros necesitan saber qué registros, relaciones contractuales, pruebas de recuperación y eventos operativos debe soportar el sistema. Diseñar sin ese contexto puede exigir grandes cambios posteriores en arquitectura o procedimientos.
La resiliencia significa más que tener un servidor disponible. Hay que saber si se procesan solicitudes, si hay mensajes retrasados, si los estados finales cuadran y si la recuperación puede repetir operaciones. Una copia de la base de datos debe acompañarse de un método para restaurar una situación coherente con los sistemas conectados. En un incidente se necesita conocer el impacto, quién decide y cómo comunicar. Las medidas de disponibilidad y objetivos de recuperación se fijan para cada servicio y se ensayan.
Una primera entrega verificable
La primera etapa no tiene que incluir todo el producto, pero sí recorrer un camino importante desde la entrada hasta un resultado verificable e incluir una excepción significativa. Una solicitud podría crearse, enviarse a un proveedor, recibir un estado confirmado o desconocido y seguir siendo trazable en una interfaz interna. Pruebas de reglas de negocio, eventos correlacionados, roles y monitorización básica forman parte de ese recorrido. Esto revela el riesgo real de integración mejor que una colección de pantallas terminadas.
Tras el piloto se decide qué construir después, qué cambiar y qué dejar al servicio de un socio. Las estimaciones distinguen componentes conocidos de dependencias de terceros, datos o valoración legal. El cliente debe entender los límites: quién es dueño del producto, quién opera la integración, quién aprueba reglas y quién resuelve excepciones. La transferencia incluye código, contratos, instrucciones de migración, configuración sin secretos y un escenario de recuperación. La posibilidad de verificar importa más que una lista impresionante de funciones.
Preguntas para la primera conversación
Prepare un resumen de roles, flujo principal, sistemas conectados y datos que no se pueden perder. Para cada servicio externo, indique si dispone de documentación, entorno de pruebas y una persona autorizada para decidir cambios. Registre incidentes conocidos y casos que hoy exigen trabajo manual. Si el producto está regulado, nombre al responsable interno de la valoración jurídica y de cumplimiento; un proveedor técnico no debe extraer conclusiones legales de un encargo incompleto.
También ayuda elegir la medida más importante de la primera etapa: estado correcto, tiempo de finalización, menos reparaciones manuales o capacidad de incorporar un socio con seguridad. No todos los objetivos deben cumplirse a la vez. Registrar hipótesis y excepciones ayuda a decidir si se empieza por análisis, prototipo de integración o desarrollo delimitado. Así la conversación pasa de una promesa imprecisa de «plataforma fintech» a un resultado que más adelante se pueda aceptar y operar.