Arquitectura de salvaguarda para instituciones de dinero electrónico
La segregación de fondos de clientes es un requisito regulatorio, no una funcionalidad. Categorías de cuentas, reglas de transferencia y obligaciones de reporte.
Safeguarding en la Práctica: Arquitectura de Cuentas de Dinero Electrónico para Licenciamiento EMI
El Artículo 10 de EMD2 requiere que las instituciones de dinero electrónico salvaguarden los fondos recibidos a cambio de dinero electrónico. Los fondos deben colocarse en una cuenta segregada en una institución de crédito, o invertirse en activos seguros de bajo riesgo, antes del final del siguiente día hábil. En cualquier momento, la institución debe poder demostrar que los fondos de los clientes están completamente cubiertos.
El safeguarding es una arquitectura de cuentas, no un requisito de reporting que se añade a infraestructura existente. El ledger debe prevenir estructuralmente la mezcla, combinar fondos de clientes con los propios fondos de la institución, a través de tipos de cuenta separados, aislamiento impuesto y visibilidad en tiempo real del saldo de safeguarding.
Los reguladores no aceptan "reconciliamos mensualmente y siempre cuadra." Requieren que la arquitectura prevenga la mezcla por construcción. La diferencia importa durante los exámenes.
La Arquitectura de Cuentas
Un ledger compatible con safeguarding distingue cuatro categorías de cuentas:
| Categoría | Tipo de Cuenta | Saldo Normal | Propósito |
|---|---|---|---|
| E-money de cliente | Pasivo | Haber | Fondos adeudados a clientes. Cada cliente tiene una o más cuentas de e-money. |
| Safeguarding | Activo | Debe | Cuentas bancarias donde los fondos de clientes se mantienen físicamente. Segregadas de cuentas operativas. |
| Operativo | Patrimonio / Ingresos | Haber | Fondos propios de la institución: comisiones, ingresos por intereses. |
| Float | Activo | Debe | Fondos en tránsito: settlement pendiente, clearing en proceso. |
La ecuación fundamental:
Suma(saldos e-money de clientes) ≤ Suma(saldos de cuentas safeguarding) + Suma(saldos float)
En todo momento. No al cierre de mes. No después de la reconciliación. En el momento en que el regulador pregunte.
Cuando un cliente deposita EUR 100:
DEBIT safeguarding:eur 100,00 (activo aumenta, banco recibió el dinero)
CREDIT customer:alice:eur 100,00 (pasivo aumenta, debemos a Alice EUR 100)
Ambos lados del asiento mantienen la ecuación. El saldo de safeguarding aumenta por el mismo monto que el pasivo con el cliente. Si un lado se registra sin el otro, un bug, un crash a mitad de transacción, un webhook fallido, la partida doble rechaza el asiento incompleto. La ecuación se mantiene por la propia invariante del ledger, no por disciplina de aplicación.
Prevención de Mezcla
La mezcla es el pecado capital de la regulación de dinero electrónico. Significa: la institución usó fondos de clientes para sus propios fines. Incluso temporalmente. Incluso por accidente.
Tres mecanismos arquitectónicos la previenen:
1. Flags de tipo de cuenta en el ledger.
Cada cuenta lleva un tipo: customer_emoney, safeguarding, fee_revenue, operating, float. El tipo se establece en la creación de la cuenta y es inmutable. No es una etiqueta, es una restricción que afecta qué transferencias están permitidas.
2. Reglas de transferencia impuestas por la capa de dominio.
Una transferencia de una cuenta safeguarding a una cuenta operativa está bloqueada por defecto. El único camino permitido para que fondos se muevan de safeguarding a operativo es a través de un workflow explícito de extracción de comisiones: al cliente se le cobra una comisión (reduciendo su saldo de e-money), y el monto de la comisión se transfiere de safeguarding a operativo. Este workflow es journalizado, auditado y requiere autorización explícita en la capa de orquestación.
La secuencia para una comisión mensual de EUR 2,00:
Paso 1: DEBIT customer:alice:eur 2,00 (pasivo disminuye, Alice debe menos)
CREDIT platform:fees:eur 2,00 (ingreso aumenta, comisión ganada)
Paso 2: DEBIT safeguarding:eur 2,00 (activo disminuye, fondos liberados)
CREDIT operating:eur 2,00 (patrimonio aumenta, fondos propios de la institución)
Ambos pasos son parte de un solo workflow durable. Si el paso 1 tiene éxito y el paso 2 falla, el motor de workflows reintenta el paso 2 desde el journal. El saldo de safeguarding nunca se desincroniza con el saldo del cliente, porque los dos movimientos están acoplados en un solo workflow, no dispersos entre procesos independientes.
3. Verificación de saldo de safeguarding en tiempo real.
El sistema puede generar un reporte de safeguarding en cualquier momento:
Total e-money de clientes: EUR 1.247.891,23
Saldo safeguarding: EUR 1.198.442,00
Float (settlement pendiente): EUR 52.100,00
Cobertura: EUR 1.250.542,00
Excedente: EUR 2.650,77 (>0 = conforme)
Si el excedente es negativo, la institución tiene safeguarding insuficiente. El sistema levanta una alerta. El equipo de operaciones tiene minutos, no días, para investigar y corregir.
Float y Timing de Settlement
Entre la iniciación del pago y el settlement, los fondos están en tránsito. Un cliente recibe un débito directo SEPA: el banco del acreedor ha enviado el cobro, pero el banco del deudor aún no ha liquidado. Los fondos se acreditan a la cuenta de e-money del cliente (pasivo aumenta), pero el correspondiente aumento de activo depende del ciclo de settlement.
Durante esta ventana, la ecuación de safeguarding incluye float:
Saldo del cliente: EUR 100,00 (cliente ve EUR 100)
Safeguarding: EUR 0,00 (banco aún no recibió los fondos)
Float (SDD pendiente): EUR 100,00 (settlement esperado en D+5)
Cobertura: EUR 100,00 (float cuenta para la cobertura)
El modelo de período de retención rastrea esto con precisión. Los fondos en estado SETTLED_PENDING se cuentan como float, cubiertos para fines de safeguarding pero aún no disponibles para el cliente. Después de que el período de retención expira y los fondos pasan a SETTLED_AVAILABLE, se mueven de float a safeguarding (el banco confirma la recepción).
Si ocurre un return durante el período de retención (R-transaction), el float se reduce y el saldo de e-money del cliente se revierte. La ecuación de safeguarding se reequilibra automáticamente porque ambos lados se mueven juntos.
Requisitos de Reporting
El licenciamiento EMI impone obligaciones específicas de reporting. La arquitectura debe producir estos reportes desde el ledger, no desde una base de datos de reporting separada, no desde un pipeline ETL, y no desde una hoja de cálculo.
| Reporte | Frecuencia | Regulador | Fuente de Datos |
|---|---|---|---|
| Saldo de safeguarding | Diario (interno) | , | Ledger: suma de cuentas safeguarding + float |
| Reporte de safeguarding | Mensual | BdE (España, Ley 21/2011) | Ledger: saldos de clientes vs. cobertura safeguarding |
| Auditoría externa | Anual | BdE, BaFin | Exportación completa de ledger con tipos de cuenta y clasificación |
| Declaración regulatoria | Trimestral | Autoridad nacional competente | E-money pendiente agregado, activos de safeguarding |
Los datos para cada reporte provienen de la misma fuente: el ledger inmutable de partida doble. El e-money pendiente de clientes es la suma de todos los saldos de cuentas customer_emoney (saldo normal haber). La cobertura de safeguarding es la suma de todos los saldos de cuentas safeguarding (saldo normal debe) más saldos float. El reporte es una consulta, no una construcción.
Esta es la ventaja de construir sobre partida doble desde el día uno. El balance general es una propiedad del ledger, no un artefacto derivado. La ecuación de safeguarding es un subconjunto de la ecuación contable (Activos = Pasivos + Patrimonio). Se verifica cada vez que se registra cualquier transferencia, porque cada transferencia debe equilibrar.
Errores Comunes de Safeguarding
Tres patrones que crean riesgo de safeguarding:
1. Cuentas bancarias compartidas. La institución usa una cuenta bancaria tanto para fondos de clientes como para fondos operativos, confiando en la contabilidad interna para rastrear la división. Si el banco congela la cuenta (por cualquier razón, investigación AML, disputa, insolvencia del banco), todos los fondos se congelan, incluyendo fondos de clientes. EMD2 requiere segregación física: una cuenta bancaria dedicada para safeguarding, separada de la cuenta operativa.
2. Falta de rastreo de float. Los saldos de clientes incluyen settlements pendientes (el cliente ve el crédito), pero el saldo de safeguarding no incluye el float correspondiente. El reporte de safeguarding muestra un déficit que realmente no existe, o peor, un excedente que enmascara un déficit real porque el float se cuenta doble.
3. Extracción de comisiones sin acoplamiento de workflow. Las comisiones se deducen de saldos de clientes (reduciendo pasivo) pero el movimiento correspondiente de safeguarding a operativo ocurre en un proceso separado y asíncrono. Si el proceso asíncrono falla o se retrasa, la cuenta de safeguarding temporalmente mantiene más de lo que debería, lo cual es técnicamente conforme pero operativamente confuso, o mantiene menos de lo que debería si el timing se invierte.
Cada uno de estos errores es evitable a través de arquitectura. Cuentas bancarias separadas. Tipos de cuenta float explícitos. Workflows durables que acoplan los dos lados de una extracción de comisiones. Los patrones no son complejos. Deben ser deliberados.
Leer más: El Ledger | Seguridad y Compliance
Fuentes:
- EMD2, Directiva 2009/110/CE, Art. 7 (Requisitos de safeguarding), Art. 10 (Protección de fondos)
- PSD3/EMD3, COM/2023/366 (propuesta de fusión de PSD2 y EMD2)
- Ley 21/2011 (España), Art. 8-10 (safeguarding para EMIs españoles)
- BaFin: Guía sobre requisitos de safeguarding para instituciones de dinero electrónico
- HGB §246, Prohibición de compensación (Verrechnungsverbot), activos de clientes no deben compensarse contra pasivos de la institución