Perché chi vende segnali si ritira - pagina 7
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Tutto questo perché la % di aumento non è calcolata correttamente.
Quando un ordine viene aperto, il saldo in quel momento dovrebbe essere memorizzato. E quando l'ordine viene chiuso, la percentuale di crescita deve essere calcolata in relazione a questo saldo.
In questo caso nessun deposito o prelievo influenzerà la percentuale di crescita poiché questi cambiamenti non hanno avuto luogo all'apertura dell'ordine.
E non ci saranno manipolazioni.
Tutto questo perché la % di aumento non è calcolata correttamente.
Quando un ordine viene aperto, il saldo in quel momento dovrebbe essere memorizzato. E quando l'ordine è chiuso, la percentuale di crescita dovrebbe essere calcolata in relazione a questo saldo.
In questo caso nessun deposito o prelievo influenzerà la percentuale di crescita poiché questi cambiamenti non hanno avuto luogo all'apertura dell'ordine.
Non ci saranno manipolazioni.
Secondo il servizio, la percentuale di guadagno è calcolata"per escludere l'influenza dei prelievi e dei depositi".
Solo la percentuale di crescita non è calcolata per ogni operazione, ma tra le operazioni di bilancio (prelievi o depositi). Apparentemente questo viene fatto per ridurre il carico computazionale del sistema di calcolo.
Se siete interessati, ecco il link.
Rapporto di crescita K = (Saldo prima di BO1 / Deposito iniziale) * (Saldo prima di BO2 / Saldo dopo BO1) * ... * (Saldo prima di BOp / Saldo dopo BOp1)Guadagno percentuale = (K - 1) * 100%.
C'è un parametro nella formula, come DEPOSITO INIZIALE . Rovina l'intero quadro, se la cronologia delle operazioni di bilancio è rotta rispetto alla cronologia delle operazioni di trading. È qui (nell'ordine cronologico) che bisogna mettere in ordine le cose. Allora tutto conterà come dovrebbe!
Una cronologia rotta mostra che c'è un problema serio nel fissare i dati nel sistema dal fornitore del segnale. C'è qualche "vulnerabilità" che non è stata ancora chiusa e che viene sfruttata da alcuni "compagni avanzati"...
Come lo facciano è un mistero per me. Ma il fatto che ci sia ancora un problema è un fatto!
È molto semplice.
Il servizio di monitoraggio del segnale ha la vulnerabilità di calcolare la percentuale di profitto. Questo è ciò che viene sfruttato. Lo schema è semplice.
Si apre una o più operazioni e si aspetta un buon profitto, ad esempio il 10-20-50%, a seconda della leva. Lo scopo è quello di rilasciare fondi nella misura del deposito iniziale.
Quando ci sono abbastanza fondi liberi, il deposito iniziale viene ritirato senza chiudere le operazioni e viene introdotta una misera quantità da cui contare.
Gli scambi sono chiusi, tutti.
Non avrei mai immaginato che ci fossero degli shughly-whughly nelle trasmissioni degli scrittori di segnali.
Sembrerebbe che tutto sia trasparente. Deposito, saldo, rischi, periodo, profitto.
Grazie a tutti voi per aver postato e per avermi illuminato.
C'è un'altra caratteristica di base del servizio MQL5-Signals, che in generale è alla base di tutte queste manipolazioni - il costo fisso di abbonamento al segnale. In effetti, è una bugia, perché si scopre che la remunerazione del manager non dipende dalla reale performance finanziaria dei sottoscrittori.
L'unica pratica giusta e corretta per gestire i soldi degli altri è "% del reddito mensile dall'inizio del mese, meno le perdite nei periodi precedenti (se ci sono)". Cioè, il calcolo dovrebbe essere fatto dalla parte dell'Abbonato in base al suo profitto per il mese, incluso l'eventuale drawdown, e non dalla parte del venditore del segnale.
A proposito, questo è il motivo per cui il servizio MQL5 Signals non è molto popolare tra i gestori ragionevoli, così come altre piattaforme per la vendita di segnali (non li nomino per evitare accuse di pubblicità) che permettono ai gestori di guadagnare in % di reddito per l'intero portafoglio di abbonati.
Il circolo vizioso: non c'è un sistema equo per calcolare il profitto del manager => non ci sono praticamente manager di successo in MQL5-service, ci sono o perdenti o truffatori.
Se non c'è nessun cambiamento nel sistema di calcolo delle commissioni dei manager, tutto rimarrà lo stesso, non importa quali azioni intraprendano gli amministratori.
Mi chiedo se anche i conti PAMM possono essere manipolati in questo modo?
Il mio commento qui è stato cancellato apparentemente per il link diretto all'account PAMM, quindi vi do solo uno screenshot.
Qualcuno può spiegarmi come ha ottenuto una redditività del 48523% e, soprattutto, come ha fatto il saldo ad aumentare così tanto di punto in bianco?
Quindi, per continuare l'annosa discussione.
Renat, l'ultima volta che hai chiesto la prova che il tuo sistema di segnali non calcola correttamente gli incrementi.
Prima di questo, l'intera base di segnali era stata completamente ripulita dagli esempi, quindi logicamente non potevo trovare nulla.
Così ho fatto una prova. E nel caso tu abbia cancellato questo segnale, ho fatto delle foto.
Chi vuole ammirarlo può trovare il segnale sul mio profilo. Non posso iscrivermi perché il mio account non è verificato.
Sono stati presi accordi. Grazie per la vostra considerazione.
Non c'è nessun errore nel calcolo, ma alcune manipolazioni di bilancio combinate con una possibile storia non lineare possono portare a tali risultati.
Ecco un altro esempio di manipolazione del bilancio.
Ce n'è circa il 200%.