Cuando un proyecto cripto regulado se retrasa, el regulador no siempre es la causa. El proyecto puede haber perdido semanas o meses antes de que una solicitud completa llegue a la autoridad. El calendario real empieza con las dependencias, no con el filing.
Ese es el error de planificación central: tratar el periodo de revisión del regulador como si fuera la duración completa del proyecto.
Tres ideas clave
- Hay al menos dos relojes. El reloj del proyecto empieza mientras se construyen perímetro, ownership, personas, capital y evidencia; el reloj de revisión del regulador empieza después.
- El critical path suele ser una cadena de dependencias. Una sola persona, documento de ownership, control, paso de capital o decisión tecnológica pendiente puede bloquear varios workstreams a la vez.
- Banca y fiscalidad avanzan en paralelo al licensing. Incluso una solicitud bien gestionada puede terminar en una estructura inutilizable si cuenta bancaria, contabilidad, residencia fiscal o reporting se dejan para el final.
La pregunta equivocada: ¿cuánto tarda la licencia?
Es comprensible que un fundador quiera un número: tres meses, seis, nueve. El problema no es querer un calendario. Es asumir que un solo número describe todas las partes del proyecto.
El regulador revisa solicitudes. El proyecto tiene que llegar a ser revisable.
Antes del filing, el solicitante puede tener que definir actividades reguladas, escoger la entidad correcta, identificar beneficial owners, documentar source of funds, nombrar senior people, preparar un regulatory business plan, construir proyecciones, establecer governance, redactar políticas, escoger tecnología y custodia, acreditar capital y resolver cuestiones de grupo o related parties.
Algunas tareas pueden ejecutarse en paralelo. Otras no.
Por eso el proyecto está gobernado por un critical path: la cadena más larga de dependencias que debe completarse antes de poder superar el siguiente gate.
El perímetro va antes que el papeleo
El primer retraso puede ocurrir incluso antes de redactar un documento.
Un proyecto que no ha definido qué va a hacer realmente no puede identificar de forma fiable qué licencia necesita. «Empresa cripto» no es una actividad regulada. Exchange, broker-dealer, custody, lending, transfer, advisory e issuance pueden ocupar partes diferentes de un marco regulatorio y generar requisitos distintos de capital, governance o tecnología.
Lo mismo ocurre con la geografía. Hay que saber dónde se presta el servicio, qué clientes se buscan y qué entidad realiza la actividad.
Si el perímetro cambia a mitad del proyecto, el trabajo posterior suele cambiar con él. Business plans, políticas, modelos financieros, staffing y arquitectura de proveedores pueden tener que revisarse.
La forma más rápida de perder tiempo es optimizar un filing antes de fijar la actividad que debe describir.
Las personas pueden convertirse en la dependencia más larga
Una política es fácil de calendarizar porque es un entregable. Una persona cualificada es más difícil porque debe existir, estar disponible, aceptar el puesto y cumplir las condiciones regulatorias aplicables.
Según el régimen, las funciones clave pueden implicar experiencia, fit-and-proper, independencia, ubicación, residencia o dedicación full-time. El senior management puede ser entrevistado. El regulador puede preguntar cómo interactúan los puestos y si las responsabilidades tienen un owner real.
Un proyecto que presupone que encontrará a las personas clave cuando la solicitud esté «casi lista» puede descubrir que el staffing determina la verdadera fecha de filing.
Por eso tampoco debe construirse el organigrama hacia atrás desde una plantilla. Las personas necesarias dependen de la actividad y del modelo operativo.
La evidencia es otro calendario oculto
Ownership y source-of-funds evidence parecen tareas administrativas hasta que aparece un eslabón perdido.
Una cadena accionarial compleja, financiación histórica, varias jurisdicciones o documentación corporativa inconsistente pueden exigir reconciliación antes de que el expediente sea creíble. Lo mismo puede ocurrir con estados financieros, evidencia de capital, close-link analysis o estructuras de grupo.
La lección no es que toda estructura tenga que ser simple. Es que la complejidad consume tiempo de verificación.
La evidencia debe tratarse como infraestructura del proyecto. Si un hecho material tendrá que demostrarse al regulador, banco o auditor, la ruta de evidencia debe identificarse pronto.
La práctica actual de VARA hace visibles los dos relojes
El proceso actual de VARA en Dubái ofrece una ilustración útil, no un plazo universal.
Para empresas nuevas, VARA describe dos etapas. Stage 1 incluye un Initial Disclosure Questionnaire, documentación adicional como business plan e información sobre beneficial owners y senior management y puede terminar en un Approval to Incorporate. Solo entonces puede completarse la incorporación y el montaje operativo, por ejemplo oficina y onboarding de empleados. VARA señala expresamente que la empresa no puede realizar actividades de Virtual Assets en ese momento.
Stage 2 comprende la solicitud de VASP Licence completa. VARA puede dar feedback, celebrar reuniones o entrevistas y solicitar documentación adicional. La licencia puede quedar sujeta a condiciones operativas.
La estructura del proceso demuestra el principio de planificación: el «tiempo de solicitud» está dentro de una secuencia mayor de preparación jurídica y operativa.
La banca no es la última casilla
Un error de secuenciación habitual es:
incorporar → solicitar → obtener licencia → abrir cuenta bancaria.
Queda ordenado en una presentación. Puede ser frágil en la práctica.
Las entidades financieras realizan su propio customer due diligence y análisis de riesgo. Pueden necesitar comprender ownership, actividad, geografías, source of funds, flujos esperados, contrapartes y controles. Esas preguntas están conectadas con el mismo modelo operativo que se presenta al regulador, pero el banco toma su propia decisión.
Si el negocio depende de fiat settlement, nómina, reserve accounts o movimiento de fondos de clientes, la banca debe considerarse mientras se diseña el modelo regulado.
La licencia puede ser necesaria para la historia de bankability. No es toda la historia.
Fiscalidad y reporting tienen su propia secuencia
Lo mismo ocurre con la fiscalidad.
La solicitud de licencia no determina dónde es residente fiscal la empresa, dónde se gestiona efectivamente, si la actividad crea otra presencia imponible, cómo se caracteriza el ingreso, qué impuestos indirectos pueden aplicar o qué obligaciones de información existen.
Esas preguntas pueden depender de las mismas personas y flujos que impulsan el análisis regulatorio. Si decisiones, contratos, wallets, cuentas bancarias y personal operativo están repartidos entre países, no tiene sentido posponer el análisis fiscal hasta después del lanzamiento.
Los regímenes de reporting también necesitan datos. No puede asumirse que un expediente de licensing o AML contenga automáticamente todo lo exigido para reporting fiscal.
La mejor objeción: los reguladores sí pueden causar retrasos reales
Por supuesto.
Una autoridad puede tener backlog, solicitar más información, cambiar expectativas, entrevistar personas, analizar con más profundidad un modelo novedoso o tardar más de lo previsto. Ningún plan serio debe negar esa incertidumbre.
Pero precisamente por existir discrecionalidad supervisora conviene controlar bien las dependencias pre-filing que sí controla el solicitante. Un equipo no puede eliminar la incertidumbre regulatoria. Sí puede evitar añadir retrasos evitables propios.
La pregunta útil deja de ser «¿cuánto tardará el regulador?» y pasa a ser:
¿Qué tiene que ser verdad antes del filing, qué puede continuar en paralelo y qué dependencia puede detener todo el proyecto?
Qué podía saberse en 2022 y qué es más claro hoy
A finales de 2022 la lección esencial ya era visible: la regulación cripto se estaba convirtiendo en un problema operativo, no solo registral. Los proyectos necesitaban personas, evidencia y sistemas además de formas jurídicas.
Los marcos actuales hacen la cadena de dependencias mucho más explícita. VARA publica hoy un proceso que separa incorporación y operational setup de la VASP Licence completa. Su documentación identifica governance, UBOs, key personnel, proyecciones, capital, seguros y wind-down como parte del expediente regulatorio.
Las reglas más recientes no permiten afirmar que todos los reguladores siguen el mismo proceso. Sí permiten abandonar la idea de un único «licensing timeline» universal.
Un modelo de planificación mejor
Un proyecto cripto regulado debería mantener cuatro calendarios conectados:
- Calendario regulatorio: perímetro, documentación, preguntas del regulador y gates de autorización.
- Calendario operativo: personas, tecnología, políticas, proveedores, custodia, finanzas y controles.
- Calendario de bankability: requisitos de cuenta, evidencia, diseño de flujos y contrapartes financieras.
- Calendario fiscal y de reporting: residencia, contabilidad, registros, datos y obligaciones de presentación.
La fecha del proyecto no es la más corta de esas cuatro. Es la fecha en la que las dependencias críticas de todas ellas permiten operar legalmente.
Es una respuesta menos comercial que prometer «X meses». También es mucho más útil.
Fuentes
- VARA — Licence Applications
- VARA — Licensed Activities
- CBUAE Rulebook — Customer Due Diligence Measures
- CBUAE Rulebook — Federal Decree-Law No. 10 of 2025 on AML/CFT/CPF
Aviso
Este artículo ofrece información general sobre planificación de proyectos regulados. No proporciona un plazo de licensing ni asesoramiento jurídico, regulatorio, fiscal, bancario o de inversión. Los requisitos y tiempos dependen de la actividad, regulador, jurisdicción y solicitante y deben verificarse frente a las normas vigentes antes de tomar decisiones.
