Cuando las transferencias se revierten

Cuando tu banco dice que salió dinero de tu cuenta, no siempre significa que llegará a destino. Incluso si son transferencias "instantáneas".

No es que pase siempre, pero pasa a veces.

En Shinkansen vemos pasar cientos de miles de transferencias mensuales, así que un caso excepcional que ocurra con 0.01% de probabilidad es algo que podemos ver ocurrir varias veces por semana.

¿Cómo es posible que una transferencia instantánea se revierta? Si uno lo piensa como mover un billete de un lado a otro de manera instantánea, pues no debiera pasar. El billete está en un lado o en el otro. No hay billetes de Schrödinger.

Pero la verdad es que la gran mayoría de transferencias no son realmente instantáneas. Es fácil intuirlo si pensamos que estás transfiriendo dinero desde un banco (o institución financiera) a otro banco (y vamos a seguir diciendo "banco" para evitarnos estos paréntesis a cada rato, pero ya saben que pueden ser otras instituciones financieras también).

La transferencia "instantánea" es en realidad un mensaje que viaja del banco A al banco B. Y como el banco B puede rechazar una transferencia (ej: número de cuenta está equivocado) entonces necesitamos un mensaje de vuelta.

Por suerte en la era de internet los mensajes pueden viajar realmente rápido. Cuando todo funciona perfecto, en pocos milisegundos el banco B le respondió al banco A y le dijo "perfecto, recibido" o "no puedo tomar tu dinero porque hay un error". Para nosotros los humanos, se percibe instantáneo.

Lo malo es que no siempre ocurre el caso feliz. A veces el banco A se va a demorar en enviar mensaje (quizás tiene mucha carga). Otras veces el banco B se va a demorar en la respuesta. En la realidad suele haber uno o más intermediarios entre A y B, que también se pueden demorar.

La ilusión de instantaneidad se derrumba. Aparecen las reversas. Desde el lado de quien envió dinero, su estado de cuenta puede verse así:

- $500: Transferencia hacia cuenta 123 en Banco B
+ $500: Reversa de transferencia hacia cuenta 123 en Banco B

No se ve fantástico, pero tampoco es terrible. El billete salió pero volvió (porque el banco A suele descontar el monto antes de enviar el mensaje al banco B, para evitar race conditions que generen saldos negativos).

Como las empresas normalmente hacen muchas transferencias a la vez en un "lote" o "batch" (pagan muchos sueldos, o a muchos proveedores), ese estado de cuenta puede ser menos obvio:

- $1500: Batch de varias transferencias
+ $ 500: Reversa de una transferencia que falló

Aquí se pone mas difícil todo. Si el batch tenía tres transferencias de $500, no es evidente cual de las 3 falló. Imagínate con varios de 1000 transacciones donde 15 fallen. Muchas empresas sólo se enteran porque su destinatario reclama 😅.

🚄 Con Shinkansen Payouts nuestros clientes automatizan todo tipo de transferencias y reciben una notificación prácticamente inmediata indicando cuáles transferencias específicas han funcionado y cuáles han fallado. Luego nuestra conciliación operacional cuadra todas esas operaciones automatizadas contra los movimientos en los estados de cuenta. Junto con automatizar el movimiento de dinero, ahorramos dolores de cabeza cuadrando estas reversas.

Ahora, lo realmente malo es cuando al receptor le ocurre esto:

+ $500: Transferencia recibida desde el banco A
- $500: Reversa de transferencia recibida

Por un breve instante la transferencia fue aceptada por el banco B y luego hubo que deshacer el movimiento. Que aparezca así en tu estado de cuenta es mejor, porque (dependiendo del banco) podría pasar que el movimiento por +$500 aparece por algunos segundos y después simplemente desaparece 😱.

¿Por qué puede pasar esto? Lo veremos en futuros posts donde entraremos al detalle de algunos rieles que provocan estos casos excepcionales. Lo importante — y que muchas áreas de tesorería u operaciones descubren simplemente cuando les ocurre por primera vez — es que puede pasar.

Y cuando pasa es un problema si hay personas (o robots) mirando los movimientos para reconocer ingresos o conciliar pagos. Si justo vieron el +$500 sin que todavía se haga el movimiento de -$500 (o simplemente ignoraron que mas abajo había una reversa) entonces se aceptará un pago o se acreditará un abono erróneamente. Rara vez pasa, pero cuando pasa puede ser enorme dolor de cabeza.

🚄 Con Shinkansen Payin Notifications nuestros clientes también reciben notificaciones de cada reversa. Y estas operaciones son parte de la conciliación operacional que cuadra estas notificaciones con los movimientos de los estados de cuenta.

¿Cómo debemos manejar estas reversas en nuestras aplicaciones?

La verdad, depende. En Shinkansen tenemos modos de operación en que (a veces) podemos abstraer a tu aplicación de las reversas. En base a lo que sabemos de cómo operan los rieles por donde viajan estos mensajes, podemos determinar cuando una transacción es realmente "final". Pero otras veces vas a preferir ver pasar las reversas y manejarlas.

Para eso puede ser útil entender mejor como funcionan los rieles de transferencias en cada país. Es lo que cubriremos en futuros posts para México 🇲🇽 (SPEI), Chile 🇨🇱 (TEF) y — si hay interés — otros países como Perú 🇵🇪, Brasil 🇧🇷 y Colombia 🇨🇴.

PD 1: Para quienes vienen del mundo de tarjetas, me suelen preguntar si las reversas son contracargos o rechazos. La verdad es que esos términos están pensados en el mundo en que el dinero se cobra y por ende estamos "tirando" (pull) el dinero desde la cuenta de un tarjetahabiente hacia la cuenta de un merchant. Allí entonces el contracargo se genera ante el desconocimiento de un pago o insatisfacción con la entrega del producto o servicio. Y el rechazo ocurre cuando la entidad emisora no permite continuar con la transacción por ejemplo por razones de riesgo de fraude. En este otro mundo el dinero se está "empujando" (push) desde una cuenta A a una cuenta B, por lo que las "reversas" son mucho mas operativas y se deben a casos excepcionales o de error. Pero ya veremos en los artículos más específicos más detalle.

PD 2: Una gran ironía de la vida es que el caso de las cuentas bancarias se usa en las clases de bases de datos para enseñarnos la atomicidad en las transacciones de bases de datos (la A de ACID). Lo malo es que cada banco tiene su(s) propia(s) base(s) de datos. Si todos usaran la misma, quizás funcionaría. Pero hasta en Bitcoin (con su blockchain, que es una base de datos global en que se puede programar el dinero) hay riesgo de que te puedan revertir una transacción (si llevas pocas confirmaciones). En escala, no hay como escapar de las reversas 🤷🏻‍♂️.