El fraude financiero es un problema de red: México lo resuelve con Veradat en AWS

Por Fabiana Serangelli y Aridai Solis

El fraude bancario en México no creció de forma gradual — se disparó. Los casos de account takeover aumentaron 324% entre finales de 2024 y principios de 2026, el mayor crecimiento de toda Latinoamérica — según el BioCatch LATAM Financial Crime Report, un análisis de 36 instituciones financieras de la región que atienden a más de 300 millones de clientes. El número por sí solo no captura la raíz del problema: cada banco combatía el fraude de forma aislada. Esa fragmentación era el riesgo real.

Cuando una institución detectaba y vetaba a un actor fraudulento, esa información se quedaba encerrada en sus sistemas internos. El defraudador simplemente se movía al siguiente banco, abría una cuenta o solicitaba un crédito, y repetía el patrón. El ecosistema financiero, en conjunto, pagaba múltiples veces por el mismo fraude que ya alguien había identificado.

El equipo que construyó esta plataforma reconoció desde el inicio que el problema no era tecnológico sino estructural: ningún banco tenía incentivos individuales para compartir inteligencia sin garantías de reciprocidad y control. Ese fue el punto de partida para diseñar Veradat.

Los enfoques existentes no resolvían esto. El intercambio por correo electrónico o archivos planos era lento, sin trazabilidad y sin capacidad de consulta en tiempo real. Las listas internas de cada banco vivían en silos. Las integraciones punto a punto entre instituciones tampoco escalaban: conectar N bancos entre sí requiere N×(N-1) integraciones independientes, cada una con su propio estándar de API. Ese modelo es inviable de gobernar.

El punto de quiebre fue reconocer que el fraude es un problema de red. Combatirlo requería una plataforma compartida donde cada banco pudiera exponer su lista de vigilancia al ecosistema y consultar las de los demás, sin renunciar al control ni a la privacidad de su propia información. Veradat nace como respuesta del sistema financiero mexicano a una realidad: ningún banco puede combatir el fraude de red actuando solo. Desplegada sobre AWS, funciona como la capa de inteligencia compartida que conecta a las instituciones en tiempo real.

Qué es Veradat y qué resuelve

Veradat es una infraestructura financiera y plataforma digital descentralizada diseñada para que los bancos colaboren en tiempo real en la prevención del lavado de dinero y delitos financieros. El principio central es directo: cada banco puede compartir inteligencia sobre riesgos con el resto de la red sin exponer datos confidenciales o sensibles de sus clientes.

La plataforma expone un conjunto de APIs estándar que permiten a cada institución dar de alta personas en una Lista de Vigilancia compartida, realizar cargas masivas de registros, recibir notificaciones en tiempo real cuando otro banco registra a un individuo que ya existe en su propia Lista Privada, y ejecutar cotejos masivos contra el ecosistema completo.

El aislamiento es fundamental: ningún banco accede directamente a la base de datos de otro. La red centraliza la inteligencia sin centralizar los datos sensibles.

La elección de AWS como plataforma de despliegue respondió a tres requisitos concretos: elasticidad para manejar volúmenes variables de consultas, controles de seguridad nativos para cumplir con los requisitos de la Comisión Nacional Bancaria y de Valores (CNBV), y la llegada de la región AWS México Central (mx-central-1) que hace posible la residencia de datos en territorio nacional.

Arquitectura de referencia: el modelo de nodo por banco

El despliegue sigue un modelo de «nodo por banco» conectado a la red central de Veradat. Cada institución opera su propio nodo dentro de su entorno AWS, y ese nodo se conecta a la plataforma mediante canales autenticados y cifrados.

La arquitectura se divide en cuatro capas funcionales que se describen a continuación.

Figura 1. Arquitectura de un nodo participante: cada institución financiera despliega este componente en su propia cuenta AWS (mx-central-1) para alimentar la red Veradat con señales de fraude en tiempo real.

Capa de conectividad y autenticación

Cada banco establece conectividad hacia la red de Veradat mediante AWS VPN Site-to-Site con el protocolo IKEv2 y doble túnel para alta disponibilidad. Para autenticar usuarios, la plataforma usa federación con el IdP corporativo de cada banco mediante SAML 2.0 u OIDC, validando Control de Acceso Basado en Roles (RBAC, por sus siglas en inglés) delimita qué operaciones puede ejecutar cada perfil dentro del banco, validándose contra los grupos/claims del IdP.

Para instituciones con mayores requisitos de latencia, ancho de banda o cumplimiento normativo, AWS Direct Connect ofrece una alternativa a la VPN que elimina la dependencia del internet público.

Capa de acceso (DMZ)

El tráfico entrante llega a una zona desmilitarizada (DMZ, por sus siglas en inglés) que actúa como frontera de seguridad. Incluye un Network Load Balancer (NLB) y, como componente de acceso principal recomendado, un Amazon API Gateway que expone las APIs estándar de Veradat con Alta Disponibilidad (autenticación por mTLS / client credentials). Para casos donde se requiere mayor control de tráfico, puede usarse un NGINX como reverse proxy.

Plataforma de contenedores

La lógica de negocio corre sobre Amazon Elastic Kubernetes Service (Amazon EKS) con auto-escalado horizontal. Los nodos worker usan instancias c6i.2xlarge (x86, 8 vCPU / 16 GB) o m7g.2xlarge (Graviton, 8 vCPU / 32 GB), con al menos 4 nodos y un máximo de 5, cada uno con 100 GB de almacenamiento, conforme al dimensionamiento del namespace.

El namespace de Veradat dentro del clúster requiere una capacidad agregada de 42 vCPU. La RAM varía entre 72 GB (mínimo) y 112 GB de RAM (máximo), más 500 GB de almacenamiento. Este requerimiento agregado es el que determina el número real de nodos worker.

Además del componente de acceso, la arquitectura permite de forma opcional un forward proxy NGINX (2× t4g.medium, 50 GB) para controlar y filtrar el tráfico de salida de los contenedores hacia la VPN o Internet, cuando la política de seguridad del banco exige inspeccionar las conexiones salientes.

Escalabilidad en dos niveles: La plataforma escala en dos capas. El Horizontal Pod Autoscaler (HPA) replica pods según CPU/memoria, mientras que el Cluster Autoscaler añade o retira nodos EC2 (de 4 hasta un máximo de 5) cuando los pods ya no caben en la capacidad existente. Esto absorbe picos de demanda —por ejemplo, durante cargas masivas o cotejos de listas contra el ecosistema— sin sobreaprovisionar. Esto cumple la premisa de Veradat: aumentar o reducir capacidad según demanda real. El dimensionamiento agregado del namespace (42 vCPU y de 72 GB a 112 GB de RAM) determina la capacidad base que estos mecanismos ajustan de forma dinámica.

Repositorios de código e imágenes

El flujo de despliegue de la plataforma se apoya en un repositorio de código fuente basado en Git (por ejemplo GitHub) y en un repositorio de imágenes de contenedor en Amazon Elastic Container Registry (Amazon ECR) con alta disponibilidad, donde se almacenan las imágenes que consumen los nodos de Amazon EKS. Amazon ECR integra nativamente con EKS y escanea vulnerabilidades en imágenes antes del despliegue.

Datos, mensajería y seguridad

Almacenamiento relacional: Amazon Relational Database Service (Amazon RDS) para PostgreSQL 16+ en configuración Multi-AZ almacena las listas de vigilancia y los registros de auditoría. El standby en una segunda zona de disponibilidad (AZ) garantiza continuidad ante eventos de infraestructura.

Caché: Amazon ElastiCache (Redis OSS) acelera consultas repetidas sobre los registros de mayor frecuencia.

Mensajería asíncrona: el documento de requerimientos de Veradat permite tres opciones de broker, y la arquitectura de referencia recomienda Amazon Simple Queue Service (Amazon SQS):

Amazon SQS (recomendado): servicio serverless de pago por uso; ideal cuando el volumen varía impredeciblemente, ya que no requiere mantener infraestructura encendida 24×7.
Apache Kafka: despliegue en clúster (ej. 3 nodos). Ideal para alto throughput y retención de mensajes. Requiere instancias de generación actual (ej. m6i).
RabbitMQ (Amazon MQ): broker gestionado en clúster, adecuado cuando la plataforma ya opera con AMQP; usa instancias tipo mq.m7g.

Almacenamiento: Amazon Simple Storage Service (Amazon S3) con acceso SFTP administrado por AWS Transfer Family para la carga de archivos de evidencia.

Notificaciones a usuarios: para el envío de notificaciones (por ejemplo alertas por coincidencias), el documento ofrece tres opciones, con Amazon Simple Notification Service (Amazon SNS) como recomendada:

Amazon SNS (recomendado): servicio de mensajería pub/sub totalmente gestionado y serverless, para notificaciones por correo/SMS/HTTP sin administrar infraestructura.
Servidor de correo (Email Server): integración con un servidor SMTP propio del banco, si se requiere usar la infraestructura de correo existente.
Microsoft Graph API: para bancos cuyo entorno de productividad es Microsoft 365 y prefieren enrutar las notificaciones por esa vía.

Seguridad transversal: AWS Key Management Service (AWS KMS) cifra datos en reposo y en tránsito. AWS Shield protege contra ataques DDoS en la capa perimetral. AWS WAF (Web Application Firewall) filtra el tráfico en la capa de aplicación. Amazon GuardDuty detecta actividad anómala. AWS CloudTrail registra cada llamada a la API con trazabilidad completa de qué, quién, cómo y cuándo.

Acceso privado a servicios AWS: Para cumplir la premisa de aislamiento, los nodos de Amazon EKS alcanzan los servicios gestionados de AWS sin salir a Internet. El acceso a Amazon S3 se realiza mediante un VPC Endpoint de tipo gateway (enrutado vía tabla de rutas, sin costo adicional), mientras que el acceso a Amazon SQS y Amazon SNS —y opcionalmente a AWS KMS, Amazon ECR, Amazon CloudWatch y AWS STS— se hace a través de interface endpoints con AWS PrivateLink, que exponen cada servicio como una interfaz de red privada (ENI) dentro de la Amazon Virtual Private Cloud (Amazon VPC). Así, todo el tráfico hacia estos servicios permanece dentro de la red de AWS, reforzando el aislamiento y el control de egreso que exigen las premisas de seguridad de la plataforma.

Prerrequisitos antes de desplegar

Antes de comenzar, el equipo necesita tener resueltos los siguientes puntos.

Cuenta y región AWS: la cuenta debe tener acceso habilitado a mx-central-1 y los Service Quotas necesarios para los servicios listados (Amazon EKS, Amazon RDS, Amazon ElastiCache (Redis OSS), Amazon SQS, Amazon S3, AWS KMS).

Conectividad: establecer VPN Site-to-Site IKEv2 desde la red del banco hacia la red de Veradat. Si el volumen de tráfico o los requisitos de SLA lo justifican, AWS Direct Connect es la alternativa recomendada.

Proveedor de identidad (IdP): el IdP corporativo compatible con SAML 2.0 u OIDC (por ejemplo Microsoft Entra ID, Okta, Ping Identity o cualquier IdP empresarial). El equipo debe decidir si la validación del IdP ocurre por HTTPS público o si requiere un enlace privado hacia el directorio corporativo.

Versiones mínimas: Amazon EKS con Kubernetes 1.28+, PostgreSQL 16+ en Amazon RDS.

Despliegue paso a paso

El flujo de despliegue sigue una secuencia que va desde la red hacia la aplicación.

Paso 1 — Red y Amazon VPC. Crear una Amazon VPC dedicada en mx-central-1 con subredes públicas y privadas distribuidas en al menos dos AZ. La DMZ es una subred privada aislada y sin Internet Gateway; el tráfico entra por la VPN interbancaria o la Intranet del banco, no desde Internet público. Amazon EKS, Amazon RDS y Amazon ElastiCache (Redis OSS) residen en subredes privadas separadas, sin acceso directo desde Internet.

Paso 2 — VPN Site-to-Site. Configurar el Virtual Private Gateway en la Amazon VPC y el Customer Gateway con la IP pública del equipo del banco. Definir dos túneles IKEv2 para redundancia, esto garantiza que una falla no interrumpa la conexión a Veradat. La configuración de la VPN del lado de Veradat la provee el equipo de la plataforma durante el proceso de onboarding.

# Crear el Customer Gateway (IP del dispositivo VPN del banco)
aws ec2 create-customer-gateway \
  --type ipsec.1 \
  --public-ip 203.0.113.10 \
  --bgp-asn 65000 \
  --region mx-central-1

# Crear el Virtual Private Gateway y adjuntarlo a la Amazon VPC
aws ec2 create-vpn-gateway \
  --type ipsec.1 \
  --region mx-central-1

aws ec2 attach-vpn-gateway \
  --vpn-gateway-id vgw-EXAMPLE1234567890 \
  --vpc-id vpc-EXAMPLE0987654321 \
  --region mx-central-1

Paso 3 — Clúster Amazon EKS. Desplegar el clúster con eksctl usando el manifiesto de configuración que especifica los tipos de instancia validados para la región. Consultar las AZ de mx-central-1 antes de fijar valores en el manifiesto. El comando recomendado: aws ec2 describe-availability-zones --region mx-central-1

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: veradat-node
  region: mx-central-1
  version: "1.28" # verificar versión actual soportada
managedNodeGroups:
  - name: veradat-workers
    instanceType: c6i.2xlarge  
    minSize: 4
    maxSize: 5
    desiredCapacity: 4
    # Verificar nombres exactos de AZ con describe-availability-zones
    availabilityZones:
      - mx-central-1a
      - mx-central-1b
    volumeSize: 100
    privateNetworking: true
    iam:
      withAddonPolicies:
        autoScaler: true
        cloudWatch: true

Paso 4 — Amazon RDS PostgreSQL Multi-AZ. La base de datos se despliega en subred privada con una instancia standby en la segunda AZ. El cifrado usa una clave gestionada por AWS KMS. La contraseña se obtiene desde AWS Secrets Manager en tiempo de ejecución y se pasa como variable de entorno para evitar que quede expuesta en el historial del shell o en logs de proceso.

# Obtener la contraseña en una variable de entorno (no en línea)
DB_PASSWORD=[REDACTED_PASSWORD] secretsmanager get-secret-value \
  --secret-id veradat/db/password \
  --query SecretString \
  --output text \
  --region mx-central-1)

aws rds create-db-instance \
  --db-instance-identifier veradat-db \
  --db-instance-class db.m6i.2xlarge \
  --engine postgres \
  --engine-version "16.2" \ 
  --master-username veradatadmin \
  --master-user-password "$DB_PASSWORD" \
  --allocated-storage 100 \
  --storage-encrypted \
  --kms-key-id alias/veradat-rds-key-EXAMPLE \
  --multi-az \
  --db-subnet-group-name veradat-db-subnet-group \
  --vpc-security-group-ids sg-EXAMPLE1234567890 \
  --region mx-central-1

Paso 5 — Amazon SQS para mensajería asíncrona. Las colas procesan notificaciones hacia los bancos cuando un nuevo registro impacta su Lista Privada. Una cola de mensajes no procesados (dead-letter queue) captura mensajes que fallan repetidamente para análisis posterior. La política RedrivePolicy vincula ambas colas para que el redireccionamiento sea automático.

# Dead-letter queue (crear primero para obtener su ARN)
DLQ_URL=$(aws sqs create-queue \
  --queue-name veradat-notifications-dlq.fifo \
  --attributes FifoQueue=true,ContentBasedDeduplication=true \
  --region mx-central-1 \
  --query QueueUrl \
  --output text)

DLQ_ARN=$(aws sqs get-queue-attributes \
  --queue-url "$DLQ_URL" \
  --attribute-names QueueArn \
  --region mx-central-1 \
  --query Attributes.QueueArn \
  --output text)

# Cola principal con RedrivePolicy apuntando a la DLQ
aws sqs create-queue \
  --queue-name veradat-notifications.fifo \
  --attributes "{
    \"FifoQueue\": \"true\",
    \"ContentBasedDeduplication\": \"true\",
    \"KmsMasterKeyId\": \"alias/veradat-sqs-key\",
    \"RedrivePolicy\": \"{\\\"deadLetterTargetArn\\\":\\\"$DLQ_ARN\\\",\\\"maxReceiveCount\\\":\\\"5\\\"}\"
  }" \
  --region mx-central-1

Paso 6 — Seguridad transversal. Habilitar Amazon GuardDuty y AWS CloudTrail para la cuenta en mx-central-1. Para AWS WAF en el API Gateway, las reglas que bloquean patrones de abuso comunes (inyección SQL, fuerza bruta sobre endpoints) requieren ajuste fino por ruta. En los primeros días de operación, conviene ejecutar AWS WAF en modo Count antes de cambiar a modo Block: eso permite identificar si alguna ruta legítima de las APIs de Veradat activa una regla gestionada antes de que el tráfico real se vea afectado.

Análisis de costos: dónde viven los ahorros reales

Resumen de costos (On-Demand, mx-central-1, configuración de referencia con Amazon SQS):

Opción 1 — Instancias x86 (c6i.2xlarge): ~$3,640 USD/mes
Opción 2 — Instancias Graviton (m7g.2xlarge): ~$3,590 USD/mes

⚠️ Nota: Ambas opciones consideran el uso de Amazon SQS como broker de mensajería porque es un servicio serverless de pago por uso: no requiere mantener un clúster encendido 24×7 (como sí lo harían RabbitMQ o Kafka autogestionados), escala automáticamente ante volúmenes variables de mensajes, y elimina la sobrecarga operativa de parchar y administrar infraestructura de mensajería. Frente a un clúster de broker equivalente, esto representa un ahorro aproximado de $880 USD/mes por nodo del banco. Adicionalmente, estos valores son estimados basados en la configuración de referencia al momento de publicación. Los precios de AWS varían según región, cambios en lista de precios, volumen de uso, y pueden ser sujetos a revisión.

Se recomienda altamente que el equipo del banco implementando la solución realice un monitoreo continuo de costos.

Observabilidad y operación 24×7

La arquitectura está diseñada para operar de forma continua. Amazon RDS Multi-AZ conmuta automáticamente al standby ante una falla sin intervención manual. Amazon EKS redistribuye los pods entre las AZ disponibles si una zona presenta problemas.

Para observabilidad, Amazon CloudWatch Metrics captura las métricas de todos los componentes AWS. Los logs de aplicación de los pods Amazon EKS fluyen a Amazon CloudWatch Logs mediante el agente Fluent Bit desplegado como DaemonSet en el clúster.

Las alertas deben cubrir al menos cuatro dimensiones: latencia de respuesta de las APIs (umbral recomendado: p99 < 500ms para consultas individuales), profundidad de las colas Amazon SQS (colas crecientes indican que los consumidores no procesan al ritmo de producción), conexiones activas en Amazon RDS (anticipa presión en el connection pool), y hallazgos de Amazon GuardDuty de severidad alta.

Conclusión

Veradat resuelve un problema que ningún banco puede resolver de forma individual: el fraude que migra entre instituciones aprovecha precisamente los silos de información que el sector financiero ha mantenido por décadas. La plataforma construye una red de inteligencia compartida donde la información fluye sin que los datos sensibles salgan del control de cada institución.

El despliegue sobre AWS en mx-central-1 cumple dos objetivos al mismo tiempo: satisface los requisitos de residencia de datos de la CNBV y mantiene los costos dentro de rangos operativos razonables. La diferencia de 5% en costo frente a otras regiones es el precio de esa residencia de datos.

Para arquitectos de nube y equipos de FinOps en instituciones financieras mexicanas: el modelo de nodo por banco que describe este post es reproducible. Cada institución miembro de la ABM puede incorporarse a la red con el mismo patrón arquitectónico, ajustando únicamente los parámetros de conectividad y los perfiles de identidad propios. La infraestructura compartida existe; el trabajo es conectarse a ella de forma segura y gobernable.

Si su institución está interesada en conectarse a la red Veradat o desea conocer más sobre la arquitectura de referencia, contacte a su equipo de cuenta de AWS o visite veradat.com. Estamos listos para acompañarlos en el camino.

Sobre las autoras

Fabiana Serangelli es Solutions Architect en AWS, donde trabaja con clientes de múltiples industrias en México, incluyendo los sectores de salud, manufactura y logística. Cuenta con más de cinco años de experiencia en arquitecturas cloud y una maestría en Análisis de Negocios. Su enfoque se centra en acompañar a clientes de distintos sectores en su adopción de la nube con soluciones seguras, escalables y a la medida de cada industria.

Aridai Solís es Solutions Architect en AWS, donde trabaja con instituciones del sector financiero en México. Cuenta con más de cinco años de experiencia en arquitecturas cloud y una maestría en Big Data. Su enfoque se centra en ayudar a clientes a diseñar soluciones seguras, escalables y alineadas con los requisitos regulatorios del sistema financiero mexicano.

Blog de Amazon Web Services (AWS)