FinSentry AI — API

1. Concepto

FinSentry AI es un SaaS API-first de detección de fraude en tiempo real para instituciones financieras medianas (bancos regionales, cooperativas de crédito, fintechs). Sustituye motores de reglas rígidos por un **motor de riesgo multi-agente**: cada transacción se evalúa desde varios ángulos independientes (monto, ubicación, velocidad, canal) y los votos se combinan en una puntuación de riesgo 0-100 con una explicación concisa y accionable para el analista.

Monetización: suscripción por niveles según volumen mensual de transacciones analizadas (API-first SaaS).

2. Arquitectura

Cliente (banco/fintech)
   │  JWT
   ▼
TransactionController ──► AnalysisService ──► MultiAgentRiskEngine (4 agentes)
                                │                    │
                                ▼                    ▼
                        TransactionRepository   RiskAnalysisRepository
                                │
                                ▼
                        WebhookNotifierService ──► webhook del cliente (async, virtual threads)

DashboardController ──► DashboardService ──► RiskAnalysisRepository / AnalystFeedbackRepository
WebhookController    ──► WebhookSubscriptionRepository
AuthController       ──► JwtService (emisión de tokens)

• Capas: %%INLINE0%% (API REST) → %%INLINE1%% (orquestación y lógica de

negocio) → %%INLINE2%% (Spring Data JPA) → %%INLINE3%% (entidades JPA).

• MultiAgentRiskEngine: implementación del core de IA. Cuatro agentes

independientes (%%INLINE5%%, %%INLINE6%%, VelocityAgent, ChannelAgent) votan 0-100 con una razón; el veredicto final promedia los votos y compone la explicación con las señales relevantes (score ≥ 50). VelocityAgent consulta transacciones recientes del mismo cliente en BD (ventana de 60 min) — señal real, no simulada.

• %%INLINE10%% (%%INLINE11%%): interfaz Feign lista para

el microservicio Python dedicado descrito en los requisitos técnicos ("el core de IA se ejecuta en un servicio Python separado"). El MVP corre el motor multi-agente en proceso para no depender de infraestructura externa; migrar AnalysisService a este cliente es un cambio de una línea cuando el servicio Python esté desplegado.

• Seguridad: JWT stateless (%%INLINE13%% 0.12.6). %%INLINE14%%

emite tokens para usuarios demo (%%INLINE15%%/%%INLINE16%%, %%INLINE17%%/%%INLINE18%%, in-memory). JwtAuthenticationFilter valida el header Authorization: Bearer <token> en cada request.

• Webhooks: WebhookNotifierService despacha notificaciones a todos los

endpoints activos cuando riskScore >= 85, usando Executors.newVirtualThreadPerTaskExecutor() (Java 25 virtual threads) para no bloquear el request de análisis ante un endpoint cliente lento o caído.

• Persistencia: H2 en memoria por defecto (Spring Boot auto-configura el

datasource embebido al no haber %%INLINE24%% en %%INLINE25%%); driver de PostgreSQL incluido en el pom.xml para producción — solo hace falta añadir spring.datasource.url apuntando a Postgres.

3. Endpoints

Método	Path	Auth	Descripción
POST	/api/v1/auth/login	pública	Login demo, devuelve JWT
POST	/api/v1/transactions/analyze	JWT	Envía transacción a análisis de riesgo en tiempo real
GET	/api/v1/transactions/{id}	JWT	Consulta el veredicto de una transacción
GET	/api/v1/dashboard/high-risk-transactions	JWT	Lista transacciones marcadas de alto riesgo (dashboard)
POST	%%INLINE32%%	JWT	Analista marca transacción como %%INLINE33%% / LEGITIMATE
POST	/api/v1/webhooks/subscriptions	JWT	Registra webhook del cliente
GET	/api/v1/webhooks/subscriptions	JWT	Lista webhooks registrados
GET	/actuator/health	pública	Health check

Ejemplo de flujo

# 1. Login
TOKEN=$(curl -s -X POST localhost:8080/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"analyst","password":"analyst123"}' | jq -r .token)

# 2. Analizar transacción
curl -s -X POST localhost:8080/api/v1/transactions/analyze \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "externalReference":"TX-1001",
    "customerId":"CUST-42",
    "amount":15000.00,
    "currency":"USD",
    "merchant":"Acme Corp",
    "location":"unknown",
    "channel":"online"
  }'
# → riskScore alto (AmountAgent + LocationAgent + ChannelAgent en rango alto),
#   explicación: "Monto inusualmente alto...; Ubicación inusual...; Canal sin presencia física..."

# 3. Dashboard de alto riesgo
curl -s localhost:8080/api/v1/dashboard/high-risk-transactions -H "Authorization: Bearer $TOKEN"

# 4. Feedback del analista
curl -s -X POST localhost:8080/api/v1/dashboard/feedback \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"transactionId":1,"verdict":"FRAUD","analystId":"analyst","notes":"Confirmado por cliente"}'

4. Referencias

• Fuente de la tendencia: https://www.techrev.us/blog/how-fintech-healthcare-saas-are-using-ai-in-2026
• Spring Boot 4.0.4 / Spring Framework 7 release notes.
• jjwt 0.12.6 (%%INLINE38%%) — API moderna %%INLINE39%% / Jwts.parser().
• Spring Cloud OpenFeign 4.2.1 — @FeignClient declarativo.

5. Análisis de Negocio

• Problema: bancos medianos y fintechs sufren altas tasas de falsos

positivos/negativos con motores de reglas rígidos, caros de mantener.

• Cliente objetivo: CROs, jefes de cumplimiento, equipos de operaciones.
• ROI directo: cada punto de reducción en falsos positivos = menos

fricción con clientes legítimos; cada fraude detectado a tiempo = pérdida evitada. Ambos son medibles y justifican el gasto en tecnología.

• Ventaja competitiva: el enfoque multi-agente se adapta más rápido que

reglas estáticas — nuevos agentes (ej. DeviceFingerprintAgent) se añaden sin reescribir el motor completo.

• Modelo de ingresos: suscripción por niveles de volumen mensual de

transacciones — escala con el crecimiento del cliente, alineando el costo con el valor entregado.

• Loop de mejora continua: el feedback de analistas (AnalystFeedback)

es el dataset de entrenamiento para futuras iteraciones del modelo, incrementando el valor del producto con el uso (data moat).

6. Cómo ejecutar

Requisitos: Java 25, Maven.

cd solutions/2026-07-12-finsentry-ai-api
mvn spring-boot:run

La app levanta en http://localhost:8080 con H2 en memoria (sin configuración adicional). Para producción, añadir a application.yml:

spring:
  datasource:
    url: jdbc:postgresql://<host>:5432/finsentry
    username: <user>
    password: <password>
finsentry:
  jwt:
    secret: <secreto-de-al-menos-32-bytes>
    expiration-seconds: 3600
  ai-engine:
    url: http://<host-servicio-python>:9000

Usuarios demo: %%INLINE46%% / %%INLINE47%%, %%INLINE48%% / %%INLINE49%%.

---

FinOps Analysis for FinSentry AI

Estimación de Costos Operativos

Para la fase de MVP de FinSentry AI, hemos proyectado los siguientes costos operativos mensuales. Esta estimación se basa en un volumen inicial de 50,000 transacciones analizadas por mes, donde el sistema multi-agente realiza aproximadamente 3 llamadas a LLM por transacción, con un promedio de 600 tokens (input + output) por llamada a gpt-4o-mini.

• Tokens LLM (principalmente gpt-4o-mini): ~$20/mes

* Estimación: ~90 millones de tokens/mes. * Este costo se basa en el uso intensivo de gpt-4o-mini, que es muy eficiente en costos. Si se requirieran modelos más grandes (ej. gpt-4o) para ciertos agentes o análisis de alta complejidad, este costo aumentaría.

• Cloud Hosting (AWS/GCP/Azure): ~$40/mes

* Incluye una instancia %%INLINE51%% (o equivalente) para la API Spring Boot y una instancia %%INLINE52%% (o equivalente) para el microservicio Python de IA. Considera costos base de red y almacenamiento para estas instancias.

• Base de Datos (PostgreSQL - AWS RDS db.t3.micro): ~$15/mes

* Cubre la instancia de base de datos, almacenamiento y I/O para persistir transacciones, análisis y feedback.

• Monitoreo y Logging (CloudWatch/Stackdriver): ~$5/mes

* Costos mínimos para la recolección y almacenamiento de logs y métricas básicas de la aplicación.

• APIs Externas (otras): $0/mes

* Actualmente no se identifican dependencias de APIs externas adicionales más allá de OpenAI (ya incluida en el costo de tokens LLM).

Costo Operativo Mensual Total Estimado: ~$80

Estimación de Ingresos y Margen de Beneficio

Considerando un modelo de monetización API-first SaaS basado en el volumen de transacciones, se proyecta un ingreso mensual inicial con una base de clientes de MVP.

• Ingreso Mensual Estimado: ~$700/mes

* Asumimos una combinación de 3-5 clientes iniciales en diferentes niveles de suscripción, promediando un valor de $150-$250 por cliente. Por ejemplo, 2 clientes en un nivel de 25,000 transacciones ($199/mes) y 1 cliente en un nivel de 50,000 transacciones ($349/mes).

Margen de Beneficio Estimado:

• Ingresos: $700
• Costos: $80
• Beneficio: $620

Margen de Beneficio: (620 / 700) 100 = ~89%

Este margen saludable es típico de una startup de software con bajos costos operativos iniciales y una propuesta de valor de alto impacto en el sector financiero.

Estrategias de Optimización de Costos (FinOps)

Para mantener y mejorar este margen de beneficio a medida que FinSentry AI escala, se recomiendan las siguientes optimizaciones de FinOps:

1. Optimización del Consumo de LLM:

* Caché de Respuestas: Implementar un sistema de caché para almacenar y reutilizar respuestas de LLM para transacciones con patrones idénticos o muy similares, reduciendo las llamadas a la API de LLM. * Modelos Híbridos/Especializados: Para el sistema multi-agente, identificar qué tareas pueden ser realizadas por modelos más pequeños y económicos (o incluso reglas heurísticas) y reservar los LLMs más potentes y costosos (como gpt-4o) para análisis de alta complejidad o casos de borde. * Filtrado de Transacciones Inteligente: Desarrollar un pre-filtro basado en reglas o modelos heurísticos más simples para identificar transacciones de bajo riesgo que no requieran análisis completo por el sistema multi-agente, reduciendo significativamente el volumen de llamadas LLM.

1. Infraestructura Cloud Eficiente:

* Serverless para el Microservicio de IA: Migrar el microservicio Python a una arquitectura serverless (ej. AWS Lambda, Google Cloud Functions) para pagar solo por el tiempo de ejecución y el consumo de memoria, eliminando costos de instancias inactivas. * Instancias Spot/Reservadas: A medida que la carga se vuelve más predecible, explorar el uso de instancias Spot (para cargas tolerantes a interrupciones) o Reserved Instances (para carga base constante) para reducir los costos de cómputo en EC2/Compute Engine. * Base de Datos: Monitorear el rendimiento de la base de datos y considerar opciones de ahorro de costos como db.t4g.micro en AWS RDS (basado en Graviton) si el rendimiento es adecuado y la región lo soporta.

1. Monitoreo y Gobernanza de Costos:

* Alertas de Gasto: Configurar alertas proactivas en las herramientas de gestión de costos de la nube (ej. AWS Cost Explorer, GCP Cost Management) para notificar sobre umbrales de gasto excedidos, especialmente para el consumo de LLM que puede ser volátil. * Etiquetado de Recursos: Implementar una estrategia de etiquetado de recursos consistente para una visibilidad granular de los costos por servicio, ambiente o cliente (si aplica a futuro). * Revisión Periódica de Costos: Establecer revisiones mensuales o trimestrales de costos para identificar y eliminar recursos no utilizados o infraestructuras sobredimensionadas.

Estas estrategias permitirán a FinSentry AI optimizar sus gastos a medida que crece, asegurando la sostenibilidad y maximizando el retorno de la inversión.