Un límite libre, dos órdenes: cómo se reparte la capacidad del trader

Analicemos una carrera hipotética de solicitudes por la capacidad del trader. A las 14:00:00, dos hilos de procesamiento leyeron el mismo saldo libre: 12 000. Cada uno recibió una orden de 8 000, comprobó la condición «hay dinero suficiente» y entregó al cliente los datos de pago. Por separado, ambas decisiones parecían correctas. Juntas crearon obligaciones por 16 000 con un margen disponible de 12 000.

No se trata necesariamente de un fraude del trader ni de un retraso del saldo bancario. Basta con separar la verificación del saldo y su reserva en dos operaciones independientes. Por fuera, el sistema funcionará con normalidad hasta que las órdenes lleguen lo bastante juntas. En un flujo P2P, este error se agrava por el tiempo que pasa entre la entrega de los datos de pago, la transferencia real y la confirmación de recepción.

La capacidad se compone de varias restricciones

La orden tiene un importe, una moneda, un método de pago y un plazo de ejecución. El trader tiene una garantía disponible o un saldo operativo de liquidación, cuentas autorizadas, un límite de órdenes simultáneas y disponibilidad operativa. Cada cuenta tiene sus propios importes admisibles, restricciones del banco y un volumen ya ocupado. El operador puede tener además límites contractuales por participante y para todo el grupo de ejecutores vinculados.

Ninguno de estos parámetros sustituye a los demás. Un depósito grande no permite superar el límite bancario. Un saldo bancario libre no significa que el saldo de liquidación prepagado alcance para reconocer un nuevo cobro. Que el contador permita procesar una orden más no sirve de nada si el único canal disponible no admite su moneda.

Para una misma categoría homogénea de operaciones, el margen monetario lo limita la restricción monetaria más estrecha. Pero el contador de órdenes paralelas y el rango de importes admisible siguen siendo condiciones aparte. No se pueden sumar sin más los saldos de distintas monedas ni suponer que dos huecos libres admiten automáticamente dos pagos de cualquier tamaño. El período de cada límite también se fija de forma explícita: día natural, ventana móvil, turno o toda la vigencia del contrato.

En una revisión pública en video del panel de Sprut, el autor muestra por separado el importe mínimo y máximo, el contador de operaciones y el límite total de la cuenta. En ese fragmento no se establece el período de los dos últimos. Esa demostración confirma que la descripción del panel incluye ajustes separados, pero no prueba la autorización bancaria, la corrección de las verificaciones del servidor ni el rendimiento real.

La decisión debe ocupar el recurso en el mismo instante

En el ejemplo de 12 000, la primera orden de 8 000 obtiene una reserva y quedan 4 000 disponibles. La segunda se verifica ya contra el nuevo estado y no pasa. Ese es el sentido de la reserva atómica: la verificación y el cambio de estado se registran como una única decisión indivisible. Su resultado incluye el identificador de la reserva, el importe, el titular y el plazo de vigencia.

Los registros de pagos implementan esta protección de distintas maneras. La documentación de Modern Treasury, por ejemplo, describe asientos condicionados al saldo resultante o a la versión de la cuenta. PostgreSQL ofrece bloqueos de fila para gestionar cambios concurrentes. Son mecanismos técnicos, no una política P2P lista para usar: el equipo todavía debe definir qué recursos cambian juntos y con qué evento se libera la reserva.

Si la asignación ocupa a la vez el saldo del trader, el saldo de la cuenta y un hueco, la ejecución parcial es peligrosa. Se registró la reserva de dinero, pero se perdió la asignación: el límite queda bloqueado. Se creó la orden, pero no se redujo el saldo: se produce una sobreasignación. Dentro de una misma transacción coherente, estos cambios ocurren juntos o no ocurren. Con varios sistemas hace falta un estado intermedio explícito y una recuperación que no entregue datos de pago hasta confirmar las reservas necesarias.

Repetir la solicitud no debe consumir una segunda porción

El comercio no recibió respuesta y repitió la creación. Si el pedido lógico es el mismo, el operador debe encontrar la reserva existente o terminar su creación de forma segura. Una nueva solicitud de red no justifica por sí sola una nueva orden para el mismo trader. De lo contrario, un comprador ocupará varios huecos y recibirá varios juegos de datos de pago, aunque pensaba pagar una sola vez.

Un resultado de asignación incierto es especialmente incómodo. El mensaje pudo llegar al ejecutor y la confirmación perderse. Hasta aclararlo, el recurso no puede considerarse a la vez libre para otro pedido y ocupado por el primero. El sistema guarda el identificador del intento, verifica el estado real y toma una sola decisión. Esa verificación necesita un responsable y un límite de tiempo; si no, la cola se llenará de eternos «casi asignado».

El operador ve las reservas atascadas por separado de la carga normal. Para ellas importan la antigüedad, el motivo, el último hecho verificado y el siguiente intento de recuperación. Liberar por temporizador es seguro solo en la medida en que se sepa qué hacer con los datos de pago ya entregados. El vencimiento de la reserva no puede anular una transferencia que el cliente ya envió.

Se liberó el hueco, pero el riesgo sigue ahí

Imaginemos que la orden venció a las 14:10, la reserva se liberó y a las 14:12 se detectó un ingreso bancario. El registro del dinero no desaparece por falta de límite libre. Pasa a ser una excepción: se confirman el origen y el destino, se determina la obligación y se restablece la distribución correcta del riesgo. Hasta decidir, puede ser necesario detener las nuevas asignaciones a ese participante.

La salida equivocada es considerar el dinero tardío como ingreso del operador o vincularlo automáticamente a la siguiente orden con el mismo importe. La salida correcta conserva el vínculo con la entrega original de los datos de pago. Si existe una ventana aparte para ingresos tardíos, su costo se incluye de antemano en el modelo de ocupación. De lo contrario, la «optimización» de liberar rápido el límite solo esconde el riesgo en la cola manual.

El depósito da colchón, la velocidad da rotación

Calculemos un rendimiento hipotético. Hay 300 000 de garantía utilizable, una orden típica de 10 000 y 12 huecos operativos paralelos. Procesar una orden hasta su confirmación lleva en promedio ocho minutos. La restricción de huecos permite en teoría 90 asignaciones por hora: 12 por 60 y dividido entre ocho. Con importes iguales, son 900 000 de flujo por hora antes de las demás restricciones.

Sin embargo, según el contrato, la garantía queda retenida hasta la liquidación, en promedio 40 minutos. Entonces 300 000 de cobertura con carga continua sostienen unos 450 000 de rotación por hora: 300 000 por 60 y dividido entre 40. Los huecos operativos podrían admitir más, pero la garantía vuelve más despacio. Es una estimación para un flujo estable y uniforme, no una promesa de rendimiento.

Si el volumen diario admisible restante del canal bancario es de 1 200 000, incluso ese ritmo lo agotará en unas dos horas y cuarenta minutos. Aumentar el depósito no cambiará el límite bancario. Y si el tiempo de liquidación sube a 80 minutos, la restricción de garantía bajará la estimación a 225 000 por hora, aunque el número de traders conectados siga siendo el mismo.

Qué debe verse en la pantalla de trabajo

Una pantalla útil de capacidad explica los rechazos: falta garantía, saldo operativo, liquidez de salida, volumen autorizado del canal, un hueco libre o la disponibilidad confirmada del participante. Al lado se ven la antigüedad de las reservas y la hora de liberación real. Un «no hay datos de pago» genérico oculta causas que exigen decisiones completamente distintas.

Las restricciones deben probarse con asignaciones simultáneas, solicitudes repetidas, caídas entre etapas, ingresos tardíos y cambios de período de liquidación. El objetivo es ejecutar el flujo autorizado dentro de los contratos y de las reglas bancarias. Eludir los límites fraccionando pagos o sustituyendo cuentas de forma opaca no corrige el modelo y crea riesgos nuevos. Un buen sistema sabe rechazar a tiempo una orden nueva y, al mismo tiempo, llevar hasta el final la que ya aceptó.