Problema a resolver

Solventa es una aseguradora digital (insurtech) fundada en 2026, concebida desde cero (arquitectura greenfield y nativa en la nube) y construida sobre el ecosistema de Finanzas Abiertas (Open Finance) y Datos Abiertos (Open Data). A diferencia de las empresas tradicionales, no cuenta con sistemas heredados y su modelo de negocio funciona simultáneamente como una aseguradora de nicho y como una plataforma de distribución de seguros embebidos orientada a APIs (API-first) El mercado de seguros en América Latina ha sufrido históricamente de una baja penetración, procesos manuales, tiempos de emisión que toman días y una experiencia de reclamo de siniestros que destruye la confianza del cliente. Solventa busca resolver este problema eliminando la fricción y la demora en todo el ciclo de vida del seguro. Su objetivo es cotizar, suscribir, emitir pólizas y pagar siniestros de bajo monto de forma casi instantánea. En lugar de esperar a que el cliente busque un seguro, Solventa resuelve el problema de la distribución al "embeber" o integrar el seguro en el punto y momento exacto de la necesidad del cliente, por ejemplo, al comprar un tiquete, alquilar un carro o solicitar un crédito hipotecario. Además, soluciona el problema de los precios estandarizados y costosos al perfilar al cliente en tiempo real usando datos financieros y públicos para ofrecer tarifas altamente personalizadas y justas.

Objetivos de los Stakeholders

• Alcanzar 5 millones de pólizas activas en 36 meses, con cotización, suscripción y emisión casi instantáneas sobre Open Finance y Open Data. • Integrar 30+ socios de distribución (bancos, aerolíneas, e-commerce, fintech y retail) mediante seguro embebido vía API. • Automatizar el pago de siniestros de bajo monto y paramétricos, reduciendo tiempos de atención y mejorando la experiencia 24/7 del cliente. • Posicionarse como la aseguradora digital de referencia en Finanzas Abiertas en Colombia, con expansión a México, Chile y Perú.

Riesgos identificados

• Pérdida de clientes a manos de la competencia si la cotización/emisión no es casi instantánea. • Degradación o caída de Open Finance / Open Data que impida cotizar y perfilar dentro del presupuesto de latencia. • Incumplimiento de habeas data o de estándares de Finanzas Abiertas (consentimiento, auditoría, Superfinanciera). • Indisponibilidad en venta o pago de siniestros que erosione la confianza 24/7 del cliente. • Incapacidad de absorber picos (campañas 100×, originación hipotecaria, eventos paramétricos) sin degradar el servicio. • Retraso en el alta de socios embebidos o en nuevos ramos/países por acoplamiento de la arquitectura.

Restricciones de Negocio

Restricciones de Tecnología

• Solventa nace en 2026 como greenfield: no hay sistemas heredados y el diseño parte desde cero. • El equipo es reducido y debe poder crecer con el negocio; la complejidad organizacional aumenta con la escala. • Gran parte del valor de negocio depende de integraciones externas (Open Finance, Open Data, KYC, pagos, socios) fuera del control de Solventa. • Debe operar bajo Ley 1581 (habeas data), Decreto 1297 de 2022 y Circular Externa 004 de 2024 de la Superfinanciera; la regulación de Finanzas Abiertas sigue madurando. • El producto debe entregarse con cliente web y cliente móvil, y habilitar distribución embebida vía API a 30+ socios.

• Infraestructura nube primero: elástica, multi-zona y con posibilidad multi-región. • La arquitectura debe asumir fallos y latencia de terceros (timeouts, reintentos, circuit breakers, caché y degradación elegante). • Seguridad y privacidad by design: cifrado, tokenización de PII, consentimiento auditable y PCI-DSS en pagos. • Clientes web y móvil con propósitos distintos; el móvil exige capacidades nativas (cámara, biometría, push, geo y modo offline). • El estilo arquitectónico no está prescrito, pero debe sostener latencia, escalabilidad, disponibilidad, seguridad, facilidad de modificación e integración.

Duración	Fase	Actividades	Responsables	Horas -Hombre	Total Horas - Equipo
1 mes	Análisis	• Identificación del problema y objetivos • Revisión de requisitos funcionales y no funcionales • Identificación de puntos de integración • Identificación de restricciones • Evaluación de riesgos	Equipo de arquitectura y desarrollo	60	240 (4 arquitectos)
1 mes	Diseño de arquitectura	• Modelado de sistema (vistas contexto, dominio, despliegue, componentes) • Definición de backlog de arquitectura • Definición de microservicios • Especificación de APIs • Plan de seguridad • Hipótesis de diseño y experimentación	Equipo de arquitectura (4 personas)	60	240 (4 arquitectos)
1 mes	Construcción de la solución	• Desarrollo del backend (Python) • Implementación de integraciones (Open Finance, Open Data, pagos, KYC) • Desarrollo de app móvil • Pruebas de integración • Pruebas de carga	Equipo de desarrollo / DevOps (4 personas)	60	240 (2 dev backend, 1 dev frontend web, 1 dev móvil híbrido)
1 mes	Pruebas	• Pruebas E2E • Pruebas de aceptación • Validación de normativa regulatoria (Superfinanciera, habeas data) • Pruebas de seguridad	Q/A Testing (4 personas)	60	240 (4 testers)
Total (4 meses)				240	960

El modelo de contexto vigente (ficha, convención, actores por canal, diagrama y fuente PlantUML) se consolidó en la hoja de trabajo de la semana 5.

Ver: Hoja de trabajo semana 5 · §1.1 Modelo de contexto

El modelo de información vigente (ficha, convención y diagrama entidad-relación por microservicio) se consolidó en la hoja de trabajo de la semana 5, donde pasó a ser el primer modelo de la vista de información.

Ver: Hoja de trabajo semana 5 · §1.4.1 Modelo de datos, dentro de §1.4 Vista de información

Nuevo en la semana 5. Diagrama de secuencia sobre las estructuras de datos: los dos recorridos que mueven el estado de la póliza —cotización con perfilamiento, y emisión con propagación asíncrona—, con el timeout duro, la rama degradada y el punto en que la respuesta se desacopla de la propagación.

Ver: Hoja de trabajo semana 5 · §1.4.2 Flujo de control sobre el modelo de información

Nuevo en la semana 5. Estrategia de redundancia por servicio: activa en :MsPolizas —la réplica atiende lecturas en producción— y pasiva en :MsSiniestros —la réplica se mantiene fuera del tráfico y solo se promueve ante la caída de la zona—, con mecanismos, RPO/RTO y el Monitor que dispara la promoción.

Ver: Hoja de trabajo semana 5 · §1.4.3 Estrategia de replicación (activa/pasiva)

El modelo de componentes vigente (ficha, convención y diagrama funcional actualizado) se consolidó en la hoja de trabajo de la semana 5. Incorpora :Consentimiento sobre la salida a Open Finance, las cachés de los adaptadores externos y los almacenes replicados de pólizas y siniestros, con las tácticas trazadas escenario a escenario.

Ver: Hoja de trabajo semana 5 · §1.2 Vista funcional — Modelo de componentes

El zoom de capas de los clientes está en §1.5 Arquitectura del portal web (MVVM) y en §1.6 Arquitectura del cliente móvil (Android).

El modelo de despliegue vigente (ficha y diagrama AWS actualizado) se consolidó en la hoja de trabajo de la semana 5.

Ver: Hoja de trabajo semana 5 · §1.3 Vista de despliegue — AWS

El caso exige dos clientes con propósito distinto sobre el mismo núcleo de negocio. La web cubre la gestión completa; el móvil cubre un subconjunto de esos recorridos y añade capacidades del dispositivo. Python concentra cotización, suscripción, emisión, pólizas, siniestros, pagos y perfilamiento, y las expone a web, móvil y API embebida.

Capa	Tecnología	Funcionalidad core (compartida)	Particular del canal
Backend y nube	Python	Recorridos de extremo a extremo: cotización, suscripción y emisión, siniestro asistido, siniestro paramétrico, perfilamiento (p. ej. vida hipotecario) y ciclo de vida de la póliza. Una sola API de dominio para web, móvil y socios embebidos.	Operación nube primero (elástica, multi-zona) e integraciones (Open Finance, Open Data, KYC, pagos, IoT, reaseguro).
Frontend web	AngularJS	Los mismos recorridos de cliente: consultar póliza y siniestro, aceptar oferta, gestionar renovación/cambio/cancelación, y operación asistida sobre ese núcleo.	Cobertura funcional total: venta asistida, back-office de socios, peritos, tableros y administración.
Aplicación móvil	Android / Kotlin	Subconjunto del núcleo orientado a tareas rápidas: billetera de pólizas, aviso y seguimiento de siniestro, estado de pago paramétrico, vencimiento y renovación.	Capacidades nativas sin equivalente pleno en web: cámara y evidencia geoetiquetada, biometría, push, geolocalización/asistencia en sitio, modo offline y escaneo de documentos.