Por qué el Software Bancario Exige el Mayor Rigor en Testing

La banca y las finanzas es uno de los dominios más exigentes para el testing de software. Un solo bug puede resultar en pérdidas financieras que afectan a miles de clientes, multas regulatorias de millones, o la pérdida total de la confianza del cliente. A diferencia de una app de redes sociales donde un bug causa una molestia menor, un bug bancario puede significar dinero real desapareciendo de cuentas reales.

El software financiero incluye sistemas de core bancario, plataformas de procesamiento de pagos, aplicaciones de gestión de préstamos, plataformas de trading y apps de banca móvil. Cada uno maneja datos financieros sensibles y debe cumplir con requisitos regulatorios estrictos.

Terminología del Dominio que Necesitas Conocer

Antes de testear software bancario, debes hablar el idioma:

  • Libro contable (Ledger): El registro central de todas las transacciones financieras
  • Liquidación (Settlement): La transferencia real de fondos entre partes
  • Reconciliación: Verificar que los registros coincidan entre sistemas
  • Compensación (Clearing): El proceso de transmitir y confirmar órdenes de pago entre bancos
  • Float: Dinero en tránsito entre cuentas durante el procesamiento
  • T+1, T+2: Tiempo de liquidación — uno o dos días hábiles después de la fecha de la operación
  • KYC: Know Your Customer — requisitos de verificación de identidad

Desafíos del Testing Financiero

Precisión Decimal: La Trampa del Punto Flotante

El desafío más fundamental en testing financiero es la precisión numérica. La aritmética de punto flotante estándar produce errores que son invisibles en la mayoría de dominios pero catastróficos en finanzas:

# Esto falla en punto flotante estándar
assert 0.1 + 0.2 == 0.3  # ¡Falso! El resultado es 0.30000000000000004

# Los sistemas financieros deben usar tipos decimales exactos
from decimal import Decimal
assert Decimal('0.1') + Decimal('0.2') == Decimal('0.3')  # Verdadero

Los casos de prueba deben verificar que el sistema use aritmética decimal exacta en todo el flujo — desde la entrada del usuario, pasando por los cálculos, hasta el almacenamiento y la visualización.

Conversión de Moneda y Multi-Divisa

El testing de operaciones con divisas introduce complejidad adicional:

  • Las monedas tienen diferentes lugares decimales: USD (2), JPY (0), BHD (3)
  • Los tipos de cambio cambian constantemente y deben tener marca de tiempo
  • Las reglas de redondeo difieren por moneda y jurisdicción
  • Las transacciones cross-currency involucran múltiples pasos de conversión

Atomicidad de Transacciones y Concurrencia

Las transacciones financieras deben ser atómicas — se completan totalmente o no se ejecutan. Considera este escenario:

Cuenta A: $1,000
Transferir $500 de A a B
Transferir $700 de A a C (enviado simultáneamente)

Sin control de concurrencia adecuado, ambas transferencias podrían leer el saldo de $1,000 y tener éxito, resultando en un saldo negativo. El testing debe verificar que el sistema maneja el acceso concurrente correctamente.

Procesamiento de Fin de Día

Los bancos ejecutan procesos batch al fin del día (EOD) para calcular intereses, procesar órdenes permanentes, generar estados de cuenta y reconciliar cuentas. El testing EOD debe verificar:

  • Cálculos de intereses para todos los tipos de cuenta
  • Manejo correcto de límites de zona horaria
  • Procesamiento de transacciones fallidas
  • Precisión en la generación de estados de cuenta
  • Disponibilidad del sistema durante y después del procesamiento batch

Testing de Cumplimiento Regulatorio

El software financiero opera bajo marcos regulatorios estrictos que moldean directamente la estrategia de testing.

PCI DSS (Payment Card Industry Data Security Standard)

PCI DSS gobierna cómo se almacenan, procesan y transmiten los datos de tarjetahabientes:

  • Los números de tarjeta deben estar enmascarados en todas las pantallas y logs (mostrar solo los últimos 4 dígitos)
  • Los datos deben estar encriptados en tránsito (TLS 1.2+) y en reposo (AES-256)
  • Los controles de acceso deben restringir los datos de tarjetas solo a personal autorizado
  • Las pistas de auditoría deben registrar cada acceso a datos de tarjetas

SOX (Ley Sarbanes-Oxley)

SOX requiere que los sistemas de reportes financieros tengan controles internos adecuados:

  • Todos los cambios en sistemas financieros deben ser auditables
  • Separación de funciones — quien escribe código no puede desplegarlo a producción
  • Verificaciones de integridad de datos en reportes financieros

PSD2 y Open Banking

La Directiva de Servicios de Pago de la UE requiere que los bancos abran sus APIs a proveedores terceros:

  • La Autenticación Fuerte del Cliente (SCA) debe ser testeada
  • Seguridad de APIs y limitación de velocidad
  • Gestión de consentimiento y controles de intercambio de datos
graph LR A[Solicitud del Usuario] --> B[Verificación de Fraude] B --> C[Autorización] C --> D[Core Bancario] D --> E[Cámara de Compensación] E --> F[Liquidación] F --> G[Reconciliación] B -.->|QA: Motor de reglas| B C -.->|QA: Límites, auth| C D -.->|QA: Actualización saldo| D F -.->|QA: Coincidencia montos| F G -.->|QA: Cross-system| G

Requisitos KYC/AML

Los requisitos de Know Your Customer y Anti-Lavado de Dinero exigen:

  • Flujos de verificación de identidad
  • Monitoreo de transacciones para patrones sospechosos
  • Screening de listas de sanciones
  • Reporte de transacciones grandes o inusuales

Técnicas Avanzadas de Testing Bancario

Testing de Integración de Pasarelas de Pago

Las pasarelas de pago conectan comercios con redes de tarjetas. El testing debe cubrir:

  • Múltiples tipos de tarjeta (Visa, Mastercard, Amex) con diferentes reglas de procesamiento
  • Flujos de autenticación 3D Secure (desafío y sin fricción)
  • Capturas parciales, reembolsos y contracargos
  • Failover de pasarela — ¿qué pasa cuando la pasarela principal está caída?
  • Idempotencia — solicitudes duplicadas no deben crear cargos duplicados

Testing de Mensajes SWIFT y SEPA

Las transferencias internacionales usan formatos de mensaje estandarizados:

  • Mensajes SWIFT MT (MT103 para transferencias de clientes, MT202 para banco a banco)
  • Transferencias de Crédito SEPA y Débitos Directos para pagos en la UE
  • Validación de mensajes contra esquema y reglas de negocio
  • Seguimiento end-to-end a través de múltiples bancos corresponsales

Liquidación Bruta en Tiempo Real (RTGS)

Las transferencias de alto valor se liquidan individualmente y en tiempo real:

  • Testear finalidad de liquidación — una vez liquidada, una transacción no puede revertirse
  • Gestión de liquidez — verificar que el banco tenga fondos suficientes en la cuenta de liquidación
  • Manejo de timeouts para liquidaciones no confirmadas

Recuperación ante Desastres para Sistemas Financieros

Los sistemas financieros tienen tolerancia casi nula al downtime:

  • Recovery Point Objective (RPO): ¿cuántos datos se pueden perder? (típicamente cero para transacciones)
  • Recovery Time Objective (RTO): ¿qué tan rápido debe recuperarse el sistema?
  • Testear failover a centros de datos de respaldo con verificación de transacciones en vivo

Ejercicio Práctico

Diseña un plan de testing para una función de transferencia bancaria en línea. Cubre estas áreas:

  1. Happy path: Transferir $100 de cuenta corriente a ahorros, verificar que ambos saldos se actualicen correctamente
  2. Valores límite: Monto cero, un centavo ($0.01), límite máximo de transferencia, un centavo sobre el máximo
  3. Cross-currency: Transferir USD a cuenta en EUR, verificar aplicación del tipo de cambio y redondeo
  4. Transferencias concurrentes: Dos transferencias desde la misma cuenta enviadas simultáneamente — verificar que no hay sobregiro
  5. Cumplimiento PCI DSS: Verificar que los números de cuenta estén enmascarados en confirmación, logs y notificaciones
Guía de Solución

Casos de prueba happy path:

  • Verificar que la cuenta origen se debitó por el monto exacto
  • Verificar que la cuenta destino se acreditó por el monto exacto
  • Verificar que la transacción aparece en el historial de ambas cuentas
  • Verificar que se envió notificación de confirmación con números de cuenta enmascarados

Casos de prueba de valores límite:

  • Transferencia de $0.00: debe ser rechazada con mensaje de error claro
  • Transferencia de $0.01: debe tener éxito, verificar que no hay errores de redondeo
  • Límite máximo (ej., $50,000): debe tener éxito
  • $50,000.01: debe ser rechazada con mensaje de límite excedido

Test de concurrencia:

  • Saldo de cuenta: $1,000
  • Enviar simultáneamente: Transferir $600 a Cuenta B, Transferir $600 a Cuenta C
  • Esperado: Una tiene éxito, la otra falla por fondos insuficientes
  • Verificar que el saldo final es correcto sin importar cuál tuvo éxito

Tips Profesionales

  1. Nunca uses punto flotante para dinero en datos de prueba — usa tipos decimales exactos o centavos enteros
  2. Testea reglas de redondeo explícitamente — el redondeo bancario (round half to even) difiere del estándar
  3. Siempre testea con múltiples monedas incluyendo las de 0 decimales (JPY), 2 (USD) y 3 (BHD)
  4. Verifica que las pistas de auditoría registren cada detalle de transacción: quién, qué, cuándo, desde dónde y el estado antes/después
  5. Testea el procesamiento batch de fin de día con volúmenes de datos realistas, no solo un puñado de cuentas de prueba

Conclusiones Clave

  1. El software financiero exige precisión matemática — nunca uses punto flotante para cálculos de dinero
  2. El cumplimiento regulatorio (PCI DSS, SOX, PSD2) no es opcional y moldea toda la estrategia de testing
  3. El testing de concurrencia y reconciliación son las dos áreas más críticas en QA bancario
  4. Las pistas de auditoría deben ser completas e inalterables — testea su completitud y precisión