Arquitectura fintech: los puntos no negociables

En la mayoría del software un bug es un incidente. En fintech un bug es un pasivo que puede haber costado dinero que nadie ha notado todavía.

La arquitectura fintech tiene un número pequeño de decisiones genuinamente no negociables. Si las equivocas, ninguna cantidad de ingeniería posterior lo recupera del todo — heredas un sistema donde el dinero puede estar silenciosamente mal, que es el único modo de fallo que un producto financiero no puede absorber.

1. Los saldos se derivan, nunca se almacenan como verdad

El error más común y más dañino es una columna de saldo mutable que el código actualiza directamente. Es cómoda, rápida e irrecuperable: cuando se desvía, no hay forma de determinar cuál debería haber sido.

El modelo correcto es un diario de asientos append-only. Nada se actualiza ni se borra nunca; las correcciones son nuevos asientos compensatorios. El saldo es la suma de los asientos, cacheado por rendimiento pero siempre reconstruible desde el diario.

2. Toda ruta de dinero es idempotente

Las redes reintentan. Los usuarios hacen doble clic. Los proveedores de pago entregan webhooks más de una vez — es comportamiento documentado, no un caso límite. Cualquier operación que mueva dinero debe ser segura de ejecutar repetidamente.

• Cada operación de dinero lleva una clave de idempotencia suministrada por quien llama, única por intención lógica
• La clave se guarda con restricción de unicidad antes de los efectos secundarios, no después
• Una clave repetida devuelve el resultado original en vez de rehacer el trabajo
• Los manejadores de webhook guardan el payload crudo indexado por el id de evento del proveedor y luego procesan — así una reentrega se reconoce incluso a mitad de procesamiento

3. El dinero son enteros en unidades menores

El coma flotante no puede representar fracciones decimales de forma exacta, así que la aritmética sobre dinero en float acumula error. Guarda unidades menores como enteros (o un tipo decimal de precisión fija) y haz la divisa explícita en cada importe — un importe sin divisa es un bug esperando a un cliente internacional.

4. La conciliación es una funcionalidad, no una ocurrencia tardía

Asume divergencia entre tu libro mayor y el proveedor de pago — ocurrirá, por timeouts, fallos parciales y correcciones del lado del proveedor. La pregunta es si la detectas.

• Un job programado que compara el estado interno con los datos de liquidación del proveedor
• Alertas ante discrepancia, con responsable definido y runbook
• Una vía de resolución definida — asientos compensatorios, nunca ajuste silencioso
• Barridos de estados atascados: transacciones pendientes más tiempo del que deberían

5. Aislamiento, en los dos sentidos

• Aislamiento de tenants — impuesto en la capa de datos, no confiando en que cada consulta incluya el filtro correcto
• Aislamiento de fallos — un proveedor lento no debe agotar el pool de peticiones y tumbar funcionalidad sin relación
• Aislamiento de entornos — jamás transacciones de prueba en libros mayores de producción

6. Construye para la auditoría que acabarás enfrentando

No. Aporta hallazgos técnicos dentro del alcance acordado. La interpretación jurídica y certificación formal requieren profesionales cualificados para esas funciones.

• Rastro de auditoría inmutable de quién hizo qué y cuándo — incluidas las acciones de administración internas
• Datos de tarjeta que nunca tocan tus servidores salvo que realmente pretendas ser PCI-compliant (usa campos alojados o página alojada)
• Retención y borrado de datos que se puedan ejecutar de verdad a petición
• Control de acceso revisable — quién puede mover dinero, quién lo aprobó

En software ordinario optimizas para velocidad de cambio. En fintech optimizas para poder demostrar, después, exactamente qué pasó y por qué.

Las cinco preguntas para tu propio sistema

1. Si este webhook llega dos veces, ¿cambia algo la segunda vez?
2. ¿Puedo reconstruir el saldo de cualquier cliente en cualquier momento pasado solo desde el libro mayor?
3. ¿Detectaríamos una discrepancia con el proveedor, o nos lo diría un cliente?
4. ¿Puede una petición manipulada leer o mover el dinero de otro tenant?
5. Si un regulador preguntara quién aprobó un ajuste manual en marzo pasado, ¿podríamos responder en minutos?

Separar aceptación y liquidación de transacciones

Los estados de pago deben permitir conciliar eventos tardíos y repetidos. Verifica registros financieros y proceso de corrección.

1. Usar decimales exactos o unidades enteras con reglas monetarias.
2. Correlacionar eventos y apuntes sin contabilizar dos veces los reintentos.
3. Conservar originales y registrar correcciones autorizadas.

• auditoría técnica fintech →