Hawala: descripción y funcionalidades
17 ago 2010
Características y procesos para optimizar redes familiares de pagos transnacionales
Desde el siglo IX las redes comerciales unidas a la emigración han generado sistemas de pago a larga distancia.
El mecanismo es sencillo: una serie de nodos {1,2,3,…,N} implantados en distintos territorios, reconocen cada uno a una serie de apoderados. El nodo 1 reconocería por ejemplo {a1,b1,c1,…,n1}, cada uno con distintos límites de crédito y el conjunto con un límite global de endedudamiento que es el máximo que el nodo 1 acepta tener como pasivo neto en ese trimestre.
Así, cuando a1 está en el territorio donde el nodo 2 desarrolla su actividad comercial, puede pedirle a este que le adelante una cierta cantidad, tras comprobar este que lo solicitado no excede el máximo que 1 otorga a a1 y que en conjunto, el nodo 1 no ha rebasado su capacidad trimestral de endeudamiento. Finalmente, cada trimestre, los nodos ajustan cuentas entre si minimizando el número de flujos en el conjunto de la red.
¿Cómo programamos esto?
Rompería el espíritu histórico de la hawala crear un software de este estilo que no fuera P2P y que cifrara las comunicaciones (hoy ya usando cifrados de clave asimétrica).
Variables a configurar por los usuarios
Cuando un nodo se diera de alta tendría que:
- Elegir una divisa para los detalles de pago. Aunque las transacciones se hagan siempre en la misma divisa internacional (de hecho simplifica mucho hacerlas en múltiplos de 500€), a1 recibirá de 2 el equivalente a su pedido en la divisa local (no en euros) el día que hizo el pedido al tipo de cambio de ese día.
- Fijar un máximo para su endeudamiento trimestral. Este no es el máximo de sus pasivos sino del balance entre activos y pasivos globales.
Cuando un nodo reconoce a otro nodo (1 reconoce a 2) fijaría además cual es el pago trimestral máximo que aceptaría hacerle. Como veremos más adelante esto no es igual que el crédito máximo que acepta dar a los suyos en el territorio de 2. Puede que 2 no preste a ningún usuario de 1 en el periodo, pero la optimización del número de pagos puede llevar a que se produzca un flujo entre 1 y 2.
Y finalmente cuando un nodo aceptara un usuario le otorgaría un máximo de crédito personal. El programa además cuidaría que un mismo usuario no pudiera estar adscrito a más de un nodo.
Mecanismo de crédito
Cuando a1 solicita dinero a 2 el programa comprueba que en ese momento del trimestre 1 todavía puede endeudarse y que a1 no ha sobrepasado el límite global que fijó. Si no se cumpliera la primera condición avisaría a 1 solicitándole un aumento de crédito para a1 que este podría aprobar o no. Si no se cumpliera la segunda notificaría a 1 que de querer autorizar la operación habría de aumentar temporalmente su límite máximo global de endeudamiento.
Saldos trimestrales
Se trata de minimizar el número de transferencias teniendo en cuenta las variables fijadas en la configuración de cada nodo. Aquí es donde se produce un ahorro evidente en gestión y obviamente, en comisiones, si las ejecutan a través de un banco o sistema de transferencia (como MoneyGram o Western Union).
Para ello el sistema debe comprobar los saldos. Resulta trivial que si un nodo ha prestado a usuarios de otros nodos durante el periodo lo mismo que sus usuarios han recibido de otros, no debería recibir ni emitir pagos en el saldo.
Y si tras optimizar los flujos, la cantidad es demasiado pequeña (por ej menor de un 20% del límite de pagos máximo de un nodo), también podría ser útil acumular el pago para un siguiente periodo, o al menos tras preguntar a las partes.
Pero se puede ir más allá usando algunos sencillos algoritmos matemáticos. Por ejemplo, imaginemos una red con cinco nodos. Si 1 debe 200 a 4, y 2 y 3 le deben a su vez 100 cada uno, y además 3 debe 200 a 2 y 5 debe 100 a 4… tendremos 5 relaciones de deuda establecidas que en realidad se saldarían fácilmente con tan sólo dos pagos. De hecho hay varias soluciones, pero una de ellas sería que 3 pagara 300 a 4 y 5 pagara 100 a 2.
Si dejamos para un siguiente periodo e pago de 5 a 2 por ser demasiado pequeño, habremos resuelto el saldo del periodo con tan sólo una transferencia ejecutada.
Por eso es importante también que los nodos fijen el monto de pago máximo que aceptarían a hacer a cada uno de los nodos (o en su defecto que no declararan no importarle tal máximo) para elegir soluciones óptimas para todos.
El sistema además habría de facilitar dos informes a los nodos: uno con los pagos recibidos por sus usuarios desde otros nodos y los dados por el a usuarios de otros nodos (tanto en la divisa franca como con sus equivalentes a precio del día en que se realizaron); otro con los pagos trimestrales que debe realizar.
En paralelo (otra pantalla de informes) debería mantener un histórico de estos pagos con opción de señalar si han sido ya realizados, de modo que en el momento en que el nodo deudor emprenda el pago sea avisado el nodo receptor, pero también de modo que si los nodos pactan (y deberían poder hacerlo a través del sistema) realizar los pagos en un plazo más amplio (semestralmente por ej) puedan compensarse flujos privadamente entre uno y otro.
¿Para quién sería útil y qué ganaría?
El usuario clásico y más evidente serían familias inmigrantes esparcidas por dos o más países, que ganarían en ahorro de costes y podrían ajustar sus flujos y pagos a los viajes presenciales que tuvieran que realizar, eliminando el máximo número posible de intermediaciones.
Pero evidentemente no se queda ahí: federaciones deportivas, redes de negocio transnacionales, pequeñas empresas que contratan servicios regulares que reciben a través de la red o incluso comunidades virtuales de viajeros podrían encontrar útil un sistema que reduzca los costes de transacción asociados a mover personas y asumir sus costes en áreas donde ya tienen agentes, socios o colegas.
Usos indebidos posibles
Es cierto que existe un potencial uso irregular frente a las necesidades de las haciendas de los estados: cuando la red que lo utiliza es una red de negocios, el límite máximo de pago a cada nodo puede servir también para ocultar esos pagos en otros mayores y recurrentes, contabilizándolos como descuentos o sobreprecios en transacciones habituales entre los nodos. De este modo los costes de transferencia se harían aún menores y la gestión de las cuentas se simplificaría aún más, pero las empresas no harían transparentes a las haciendas estatales el uso final de esos fondos. Seguramente habría que incorporar algún tipo de advertencia en el programa o en sus instrucciones señalando el peligro de que la legislación de los estados en los que operen los usuarios no acepte ese tipo de prácticas.
Conclusiones
El objetivo de este programa es reducir el elevado coste que los intermediarios generan a los inmigrantes, a los pequeños negocios que generan pagos internacionales más o menos reiterados y a los profesionales que trabajan regularmente para empresas en otros países a través de la red. Obviamente también sería de utilidad a PYMEs transnacionalizadas con estructuras en distintos países.
Se basa en un sistema tan antiguo como el comercio internacional, en la confianza propia de las redes y los lazos establecidos entre agentes y mercaderes. Seguramente merece la pena desarrollarlo…
¡Uau, David! Tenía pensado publicar un post hablando sobre la hawala y su posibilidad como software (aunque de momento tan sólo había recogido unos enlaces), cuando vi tu post del otro día. En él hablabas de Bitcoin, pero lo que narras en este post podría pasar por una descripción de Ripple, un proyecto existente que vengo siguiendo con mucho interés desde hace ya tiempo.
La intención de Ripple es convertirse en un sistema distribuido capaz de encaminar deudas en una red arbitraria de nodos con relaciones de confianza y crédito. Cada usuario decide para cada uno de los nodos con los que tiene relación de confianza cuál es el máximo crédito que le otorga, en qué moneda y bajo qué interés. Cuando se efectúa una transacción entre dos nodos entre los cuales no hay relación de confianza, el sistema encuentra un camino (o varios) de nodos entre los que sí hay confianza, ajustando sus créditos (si los límites lo permiten y el que paga acepta las condiciones del camino, como tipos de cambio). Por tanto, el sistema se basa en la confianza entre los nodos (cohesión) y realiza automática y continuamente el «ajuste trimestral» que comentas (aunque un grupo de nodos podría establecer sus propias políticas de cierre periódico de cuentas fuera de Ripple, el cual ya se habría encargado de minimizar el número de deudas pendientes). Hay animaciones y gráficos en esta página (recomiendo la presentación «Car Trip» y el diagrama «Introduction to Ripple»).
En el ejemplo que expones, a[1] podría pedir dinero a 3, que no conoce a 1, pero el sistema encontraría un camino a través de 2 (que tiene relación tanto con 1 como con 3) para realizar la transacción (si los límites de crédito en el camino lo permitieran). Creo que con un seguimiento local de créditos otorgados y recibidos, y jugando con los créditos máximos en cada nodo de la red se puede llegar a una limitación del valor en circulación (al menos como la has expuesto), y desde luego generar los informes que enumeras. Lo que no sé cómo está es el asunto del anonimato.
Ahora mismo tan sólo hay una implementación libre monositio (proyecto ripple en SourceForge), al menos un sitio que la executa (ripplepay.com) y un foro de compra-venta (ripplexchange.com). Ryan Fugger, su desarrollador principal, dijo que prefería de momento tener una implementación monositio y dejar el protocolo bien especificado antes de saltar a una implementación realmente distribuida. Si existiera una comunidad de usuarios interesados en la versión distribuida, creo que Ryan estaría dispuesto a cambiar de opinión, y desde luego yo, si tuviera el tiempo, estaría dispuesto a colaborar.
(Por cierto, incluir esto como opción a instalar en un nodo del bazar sería la b-o-m-b-a.)