3. Integración Bancaria y Tolerancia a Fallos (On/Off-Ramp)

Torrente opera estratégicamente en la frontera operativa entre el ecosistema financiero descentralizado (DeFi) y el sistema financiero tradicional (TradFi). Esta interfase transaccional, conocida como On/Off-Ramp, representa la superficie de mayor riesgo y el punto crítico de falla de la plataforma, particularmente al interactuar con las infraestructuras de Interfaz de Programación de Aplicaciones (API) de instituciones bancarias en mercados emergentes como Venezuela, donde los sistemas de liquidación bruta en tiempo real, como el Pago Móvil o las transferencias interbancarias, presentan inestabilidades documentadas.

3.1. Conciliación de Entradas (Inbound) y Deduplicación

Los sistemas bancarios legados que interactúan con plataformas fintech frecuentemente emiten webhooks de notificación de pagos que llegan duplicados, fuera de orden cronológico, o experimentan tiempos de inactividad intermitentes que retrasan severamente la liquidación de la información. Cuando un usuario minorista efectúa un depósito mediante la red de Pago Móvil, la infraestructura bancaria dispara un evento HTTP hacia la pasarela de Torrente.

Para imposibilitar la acreditación de los mismos fondos monetarios en múltiples ocasiones, la capa de recepción (Inbound) implementa una barrera de deduplicación determinista e infranqueable. Al recibir la carga útil entrante, Torrente sintetiza un hash criptográfico canónico del pago basándose en la concatenación inmutable del número de referencia bancaria, la marca de tiempo de la red y el monto transado.

La base de datos relacional utiliza restricciones de unicidad (UNIQUE) acopladas a comandos de inserción condicional nativos (ON CONFLICT DO NOTHING) para neutralizar colisiones:

INSERT INTO processed_events (event_id, event_type, status, payload)
VALUES (:bank_reference, 'pago_movil_inbound', 'processing', :json_payload)
ON CONFLICT (event_id) DO NOTHING;

Si el servidor bancario, en un intento de sortear un falso error de latencia, transmite el mismo webhook por triplicado en una ventana de pocos segundos, únicamente el primer hilo de ejecución adquirirá el bloqueo en la base de datos, procesará los asientos contables en el Core Ledger y consolidará el saldo del usuario. Las dos peticiones posteriores chocarán contra el muro del índice único y fallarán silenciosamente, protegiendo al ecosistema de una inflación artificial y catastrófica de los saldos internos. Adicionalmente, dado que la estructura de la carga útil del webhook suele sufrir alteraciones no planificadas o adición de campos espurios por parte de los proveedores de integración, Torrente confina esta información variable utilizando el tipo de datos JSONB de PostgreSQL. Este enfoque dicotómico mantiene un esquema altamente flexible en los bordes de integración para asimilar estructuras de terceros, mientras preserva una rigidez relacional absoluta en el núcleo contable para atributos fundamentales como identidad, dinero y fechas.

3.2. Motor de Desembolso (Outbound) y Throttling Dinámico

El flujo monetario de salida (Outbound) acarrea un perfil de riesgo estadísticamente superior al de entrada. Cuando un usuario solicita el retiro de su capital, Torrente debe orquestar una instrucción hacia su cuenta bancaria concentradora corporativa para que esta, a su vez, despache una transferencia electrónica al beneficiario final. Las APIs bancarias imponen límites de tasa (rate limits) inflexibles con el fin de prevenir abusos informáticos, denegaciones de servicio y mitigar el riesgo de liquidez sistémica.

Si la plataforma Torrente intentara transmitir simultáneamente miles de solicitudes de desembolso hacia la API del banco en un momento de alta concurrencia, la infraestructura bancaria respondería invariablemente con códigos de error HTTP 429 (Too Many Requests), o en el peor de los escenarios, ejecutaría un bloqueo preventivo temporal de la credencial criptográfica corporativa de Torrente. Para gobernar y modular este tráfico saliente, el Motor de Desembolso emplea un sofisticado algoritmo de estrangulamiento de red (Throttling) basado en el paradigma de Token Bucket (Cubeta de Tokens).

Bajo este modelo, el sistema de colas internas genera y asigna “tokens” virtuales a una tasa matemáticamente constante que calza con el límite máximo de tolerancia admitido por la API del banco emisor (por ejemplo, exactamente cinco transacciones por segundo). Cada orden individual de desembolso saliente debe consumir un token de la cubeta para ser autorizada a viajar por la red. Si el volumen de retiros vacía la cubeta, las solicitudes de desembolso excedentes no son rechazadas ni descartadas, sino que se encolan o se retrasan dinámicamente aplicando una estrategia de retroceso exponencial iterativo (exponential backoff). Este mecanismo hidrodinámico suaviza los picos de peticiones masivas, garantizando el cumplimiento continuo de los límites perimetrales externos sin comprometer ni extraviar una sola solicitud del usuario.

3.3. Máquina de Estados de Idempotencia

El escenario de fallo más crítico y destructivo para la confianza en un sistema de pagos distribuidos es la ambigüedad de estado de red durante la ejecución de un desembolso. Supóngase que Torrente envía la orden de transferencia cifrada al banco centralizador; durante la transmisión de la respuesta, ocurre un tiempo de espera de red (timeout) severo y el servidor bancario queda incomunicado. El sistema interno enfrenta un dilema: ¿se procesó efectivamente la transferencia o fue rechazada? Si la plataforma asume erróneamente un fallo y retransmite la orden, el usuario minorista podría recibir los fondos por duplicado, incurriendo en un evento de doble gasto sistémico. Si, a la inversa, asume un éxito ilusorio, el usuario sufrirá la pérdida de su capital sin recurso inmediato.

Para erradicar esta incertidumbre, el núcleo de Torrente opera a través de una inquebrantable Máquina de Estados de Idempotencia.

1. Milisegundos antes de iniciar cualquier contacto de red con la institución bancaria, el estado de la solicitud de desembolso en las tablas de Torrente muta a PENDING_NETWORK_REQUEST y el saldo equivalente en la cuenta del usuario es inmediatamente pignorado (bloqueado contablemente).
2. La carga útil enviada al banco incluye imperativamente un identificador único global (Clave de Idempotencia o external_id), generado unívocamente por el orquestador de Torrente para esa transacción específica.
3. Si se materializa un timeout de red, el proceso de supervisión de demonios de Torrente tiene prohibido generar una nueva solicitud de pago. En su defecto, inicia un ciclo de sondeo pasivo (polling) interrogando específicamente el estado de ese external_id contra el endpoint de conciliación del banco.
4. Únicamente ante la recepción de un fallo duro, terminal y confirmado explícitamente por el sistema bancario, la máquina de estados transita hacia FAILED y, solo entonces, libera el saldo pignorado devolviéndolo a la disponibilidad del usuario. En cualquier otro escenario de duda o latencia persistente, el estado permanece bloqueado, escalando a una conciliación manual de fin de día, lo cual garantiza matemáticamente que una orden de retiro jamás pueda resultar en una duplicación de fondos.

Conclusión del capítulo

La integración bancaria y la tolerancia a fallos son centrales para la viabilidad operativa de Torrente. La plataforma combina deduplicación, rate limiting, idempotencia y conciliación para reducir al mínimo los errores de liquidación que podrían afectar la confianza del usuario.