Fiscal y normativa · 9 min de lectura

Tributación de bots de trading y arbitraje en criptomonedas

Contenido del artículo

Un bot de arbitraje entre Binance y Kraken puede ejecutar 300 operaciones en una hora. Al cierre del ejercicio, el cliente trae un CSV de 40.000 filas y pregunta: “¿Cuánto debo pagar?”. Lo básico (cómo tributa cada tipo de operación y cuándo toca el 721) está en la guía del cliente con criptomonedas en la gestoría. Aquí va lo que cambia cuando hay un bot: la respuesta corta es que cada una de esas operaciones tributa por separado en la base del ahorro del IRPF, y la reconstrucción de la base imponible con el método FIFO sobre 40.000 líneas no es un trámite de diez minutos.

El trading manual de tres o cuatro operaciones al mes se lleva con una hoja de cálculo. El trading automatizado cambia la escala del problema: no es el tipo de gravamen lo que se complica, es la mecánica de cálculo. Y ahí es donde el coste de gestión fiscal se come el margen del arbitraje.

El desafío fiscal del trading automático y el arbitraje

La realidad del volumen de operaciones

Un bot puede ejecutar cientos de operaciones al día. Uno de arbitraje triangular (BTC → ETH → USDT → BTC) genera tres por cada ciclo. En un ejercicio pueden ser miles de operaciones, cada una con su par, su precio, su comisión, su gas y su fecha exacta al segundo.

El problema no es que AEAT te pida un resumen. El problema es que el artículo 37.2 de la Ley 35/2006 del IRPF fija el método FIFO para valores homogéneos, y la Administración lo extiende a las criptomonedas. Eso significa que, para cada venta o permuta, hay que saber qué unidades se transmiten: primero las que se compraron antes. Con miles de operaciones, la reconstrucción a mano es inviable.

Diferencia entre trading manual y ejecución por bots

Fiscalmente, no existe una categoría “trading por bot”. AEAT no distingue entre la orden que tú pulsas y la que ejecuta un algoritmo. Lo que cambia es la trazabilidad: en el trading manual, el contribuyente sabe qué compró, cuándo y a qué precio. Con un bot, esa información vive en los logs del exchange y en la configuración del bot, y si no se exporta de forma sistemática, se pierde.

Cómo tributa cada operación en el marco del IRPF

Venta de criptomonedas por euros (ganancias patrimoniales)

Cuando el bot vende BTC por USDT o por EUR, se produce una ganancia o pérdida patrimonial en la base del ahorro (art. 46.b de la Ley 35/2006). La ganancia es la diferencia entre el valor de transmisión y el valor de adquisición de esa unidad concreta (FIFO). Las comisiones de la plataforma y el gas se suman al valor de adquisición o se restan del de transmisión (art. 35.1.b y 35.2 de la Ley 35/2006).

La base del ahorro tributa, sumando la escala estatal y la autonómica, al 19 % hasta 6.000 €, 21 % hasta 50.000 €, 23 % hasta 200.000 €, 27 % hasta 300.000 € y 30 % a partir de ahí.

La permuta de criptoactivos: cuando no hay paso a moneda fiat

Aquí es donde la mayoría de los operadores de bots se equivocan. Si el bot intercambia ETH por USDC sin pasar por euros, tributa. Es una permuta, y el artículo 37.1.h de la Ley 35/2006 dice cómo se calcula. La ganancia se calcula comparando el valor de adquisición de lo entregado con el mayor del valor de mercado de lo entregado y de lo recibido en el momento de la permuta.

Un bot de arbitraje triangular genera tres permutas por ciclo. Cada una es una transmisión independiente. No hay “ganancia neta del ciclo”: hay tres ganancias (o pérdidas) patrimoniales que se suman a la base del ahorro.

El impacto del Staking y el Staking Líquido en la base del ahorro

Si el bot o el operador usa staking para generar rendimiento sobre los activos en cartera, la tributación cambia de naturaleza. Según las consultas vinculantes de la DGT (V1766-22 y V0612-26, de 17 de marzo de 2026), el staking centralizado y el staking nativo generan rendimientos del capital mobiliario (art. 25.2 de la Ley 35/2006), valorados a mercado cuando se perciben, y tributan en la base del ahorro.

En el staking líquido, el intercambio del token de stake por el token equivalente se considera una permuta y tributa como transmisión patrimonial. Si el bot rota entre staking y trading, hay que separar en la declaración qué parte es rendimiento y qué parte es ganancia patrimonial.

El método FIFO y la complejidad de las microoperaciones

Por qué el volumen de operaciones de un bot complica la reconstrucción

FIFO exige que, al vender la unidad 1.247 de BTC, identifiques cuál fue la 1.247ª que compraste. Con un bot que compra y vende varias veces al día, las posiciones se entrelazan, y si opera en varias plataformas hay que juntar los históricos de todas para saber qué unidades de cada moneda se compraron primero.

El error que se repite: el cliente exporta un CSV “resumido” del exchange que solo muestra el saldo final, no el histórico de operaciones. Con ese archivo no se puede aplicar FIFO. Se necesita el log completo, operación a operación, con timestamp, par, cantidad, precio, comisión y gas.

El coste administrativo de procesar miles de líneas de ejecución

Con unos cientos de operaciones, una hoja de cálculo bien montada aguanta. Con miles, deja de ser fiable: cualquier error de ordenación en una fila arrastra todas las siguientes, porque cada venta consume las compras más antiguas que queden.

A partir de ahí toca automatizar dos cosas distintas. La extracción de los históricos se puede montar con una herramienta como Make, que conecta con las plataformas y deja los datos en un formato común. El cálculo FIFO en sí necesita un programa o un script que empareje ventas y compras operación a operación: eso no lo hace una herramienta de automatización por sí sola.

Análisis de rentabilidad vs. coste de gestión fiscal

Por qué el papeleo puede absorber el beneficio del arbitraje

El arbitraje vive de márgenes muy pequeños por operación. Pongamos un bot que cierra el año con 8.000 € de ganancia neta. En el IRPF, 6.000 € tributan al 19 % y los 2.000 restantes al 21 %: 1.560 €. Si además reconstruir el histórico cuesta 1.500 € en horas del despacho o en herramientas, el cliente se queda con 4.940 € de los 8.000, algo más del 60 %.

La pregunta que hay que hacer al cliente no es “¿cuánto tributas?” sino “¿cuánto te cuesta saber cuánto tributas?”. Cuanto más pequeño es el margen de cada operación, más pesa ese coste fijo sobre lo que queda.

La importancia de la trazabilidad desde el origen

La solución no es “exportar al final del año”. Es tener un registro en tiempo real: cada operación del bot se registra con su par, precio, comisión, gas y timestamp en un formato estandarizado. Si el cliente no lleva ese registro desde el primer día, la reconstrucción al cierre es una estimación, y una estimación con miles de operaciones es una invitación a una regularización.

Obligaciones informativas y plazos de prescripción

El Modelo 721 y la custodia de activos en el extranjero

Las criptomonedas no van en el modelo 720. Tienen su propia declaración informativa: el modelo 721 (art. 42 quater del RD 1065/2007). Se presenta cuando el saldo conjunto de criptoactivos custodiados por un proveedor en el extranjero supera los 50.000 € a 31 de diciembre. Plazo: del 1 de enero al 31 de marzo del año siguiente. En años posteriores, solo si el saldo sube más de 20.000 €.

Ojo: la autocustodia (wallet propia, seed phrase en un disco) no está sujeta al 721. Solo cuenta la custodia por un proveedor (exchange, plataforma de staking, etc.). Si el bot opera en Binance y Kraken, hay que sumar los saldos de ambas al 31 de diciembre.

Plazo de prescripción de la Agencia Tributaria

La acción de la AEAT para exigir el IRPF prescribe a los cuatro años desde el día siguiente al de finalización del plazo de declaración (art. 66 LGT). Para una declaración de 2026, el plazo de presentación es el 30 de junio de 2027, así que la prescripción llegaría el 1 de julio de 2031. Eso no significa que se pueda esperar: si la reconstrucción FIFO es incorrecta y la AEAT lo detecta en una comprobación de oficio, el interés de demora y la sanción por infracción tributaria se suman a la cuota.

Confidencialidad y datos del cliente

Cuando un cliente trae el histórico de un bot, ese CSV contiene NIF, direcciones de wallet, saldos, pares operados y volúmenes. Es información financiera identificable. La regla de oro al trabajar con una IA pública o una herramienta en la nube: nunca se sube el CSV completo con datos identificables. Se anonimiza (se sustituye el NIF, se eliminan las direcciones de wallet) antes de procesarlo. El RGPD exige aplicar medidas de seguridad adecuadas (art. 32 RGPD) y tratar solo los datos necesarios.

Checklist antes de cerrar la declaración de un cliente con trading automático

  • Exportar el log completo de cada exchange (no el resumen de saldo): fecha, hora, par, cantidad, precio, comisión, gas.
  • Verificar que el CSV incluye todas las operaciones, incluidas las permutas cripto-cripto que el exchange a veces agrupa como “swap”.
  • Juntar los históricos de todas las plataformas antes de aplicar el FIFO a cada criptomoneda.
  • Identificar las operaciones de staking y clasificarlas como rendimiento (art. 25.2) o permuta (art. 37.1.h), según el caso.
  • Calcular la ganancia/pérdida por operación con FIFO y sumar todas las transmisiones del ejercicio.
  • Aplicar la escala de la base del ahorro (del 19 % al 30 %, estatal y autonómica ya sumadas) al resultado neto.
  • Comprobar si el saldo en exchanges extranjeros supera los 50.000 € al 31-dic → modelo 721.
  • Cruzar las pérdidas con las ganancias del mismo ejercicio; las pérdidas no compensadas se arrastran cuatro años (art. 49).
  • Guardar el CSV original y el archivo de reconstrucción FIFO al menos cuatro años (plazo de prescripción).
  • Confirmar con el cliente que no hay wallets de autocustodia con activos que no figuren en el log del exchange.

Con miles de operaciones al año, la reconstrucción manual no es viable: sin un proceso que extraiga, empareje y resuma por FIFO, el número que acaba en la declaración es una estimación.