Una idea de trading puede parecer perfectamente clara al mirar un gráfico. Sabes qué situación buscas, cuándo entrarías y qué operación prefieres evitar. Entonces intentas explicársela a un desarrollador y unas pequeñas preguntas cambian la conversación: qué vela cuenta, si el sistema puede volver a entrar y qué ocurre si otra estrategia ya está utilizando la misma cuenta.
En esas preguntas empieza buena parte del trabajo real. En POLARIS entendemos el desarrollo de sistemas de trading como una forma de concretar tu idea para poder construirla, probarla y utilizarla con confianza. El código importa. También importa que siga la idea que realmente tenías en mente.
Nuestro archivo publicado reúne 170 registros: 169 de trabajos de desarrollo y uno de investigación interna. Incluye sistemas nuevos, cambios en herramientas existentes, integraciones y reparaciones. Esa variedad es el contexto de las lecciones que siguen. Los tres ejemplos se han creado para este artículo: explican el razonamiento sin revelar proyectos de clientes.
1. Una pequeña pregunta puede cambiar cada operación
Imagina pedir un sistema que compre cuando un indicador pase a positivo. Parece una instrucción completa. Pero ¿quieres decir «compra una vez cuando cruce por encima de cero» o «compra cada vez que su valor esté por encima de cero»?
La diferencia se ve al seguir cinco lecturas. Supongamos que ninguna otra regla bloquea la entrada. Cada fila es una nueva comprobación del indicador; antes de la primera lectura, su valor era −0,2.
| Lectura | Valor del indicador | Comprar si el valor es positivo | Comprar solo en el cruce |
|---|---|---|---|
| 1 | 0,3 | Solicitud de compra | Solicitud de compra |
| 2 | 0,4 | Solicitud de compra | Sin nueva compra |
| 3 | 0,1 | Solicitud de compra | Sin nueva compra |
| 4 | −0,1 | Sin nueva compra | Sin nueva compra |
| 5 | 0,2 | Solicitud de compra | Solicitud de compra |
La regla que solo exige un valor positivo produce cuatro solicitudes de compra. La del cruce produce dos señales nuevas. Ninguna es correcta por definición: quizá quieras entrar repetidamente. El problema es dejar esa elección en manos de quien escribe el código.
Ahora imagina que la primera operación se cierra mientras el indicador sigue siendo positivo. ¿Debe entrar de nuevo el sistema? La opción «una operación a la vez» no responde a esa pregunta. Puede ocultar la ambigüedad hasta que se produzca la primera salida.
Qué acordaríamos antes de construirlo: en este ejemplo, comprobar velas cerradas y generar una señal solo cuando el valor anterior sea cero o negativo y el nuevo sea positivo. Cada señal recibe una referencia única para que la misma vela no provoque otra orden tras un reinicio. Si no se permite operar, la señal caduca al llegar la siguiente vela. Sin datos del indicador, no hay entrada.
Cómo comprobarlo: repetir las cinco lecturas debe producir dos referencias de señal. Repetir la primera lectura y reiniciar el sistema no deben crear una orden adicional para esa misma señal. Son resultados esperados según las reglas del ejemplo, no resultados atribuidos a una prueba de un cliente. Operar mientras se forma una vela también es posible, pero requiere otras reglas igual de claras.
2. Dos operaciones razonables pueden ser demasiado para una cuenta
Los ajustes de riesgo pueden resultar tranquilizadores al examinar cada estrategia por separado. La pregunta más difícil es qué sucede cuando varias quieren operar a la vez.
Tomemos una cuenta de 10.000 dólares. En este ejemplo, cada operación puede prever una pérdida de hasta 100 dólares en su stop, mientras que la pérdida total prevista en la cuenta debe mantenerse dentro de 150 dólares. Dos sistemas solicitan una operación con 90 dólares de riesgo previsto cada uno. Ambos cumplen su límite individual. Juntos necesitan 180 dólares.
El momento de la comprobación importa. Si ambos sistemas consultan la cuenta antes de que aparezca alguna de las operaciones, cada uno puede creer que los 150 dólares siguen disponibles. El cálculo del porcentaje puede ser correcto y, aun así, la decisión para el conjunto de la cuenta puede fallar.
Un control común del riesgo resuelve este ejemplo reservando 90 dólares en cuanto acepta la primera solicitud. Quedan 60, por lo que rechaza la segunda solicitud de 90 dólares. Aquí mantenemos fijo el tamaño de la operación; reducir la segunda sería una regla distinta que habría que acordar.
La reserva no puede desaparecer simplemente porque una respuesta tarde. Si el bróker confirma el rechazo, puede liberarse. Si el resultado se desconoce, el sistema debe comprobar las órdenes y posiciones reales antes de volver a considerar disponible esa capacidad. MetaQuotes explica por qué una solicitud de trading puede generar varias actualizaciones separadas.
Cómo comprobarlo: enviar ambas solicitudes juntas, retrasar una respuesta y repetir la prueba después de reiniciar. El riesgo previsto ya utilizado o reservado nunca debe superar los 150 dólares. Es un límite de diseño, no una garantía de pérdida máxima: los saltos de precio, el deslizamiento y las salidas fallidas pueden provocar pérdidas mayores.
3. Un gráfico puede parecer más claro después de lo que era en ese momento
Supongamos que aparece una señal de cinco minutos a las 10:05 y quieres confirmarla con la tendencia horaria. ¿Qué vela de una hora debe leer el sistema?
A las 10:05 ya se ha cerrado la vela de cinco minutos que va de 10:00 a 10:05. A la vela horaria de 10:00 a 11:00 todavía le quedan 55 minutos. Su valor final aún no se conoce. Si la regla utiliza velas cerradas, la vela horaria disponible es la de 09:00 a 10:00.
Al mirar el gráfico terminado, es fácil olvidar esa diferencia. Usar el valor final de las 11:00 para evaluar una decisión de las 10:05 da al sistema información que entonces no podía tener. También puedes elegir la vela horaria que sigue cambiando, pero es una regla diferente y debe probarse como tal.
Qué acordaríamos: de qué vela procede cada dato, cuándo puede utilizarse y qué hacer si llega tarde. En este ejemplo, la falta de historial supone esperar o saltarse la oportunidad según lo acordado, nunca sustituirlo silenciosamente por una vela sin cerrar.
Cómo comprobarlo: el registro de la decisión de las 10:05 debe identificar la vela horaria que termina a las 10:00 y la de cinco minutos que termina a las 10:05. Retrasa uno de los datos y comprueba que el sistema espera o se salta la entrada según lo previsto. Estos horarios suponen datos continuos y una zona horaria de servidor definida; alrededor de los cierres de mercado hay que comprobar las horas reales de las velas.
4. Un programa correcto y una estrategia útil necesitan comprobaciones distintas
Los ejemplos anteriores preguntan si el software hace lo acordado. Un sistema puede superar todas esas comprobaciones y seguir perdiendo dinero. Por eso, una buena conversación sobre la entrega incluye cómo se evaluará la propia idea de trading.
Un backtest muestra cómo se comportaron las reglas con precios pasados bajo las condiciones elegidas. Es útil, pero el resultado también depende de los costes, la calidad de los datos y la simulación de las operaciones. Si un pequeño aumento del spread elimina la ventaja aparente, conviene descubrirlo antes de confiar en el sistema.
Una opción práctica es desarrollar la idea sobre un periodo y probarla después en otro que no se haya utilizado para tomar esas decisiones. A continuación se observa su comportamiento hacia delante, bajo condiciones definidas. Si el periodo separado se usa repetidamente para ajustar la estrategia, deja de ser una comprobación nueva. Cada etapa aporta información; ninguna garantiza la siguiente.
Desarrollador y cliente deben acordar qué significa superar cada prueba. «El sistema abrió exactamente las dos operaciones previstas» es un resultado del software. «La estrategia siguió siendo útil después de costes con datos no vistos» necesita pruebas de trading propias.
5. Deberías poder entender qué está haciendo tu sistema
Un sistema debe seguir siendo utilizable después de su primera prueba satisfactoria. Si se mantiene fuera del mercado, deberías poder saber si no había señal, si se alcanzó el límite de riesgo o si faltaban precios.
Un mensaje como «operación fallida» deja demasiadas dudas. «Entrada omitida: 60 dólares disponibles, 90 necesarios» explica qué ocurrió y dónde mirar. La versión del software, la hora de la decisión y la respuesta del bróker ayudan a distinguir un cambio en las reglas de un cambio en las condiciones de trading.
El reinicio merece la misma atención. ¿Reconocerá el sistema una posición existente? ¿Podría repetir una orden ya enviada? Una entrega útil incluye ajustes claros, una guía breve de uso y comprobaciones de estas situaciones. Son prácticas de entrega que recomendamos; el archivo no demuestra que todos los trabajos históricos las incluyeran.
Qué significa esto para tu proyecto
El valor de la experiencia está en saber qué preguntas conviene adelantar, cuando todavía es fácil cambiar las respuestas. Una estrategia nueva, la conversión de un indicador y una reparación no necesitan planes idénticos. Sí necesitan una comprensión compartida de lo que debe hacer el sistema terminado.
Para una primera conversación con POLARIS son especialmente útiles tres cosas: un ejemplo de una operación que deseas, otro de una que quieres evitar y los límites que el sistema debe respetar. No necesitas llegar con una especificación técnica. Esos ejemplos nos dan un punto de partida concreto para prepararla contigo.
- Antes del desarrollo: acordar señales, tiempos, límites de posición y comportamiento cuando falta información.
- Antes de aceptar la entrega: probar una situación normal, un caso límite y un fallo, con el resultado esperado por escrito.
- Antes de confiar en el sistema: revisar las pruebas de trading, las instrucciones de uso y la recuperación tras un problema.
Queremos que reconozcas tu propia idea en el sistema terminado y entiendas cómo se ha comprobado su comportamiento. El desarrollo cuidadoso puede ganarse esa confianza.
Habla de tu idea de trading con POLARIS · Explora nuestras capacidades de desarrollo
Una mirada más cercana al archivo
El archivo ayuda a mostrar la variedad de trabajos que hay detrás de esta conversación. No mide la rentabilidad ni indica la frecuencia de un error concreto. Los detalles siguientes permiten comprobar las cifras sin interrumpir las lecciones prácticas.
Qué incluyen los 170 registros y cómo interpretar las cifras
Las cifras proceden del conjunto de datos publicado del archivo. Cada fila representa un trabajo registrado, no necesariamente un cliente distinto o una estrategia única.
| Tipo de trabajo | Registros |
|---|---|
| Desarrollo nuevo | 117 |
| Modificación y mejora | 34 |
| Conversión e integración | 12 |
| Depuración y reparación | 6 |
| Investigación interna | 1 |
Los 169 registros de desarrollo tienen fechas entre noviembre de 2020 y febrero de 2024. El de investigación interna no tiene fecha ni duración publicadas. Es una instantánea del archivo, no el total actual de todos los trabajos de POLARIS. No contiene informes de aceptación de clientes, rentabilidades de cuentas ni una lista común de criterios de aceptación.
Plataformas: las etiquetas suman 81 registros de MT5, 71 de MT4 y 18 de ambos. De ellos, 108 están marcados expresamente como inferidos: 52 de MT5 y 56 de MT4. Los otros 62 son 29 de MT5, 15 de MT4 y 18 mixtos; no estar marcado como inferido tampoco implica verificación independiente. Las fechas inferidas de MT4 van de noviembre de 2020 a diciembre de 2021, y las de MT5 de enero de 2022 a enero de 2024. No deben presentarse como experiencia confirmada en esas plataformas.
Categorías: cada fila tiene un tema principal y puede incluir varias etiquetas de funciones. Por ejemplo, el registro 1 tiene como tema la gestión del riesgo y de operaciones, con etiquetas de tamaño de posición y gestión de stops. Sigue siendo un solo registro. Una etiqueta ausente significa «no registrado aquí», no necesariamente «no desarrollado». Las fechas y duraciones desconocidas siguen siendo desconocidas.
Los recuentos exactos por función incluyen 45 registros de tamaño de posición, 7 de varios marcos temporales y 6 de integración de indicadores. Además, 6 filas están clasificadas específicamente como reparaciones. Estas cifras describen el archivo; no cuentan defectos ni demuestran que las protecciones de los ejemplos se entregaran en todos los casos.
Algunas páginas antiguas utilizan agrupaciones temáticas más amplias. La tabla separa esos resúmenes publicados de los recuentos que pueden reproducirse directamente a partir de las filas.
| Tema | Total temático antiguo | Selección del artículo | Recuento en los datos |
|---|---|---|---|
| Integración de indicadores | 11 | 10 | 6 — etiqueta de función |
| Grid y cobertura | 38 | 33 | 33 — tema principal |
| Acción y estructura del precio | 26 | 22 | 22 — tema principal |
| Datos, estadística y aprendizaje automático | 9 | 3 | 3 — tema principal |
| Paneles y escáneres | 22 | 14 | 11 — etiqueta de función |
Las listas que relacionan los grupos antiguos y las selecciones de los artículos con las filas individuales no son públicas, por lo que las diferencias no pueden explicarse por completo. Para reproducir los recuentos, se cuenta cada tema principal una vez por fila, o la presencia de la función indicada una vez por fila. Distintas funciones pueden coincidir en un mismo registro.
El archivo refleja el trabajo conservado y la demanda de los clientes, no una muestra representativa del sector. No muestra trabajos abandonados, frecuencias de errores ni coincidencia entre revisores independientes. Afirmaciones más amplias necesitarían esos datos. Los futuros registros serían más fáciles de comprobar si incluyeran la versión aceptada, la lista de comprobación, la fecha de decisión, el revisor y la ubicación de las pruebas.
| Lección | Recuento | Qué explica la lección | Cuándo puede cambiar la regla |
|---|---|---|---|
| Definir el evento de entrada | 6 etiquetas de integración de indicadores | El ejemplo 1 muestra cuatro solicitudes frente a dos señales; el recuento no mide errores. | Las entradas repetidas pueden ser intencionadas. |
| Coordinar el riesgo de la cuenta | 45 etiquetas de tamaño de posición | El ejemplo 2 pide 180 dólares frente a 150 disponibles; el recuento no demuestra controles compartidos. | Las cuentas separadas y aisladas no comparten esa capacidad. |
| Acordar qué vela cuenta | 7 etiquetas de varios marcos temporales | El ejemplo 3 separa información disponible de un valor final posterior; no es una tasa de errores. | Puede utilizarse una vela en formación si se define y se prueba. |
| Hacer comprensibles los problemas | 6 registros de reparación | El ejemplo del registro explica la utilidad de un mensaje claro; las reparaciones no cuentan todos los defectos. | Una reparación también puede formar parte de un desarrollo o una modificación. |
Algunas preguntas que quizá tengas
¿170 registros significan 170 sistemas rentables para clientes?
No. El archivo contiene 169 registros de desarrollo y uno de investigación interna. Incluye varios tipos de trabajo y no determina el número de clientes distintos ni de estrategias rentables.
¿Los ejemplos proceden de proyectos concretos de clientes?
No. Los hemos creado para que las decisiones técnicas resulten fáciles de seguir. El archivo aporta contexto, pero los ejemplos no son historias de proyectos ni resultados medidos de clientes.
¿Necesito una especificación técnica antes de contactar con POLARIS?
No. Empieza por el comportamiento de trading que deseas, un ejemplo que rechazarías y tus límites de uso. Esos detalles pueden ser el punto de partida para una especificación acordada.
¿Puedo comprobar las cifras del archivo?
Sí. Los datos enlazados permiten contar tipos de trabajo, temas principales y etiquetas exactas de funciones. Algunos totales más amplios de páginas antiguas no pueden reproducirse por completo porque sus listas de registros incluidos no son públicas.
Reescrito el 6 de septiembre de 2026. Las cifras corresponden a la instantánea publicada de 170 registros. No se revelan identidades de clientes, especificaciones privadas ni código.
