I. El contexto
El 2 de enero de 2026 entró en vigor la Orden VAU/1560/2025. Una nueva obligación para todo operador de alquiler de corta duración en España: depositar un modelo informativo anual ante el Registro de la Propiedad, a través de la Sede Electrónica del Colegio de Registradores. Fechas de las reservas y número de huéspedes, básicamente. Plazo: febrero de cada año, con la primera presentación en febrero de 2026.
Para un propietario con un apartamento, es un trámite. Para una agencia de gestión vacacional con decenas o cientos de propiedades, cada una con su CRU y su NRUA, es una sentencia administrativa.
La pregunta lógica es: ¿qué herramienta proporciona el Colegio de Registradores para cumplir esta obligación?
II. SetupN2.exe
La respuesta es un archivo ejecutable de Windows llamado SetupN2.exe. Una aplicación de escritorio, descargable desde la Sede Electrónica, que solo funciona en Windows. Ni Mac, ni Linux. Solo Windows.
La interfaz es exactamente lo que imaginas cuando un organismo público español desarrolla software en 2026: una tabla que recuerda a Excel del año 1995. Campos rígidos, validaciones crípticas, mensajes de error que no explican nada. El separador debe ser punto y coma. Las fechas en DD/MM/AAAA. El orden de columnas es inamovible. Un espacio de más y el archivo se rechaza.
Una vez rellenados los datos — manualmente o importando un CSV con un formato tan específico que prácticamente necesitas otro programa para generarlo — la aplicación produce un fichero XBRL empaquetado en un ZIP. Ese archivo es lo que se presenta telemáticamente en la sede.
Y ahí empieza el verdadero problema.
III. La firma electrónica
Para presentar el depósito telemáticamente, necesitas firma electrónica. El Colegio de Registradores utiliza una aplicación del Gobierno de España llamada AutoFirma: un programa Java de escritorio que gestiona la firma digital con certificado electrónico.
AutoFirma funciona así: abres un navegador, inicias la presentación en la sede, el navegador lanza AutoFirma mediante un protocolo personalizado (afirma://), AutoFirma abre una ventana gráfica, te pide seleccionar un certificado, te pide la contraseña, firma el documento, y devuelve el resultado al navegador.
Es un proceso diseñado para un ser humano sentado delante de un ordenador Windows, haciendo clic. Cada propiedad. Cada depósito. Cada vez.
Si gestionas 200 propiedades, son 200 sesiones manuales. 200 selecciones de certificado. 200 contraseñas. 200 clics en "Aceptar". No hay API. No hay endpoint REST. No hay forma documentada de automatizar nada. El Colegio de Registradores simplemente no contempló que alguien pudiera necesitar hacerlo a escala.
IV. La respuesta del programador
Donde el Registro pone un formulario Windows, nosotros construimos una interfaz máquina-a-máquina.
Lo que hicimos no tiene precedente en este sector. Aplicamos ingeniería inversa sobre AutoFirma. Descargamos el código fuente del repositorio oficial del Gobierno de España, analizamos el flujo completo de firma tri-fase, identificamos los tres puntos exactos donde la aplicación requiere intervención humana, y los parcheamos.
Tres archivos. Tres parches. Cero intervención humana.
Parche 1: El almacén de certificados. AutoFirma espera que un humano introduzca la contraseña del certificado digital mediante un diálogo gráfico. Modificamos AOKeyStore.java — el núcleo del sistema de keystores — para que lea automáticamente las credenciales desde nuestra base de datos, cifradas con AES-256-CBC. Sin ventana. Sin prompt. Sin humano.
Parche 2: Las preferencias del sistema. AutoFirma consulta la configuración del usuario para determinar qué tipo de almacén de certificados utilizar. Si no encuentra una configuración, abre otro diálogo. Parcheamos PreferencesManager.java para que fuerce automáticamente el tipo PKCS12 y la ruta al certificado. Sin preguntas.
Parche 3: La selección de certificado. Cuando hay múltiples certificados disponibles, AutoFirma muestra una ventana para que el usuario elija cuál usar. Parcheamos CertificateSelectionDialog.java para que seleccione el certificado del usuario de Holidario. Sin diálogo. Sin espera.
La arquitectura
El resultado es una cadena completamente automatizada que funciona en un servidor Linux sin interfaz gráfica:
- Holidario genera el fichero XBRL con los datos del depósito de cada propiedad.
- El sistema selecciona el certificado digital del usuario de Holidario.
- Se lanza AutoFirma parcheado dentro de un display virtual (
xvfb) — porque la aplicación, incluso parcheada, cree que tiene pantalla. - Un cliente WebSocket en Node.js se conecta al puerto local de AutoFirma y envía el comando de firma.
- AutoFirma carga el certificado, firma el documento, ejecuta el protocolo tri-fase contra
sede.registradores.org, y devuelve el resultado.
Todo el proceso dura segundos. Sin navegador. Sin Windows. Sin intervención humana. Comunicación directa: servidor de Holidario ↔ Colegio de Registradores.
V. Lo que esto significa
A día de hoy, Holidario es el único software de gestión vacacional con una interfaz directa ordenador-a-ordenador con el Colegio de Registradores de España. No existe ningún otro PMS, channel manager, o ERP del sector que haya implementado esto.
Mientras el resto del sector ofrece "generar el CSV para que lo importes en la app N2 y lo firmes tú manualmente", nosotros ejecutamos el depósito completo. Generación del XBRL, firma electrónica, y presentación telemática. Automático. Para todas tus propiedades. Con un clic.
¿Por qué nadie más lo ha hecho? Porque no estaba diseñado para ser automatizado. El Colegio de Registradores publicó un ejecutable de Windows con una interfaz de los 90 y dijo "ahí lo tenéis". No hay documentación de integración. No hay API pública. No hay SDK. La única forma de hacerlo era abrir el código fuente de AutoFirma, entender su arquitectura interna, parchear el bytecode Java, montar un bridge WebSocket, y ejecutar todo en un servidor headless.
Eso es exactamente lo que hicimos.
VI. La reflexión
No pretendemos ser irrespetuosos con el Colegio de Registradores. La obligación del depósito de arrendamientos es razonable. La regulación del alquiler de corta duración es necesaria. Pero la implementación técnica es, siendo generosos, anacrónica.
Estamos en 2026. Existen APIs REST. Existen webhooks. Existen protocolos de firma electrónica en servidor (XAdES, CAdES) perfectamente estandarizados. Que la única vía de presentación telemática sea una aplicación Java de escritorio que requiere una pantalla, un ratón, y un ser humano haciendo clic, es una decisión de diseño que ignora deliberadamente la realidad del sector.
Un sector donde una sola agencia puede gestionar cientos de propiedades. Donde la eficiencia operativa es la diferencia entre un negocio viable y uno que se ahoga en burocracia. Donde cada hora dedicada a repetir trámites manuales es una hora que no se dedica a los huéspedes.
El software público debería facilitar el cumplimiento, no obstaculizarlo. Y cuando la administración no ofrece las herramientas adecuadas, alguien tiene que construirlas.
Nosotros las construimos.