Quién le debe a quién después de una transferencia P2P: la ruta del dinero y de las obligaciones

Analicemos una operación hipotética: a las 12:04 el cliente transfirió 10 000 unidades monetarias. El trader ve el abono, el operador envió al comercio «pagado» y la tienda entregó el producto. Pero los 10 000 siguen en la cuenta del receptor. ¿Quién tiene ahora el dinero, quién debe al comercio y qué protege exactamente a la tienda si el trader desaparece? Un estado en verde no responde a ninguna de estas preguntas.

En el procesamiento P2P es especialmente importante separar el movimiento físico del dinero del nacimiento de las obligaciones. Un mensaje puede recorrer toda la cadena en un segundo y la liquidación producirse por la noche. Entre ambos momentos, alguien está financiando de hecho a los demás. Si ese rol no se nombró de antemano, suele descubrirse con la primera liquidación atascada.

Primero definamos el modelo

Bajo el nombre P2P existen diseños distintos. En un exchange, comprador y vendedor intercambian dinero fiat por un activo digital, y la plataforma gestiona la retención del activo prevista en sus reglas. En un proceso de pago con licencia, los participantes reciben o transfieren fondos en roles autorizados. Una red informal de transferencias a cuentas personales de terceros es un diseño aparte, con sus propios riesgos legales y bancarios. Tener una API y un depósito de garantía no la convierte en un servicio de pago autorizado.

A continuación se analiza un modelo de recaudación hipotético y transparente: los contratos y los bancos admiten esa forma de trabajo, el receptor está identificado, el operador está facultado para incorporar a ese participante y el cliente conoce la finalidad de la transferencia. La palabra «trader» designa al participante contractual que ejecuta la operación. Sus obligaciones las define el acuerdo; no se afirma que cualquier plataforma P2P de un exchange permita cobrar en nombre de una tienda ajena. Las cifras sirven para analizar la mecánica y no describen la tarifa de ningún servicio concreto.

Antes de mostrar los datos de pago nace la primera reserva

El comercio crea un pedido de 10 000. El operador guarda el identificador del pedido, la moneda, el importe, el plazo de vigencia y la tarifa acordada. Luego elige al ejecutor adecuado y verifica el método de pago autorizado, la disponibilidad de la cuenta, los límites y la garantía. Al mismo tiempo se reserva capacidad para esa orden. Solo después de una reserva exitosa se entregan al cliente los datos de pago concretos y las instrucciones.

Supongamos que la comisión del comercio es de 400, de los cuales 150 son para el trader y 250 quedan para el operador. Si la operación se completa, al comercio le corresponden 9 600. Si la remuneración del trader se retiene del dinero recaudado, su futura transferencia al operador será de 9 850. El contrato puede fijar la reserva por el importe completo de 10 000 o por otra exposición. Para nuestro ejemplo elegimos 10 000: se reserva un importe concreto, no un «hueco» arbitrario.

En este momento el dinero del cliente todavía no existe. La reserva limita las nuevas asignaciones al trader, pero no prueba el pago ni genera ingresos. Una orden sin usar puede vencer. El sistema debe conservar el rastro de los datos de pago entregados: el cliente puede enviar la transferencia incluso después de cerrar la pantalla.

Tras el abono bancario aparecen deudas distintas

El cliente envía la transferencia desde su fuente admisible. El participante confirma la recepción con los datos bancarios y verifica el importe, la moneda y el vínculo con la orden. En nuestro modelo, el operador asume la obligación con el comercio tras esa verificación. Es una condición contractual del ejemplo: otro proveedor puede prometer la liquidación solo después de recibir el dinero en su propia cuenta.

Ahora el trader tiene 10 000 en fiat y debe transferir 9 850 al operador. El operador le debe 9 600 al comercio. La diferencia de 250 es su remuneración antes de sus propios gastos, y 150 son la remuneración del ejecutor. En la contabilidad del operador aparecen un derecho de cobro frente al trader y una obligación con la tienda. Eso no significa que el dinero ya esté en la cuenta bancaria del operador.

La notificación al comercio tiene un sentido de negocio: el pago se reconoció según la regla acordada y el pedido puede ejecutarse. La notificación en sí no es una transferencia bancaria. Su identificador se vincula a la orden, al registro del ingreso, a la versión de la tarifa y al momento en que se reconoció la obligación. Una notificación repetida debe remitir al mismo reconocimiento y no crear otra deuda de 9 600.

Dónde está la garantía en este esquema

Supongamos que el trader aportó de antemano una garantía por valor de 30 000. Antes de la operación se registraba aparte de los cobros de clientes. Tras entregar los datos de pago, se reservaron 10 000 de capacidad disponible. Confirmar el pago no libera necesariamente esa reserva: si el trader todavía tiene el fiat recaudado, el riesgo de liquidación frente al operador sigue existiendo.

En el modelo elegido, la reserva se mantiene hasta que se confirma la transferencia de 9 850 y se cumplen las demás condiciones de liberación. Si el sistema devuelve toda la capacidad en cuanto se pulsa «recibido», sin un límite de deuda aparte, la misma garantía permite acumular sin fin una deuda todavía no saldada. Eso ya es otro modelo de crédito, que necesita límites propios y una aceptación consciente del riesgo.

La garantía solo puede compensarse contra la obligación con un fundamento previsto. Además, la deuda no debe saldarse dos veces: con la transferencia de liquidación acreditada y con un débito paralelo de la garantía. Ambas operaciones se vinculan a una misma exposición. Un activo digital congelado tampoco puede considerarse automáticamente fiat disponible para pagar a la tienda.

La liquidación de la noche cierra la cadena del dinero

El trader transfiere 9 850 por la ruta de liquidación acordada. El operador coteja el ingreso real con el registro, reduce el derecho de cobro frente al trader y libera la garantía correspondiente si no hay otras retenciones. Después paga 9 600 al comercio. Una vez confirmado el pago, la obligación con la tienda se cierra; al operador le quedan 250 antes de gastos y al trader, 150.

Si el operador pagó a la tienda a las 12:10 y recibió la liquidación del trader a las 18:00, esas cinco horas y cincuenta minutos se financiaron con su propia liquidez disponible o con una fuente de financiación autorizada. El balance de obligaciones pudo cuadrar todo ese tiempo. Mientras tanto, el saldo de caja disminuía. Por eso la frase «todo está cubierto con depósitos» no basta para evaluar la capacidad de pagar según el calendario.

En una liquidación por lotes, una sola transferencia bancaria puede cerrar varias órdenes, comisiones y ajustes acordados previamente. La imputación se hace según el detalle del registro. Buscar una transferencia exactamente por el importe de una operación de cliente concreta generará aquí una falsa alarma, y asignar todo el importe al primer pedido parecido arruinará los saldos de los demás.

Otro modelo: se debita el saldo operativo

También existen diseños con un saldo operativo prepagado. Veámoslos por separado: el trader tenía un derecho de cobro de 1 000 USDT frente al operador, y el tipo de cambio acordado para el ejemplo es de 100 unidades de liquidación por USDT. Tras recibir 10 000 en fiat, se debitan del saldo operativo 98,5 USDT, equivalentes a 9 850. El derecho de cobro del trader frente al operador baja a 901,5 USDT, y el fiat recibido queda en poder del trader. Al comercio se le reconocen 9 600 según las condiciones de liquidación; el operador todavía necesita liquidez adecuada para el pago real.

En este segundo modelo no hay una nueva transferencia de esos mismos 9 850 en fiat: la liquidación económica ya se realizó al reducir el derecho de cobro operativo. Una reserva de garantía fija aparte no tiene por qué consumirse. Si se mezclan ambos diseños, se obligará al trader a liquidar dos veces. Además, el saldo interno puede ser un simple derecho de cobro frente a la empresa, incluso sin garantía; una pantalla bonita no prueba la custodia segregada de los activos ni el derecho a retirarlos de inmediato.

Si entre las partes hay un enrutador

Un intermediario técnico puede transmitir la orden y los estados sin recibir dinero y sin convertirse en deudor del comercio. Por ejemplo, PayStar describe expresamente el cálculo del pago esperado como una función de control y mantiene la obligación de liquidar en el PSP, según el contrato directo. En otra cadena, los roles se verifican de nuevo. Varios logotipos en el panel no equivalen a varias fuentes independientes de liquidez.

Si en nuestro primer ejemplo el operador le paga a ese intermediario 50 de sus propios 250, le quedan 200 antes de los demás gastos. La deuda con la tienda sigue siendo de 9 600, y la obligación por el servicio técnico es otra, de 50. Por el intermediario puede pasar el mensaje de cada pago, aunque el dinero de los clientes no pase por él en absoluto. Su responsabilidad por el enrutamiento y los datos no equivale a una garantía de devolución de todos los fondos.

Tres puntos donde la cadena suele romperse

El trader confirmó el dinero, pero la liquidación no llegó: queda abierta su obligación y hace falta el procedimiento de cobro o de ejecución de la garantía previsto en el contrato. El operador recibió la liquidación, pero no pagó al comercio: el problema está del lado del operador, aunque la transferencia original del cliente haya pasado por otro participante. La tienda recibió la notificación, pero el ingreso bancario no se confirma: primero se establece el motivo del reconocimiento erróneo, después se registra el ajuste y se reparte la responsabilidad.

Para cada orden conviene poder reconstruir una única respuesta coherente: quién recibió los fondos del cliente; quién reconoció el pago y con qué fundamento; quién debe dinero ahora; qué respalda ese derecho de cobro; con qué transferencia real se cerró. Si cualquier tramo del esquema se sustituye por la palabra «socio», la transparencia financiera termina justo ahí.