Hace unas semanas, durante una llamada con un importante socio potencial, surgió el tema de la disponibilidad de los fondos. El momento en que los fondos están disponibles para el destinatario en una transacción electrónica depende, en la mayoría de los casos, del tipo de transferencia que se utilice para el intercambio de dinero.

En EE. UU., hay muchos tipos de transferencia que no ofrecen disponibilidad inmediata de fondos, por lo que, a lo largo de los años, muchas empresas han resuelto ese problema creando una solución común.

Esa solución consiste en recurrir a un tercero que interviene para proporcionar liquidez, lo que permite al receptor acceder a los fondos al instante.

A continuación se describen los mecanismos básicos en un escenario normal sin un proveedor de liquidez que utilice los tipos de cliente de lDwolla. En este ejemplo, VCR1 es el remitente y VCR2 es el destinatario.

Dwolla Fund Flow

Este retraso habitual puede resolverse introduciendo a un tercero que proporcione liquidez, tal y como se ha mencionado anteriormente. Una forma menos técnica de expresarlo es que alguien adelantará el dinero al receptor y asumirá el riesgo de que el pago del remitente falle.

Un ejemplo de cómo se hace esto desde la perspectiva del flujo de fondos es el siguiente.

Dwolla Introduction of Liquidity Provider

VCR3 representa una nueva entidad no incluida en el flujo de fondos inicial. VCR3 es operada o es propiedad de un proveedor de liquidez. Cabe señalar que esto se ha simplificado en exceso con el fin de compartir el ejemplo. En realidad, VCR3 también podría ser gestionada por el propietario de la aplicación cliente, siempre y cuando el contrato entre el titular de la cuenta VCR3 y el propietario de la aplicación cliente lo permitiera.

¿Es esto realmente posible?

Ocurre a diario en sistemas de todo el mundo. A medida que las altas finanzas invaden el FinTech, o viceversa, esto ocurre cada vez con más frecuencia.

Entonces, ¿cuánto cuesta la liquidez?

Varía mucho. Algunas empresas recaudan fondos suficientes y obtienen las licencias adecuadas para poder financiarla fuera de su balance. Otra solución es asociarse con un banco y otra más es asociarse con un tipo diferente de proveedor de liquidez.

Aunque la economía puede variar, veamos tres posibles soluciones si la liquidez se financia aceptando el riesgo de transacción en forma de deuda a corto plazo. En este ejemplo hay tres escenarios de costes que veo habitualmente:

  1. Tipo de interés de los fondos federales. Este se situaba en el 0,25 % anual en el momento de escribir esto por primera vez. El tipo de interés de los fondos federales baja día a día.
  2. Una línea de crédito comercial. Supongamos un 6 % anual. Aunque el tipo de la Fed sea más bajo, las entidades no bancarias rara vez disfrutan de ese tipo.
  3. Algo más provocativo. Supongamos un 12 % anual. Estos son los tipos de interés que se ven con más frecuencia.

El coste depende del socio.

Un componente clave aquí es que la liquidez no se proporciona sobre una base anualizada, sino que se proporciona día a día. Cuando analizamos el coste real, es importante fijarse en cuánto dinero se concede y durante cuánto tiempo.

Cuando se empiezan a introducir entornos en tiempo real, se pueden desglosar los costes día a día, hora a hora, minuto a minuto y, sí... segundo a segundo.

El interés diario es importante en este escenario

En una transacción típica de «ACH», es posible que haya que lidiar con un retraso de dos días. Así que, si necesitas 1 millón de dólares (porque es una cantidad sencilla para este ejemplo), podrías utilizar una de las soluciones de socios que he mencionado anteriormente para financiar ese millón. Recuerda que la liquidez casi siempre se basa en una relación entre el proveedor de liquidez y el propietario de la aplicación.

Entonces, ¿quién asume el coste? El propietario de la aplicación cliente suele asumir el coste del programa que el proveedor de liquidez hace posible.

Dwolla Liquidity Provider

En resumen, si utilizamos los tipos de interés de los préstamos que he mencionado anteriormente, podemos suponer que 1 millón de dólares en liquidez supone unos 164,38 dólares al día al 6 %, devengados diariamente.

Para cubrir el intervalo de dos días, habría que pagar 328,76 dólares. Si se parte de una transacción media de unos 124 dólares, se podrían gestionar más de 8000 transacciones de consumidores al día y pagar al comerciante en tiempo real, tomando prestado el dinero y asumiendo el riesgo de la rentabilidad. Un matiz importante que hay que recordar es que el consumidor no está solicitando ningún préstamo. En este ejemplo, el consumidor es el beneficiario de que el propietario de la aplicación del cliente y el proveedor de liquidez asuman el riesgo para ofrecer una mejor experiencia de usuario y acceso instantáneo al dinero.

El coste de introducir la disponibilidad de fondos en tiempo real ya no es tan elevado como lo era antes.

Al 0,25 %, el coste de 164,38 $ al día se convierte en 6,85 $ al día. Con un plazo de 2 días, el coste es de 13,70 $ por cada 1 000 000 $.

Aquí están las cifras, por si quieres revisarlas. Son a efectos de demostración y no deben considerarse exactas. Hay una serie de variables que podrían alterar los costes reales.

LiquidezTasa anualCoste anual2 días1 díaPor horaPor minutoPor segundo
10 000 000 $0,55 %55 000301,37150,68 $6,280,1050,0017
1 000 0006,00 %60 000 $328,77164,386,850,1140,0019
1 000 000 $12,00 %120 000 $657,53328,77 $13,700,2280,0038 $
1 000 000 $20,00 %200 000 $1.095,89547,95 $22,830,3810,0063

Programación de elementos de riesgo

Cuando los sistemas permiten que diferentes partes asuman riesgos en tiempo real, podemos empezar a plantearnos quién podría estar pujando día a día, hora a hora, minuto a minuto y segundo a segundo. Aunque es emocionante, también resulta peligroso si se hace de forma irresponsable.

Si estás creando algo así, te recomiendo encarecidamente que contrates a un abogado especializado en tecnología que te ayude a estructurar tus relaciones. El aspecto técnico de mover el dinero es ahora la parte fácil. ¡Antes era al revés!