Да, конечно, персонально обратиться к кому-то, было б хорошо.
Если на горячую линию президента обратиться(?), могут устроить внутреннее раследование. На это конечно время надо. Так понимаю, до решения суда мало осталось.
Решение суд уже вынес - чуть выше написал об этом.
Обратиться в полицию. Там есть отдел киберпреступлений. Закрыть по 30% вместо 20% можно трактовать, как мошенничество.
Там, не будут просить принести нужные файлы. Сами придут и скачают, и посмотрят. Возможно, это не единичный случай.
Первые посты в этой теме говорят только о том, что я не понимал договорные условия. Изначально в иске я просил предоставить документы для проверки отчёта, в том числе методологию расчёта кросс-курса, которая должна быть прописана в рамочном договоре, но по факту она не полная, так как не указано какие котировки (Bid/Ask/Mid) использовать в том или ином случае - без точных формулировок нельзя проверять договор на соответствие с отчётом, а так же просил увеличить срок на проверку отчёта с 3 до 10 дней (форекс-дилер 10 дней готовит отчёт по запросу - просил равноправия), признать, что отчёты без подписи не являются документом оформленным надлежащим образом, а значит и небыли предоставлены, просил обязать предоставлять полную форму отчёта со всеми реквизитами предусмотренными договором и с показателями, необходимыми для проверки отчёта по ФЗ-39, а так же признать предоставленные отчёты недостоверными - не отражены все торговые операции, а те что отражены во многом содержат ошибки, а так же неправильно указан финансовый результат по ним - это если без деталей, хотя тут выкладывал требования.
Вот что просил - развёрнуто:
"
1.Требования о предоставлении информации и документов
1.1.Обязать ООО «Форекс» предоставить информацию и документы:
Копии Заявок, заверенных надлежащим образом, за период с 03 июня 2024 года по 31 мая 2025 года;
Выписку из лог-файла сервера ИТС в части, относящейся к моим торговым операциям за период с 03 июня 2024 года по 31 мая 2025 года включительно;
Информацию в виде справки или иного документа о ценовых значениях валютных пар (базисных активов), участвующих в расчёте финансового результата по сделкам истца и на основании которых производился расчёт кросс-курса, с указанием времени выставления котировки, участвовавшей в расчёте кросс-курса при исполнении поданных мной Заявок;
Банковскую выписку (копию) по специальному разделу номинального счёта клиента, открытого для учёта операций Истца за период с 03 июня 2024 года по 31 декабря 2024 года включительно;
Банковскую выписку (копию) по специальному разделу номинального счёта клиента, открытого для учёта операцийИстцаза период с 01 января 2025 года по 31 мая 2025 года включительно;
Рассчитанные значения показателя «Требуемое обеспечение» на каждый торговый день за период с 03.06.2024 по 31.05.2025 включительно по базисным активам.
1.2.Предоставить воспроизводимый алгоритм (методологию) расчёта кросс-курса с указанием, для каких целей и когда применяется конкретный расчёт.
2.Требования о признании отчётов недостоверными и их исправлении
2.1.Признать отчёты Форекс-дилера за 2024 и 2025 годы недостоверными в части неполного отражения Отдельных договоров и искажения финансового результата по ним.
2.2.Обязать Форекс-дилера предоставить исправленные отчёты за 2024 и 2025 годы, содержащие полную и достоверную информацию обо всех Отдельных договорах, включая даты, объёмы, цены, направления и финансовый результат по каждому.
3.Требования к форме и содержанию отчётов
3.1.Признать текущую форму отчёта, используемую ООО «Форекс», не соответствующей требованиям законодательства и Рамочного договора в части недостаточности и неопределённости информации.
3.2.Обязать ООО «Форекс» предоставлять мне отчёты по результатам торговых и неторговых операций, содержащие полную и достоверную информацию, необходимую для проверки всех этапов заключения, исполнения и прекращения отдельных договоров, в том числе:
цену базисного актива на момент открытия и закрытия позиции;
объём отдельного договора;
срок действия заявки;
размер обязательств клиента;
размер и соотношение обеспечения и обязательств;
уровень обеспечения на момент совершения операции и на момент стоп-аута;
кросс-курс с указанием составляющих его котировок;
форвардные пункты;
размер Требуемого обеспечения для заключения отдельного договора;
суммарный размер обособленного Требуемого обеспечения по совершённым торговым операциям к моменту совершения текущей торговой операции;
дату и время выставления котировки (с точностью до миллисекунды), в том числе для расчёта кросс-курса;
способ подачи заявки и место хранения документа;
идентификаторы заявок и отдельных договоров, совпадающие с данными ИТС (MT5) или сопровождаемые таблицей сопоставления.
3.3.Обязать ООО «Форекс»:
использовать в отчёте только термины, определённые в Рамочном договоре, ФЗ № 39-ФЗ и нормативных актах ЦБ РФ;
включить в форму отчёта поле для подписи клиента и предусмотреть порядок возврата подписанного экземпляра;
обеспечить наличие двух идентичных экземпляров отчёта — у Истца и у Ответчика.
4.Требования о признании нарушения порядка предоставления ежемесячных отчётов
4.1.Признать действия ООО «Форекс» по непредоставлению ежемесячных отчётов за период с июня 2024 г. по июль 2025 г. нарушающими права Истца как получателя финансовых услуг.
4.2.Обязать ответчика в течение 5 (пяти) рабочих дней со дня вступления решения суда в законную силу предоставить Истцу надлежащим образом оформленные ежемесячные отчёты за период с июня 2024 г. по июль 2025 г. в соответствии с п. 15 Рамочного договора, а именно:
по официальным каналам связи, указанным в договоре, и через инфраструктуру, принадлежащую ООО «Форекс»;
с подписью уполномоченного лица (собственноручной или ЭЦП в соответствии с ФЗ-63);
содержащие все отражённые заявки и отдельные договоры;
с полной информацией о существенных условиях отдельных договоров и номерами заявок, соответствующими данным ИТС.
5.Требования об изменении условий Рамочного договора о сроках проверки отчёта
5.1.Признать недействительным условие пункта 15.13 Рамочного договора № *****-24/РМ от 03.06.2024 года (ред. 2.3) в части установления срока для проверки клиентом отчёта форекс-дилера — 3 (три) рабочих дня.
5.2.Обязать ответчика внести изменения в действующую редакцию Рамочного договора, установив срок для проверки отчёта — не менее 10 (десяти) рабочих дней.
5.3.Обязать ответчика заключить с истцом дополнительное соглашение, предусматривающее применение указанного срока (10 рабочих дней) к отношениям, возникшим на основании предыдущих редакций Рамочного договора, в том числе к отчётам, подлежащим проверке на дату подачи настоящего иска.
6.Требование о компенсации морального вреда
6.1.Взыскать компенсацию морального вреда в размере 100 000 (Ста тысяч) рублей 00 копеек.
7.Требование о взыскании судебных расходов
7.1.Взыскать с Форекс-дилера судебные расходы (госпошлина) в размере 3000 рублей.
Я всё же нашёл, вероятно (предположительно), ошибку в расчёте стоп-аута у форекс-дилера, которая приводит к задержке закрытия позиций относительно договорных условий. И в связи с этим и в связи с тем, что заключались отдельные договора не по котировкам сохранённым в истории терминала, просил произвести перерасчёт дополнительно к требованиям пункта 2 (выше требования писал).
Выписка из письменных пояснений (готовил для суда): "
ЧАСТЬ III. ПОЧЕМУ ФАКТИЧЕСКИЕ НАСТРОЙКИ НЕ ОТВЕЧАЮТ УСЛОВИЯМ ДОГОВОРА ДАЖЕ С ДОПУЩЕНИЯМИ
Допущения, принимаемые в целях настоящего анализа
Официальная методика расчёта показателя «Обязательства Клиента» (п. 9 ст. 4.1 ФЗ-39) ни в Рамочном договоре, ни в Базовых стандартах не определена: в них отсутствует математический алгоритм (не указано, какая котировка — Bid, Ask или Mid — используется, не установлены правила агрегации позиций и перерасчёта). Запрос Истца в СРО АФД от 06.08.2026 о предоставлении алгоритма расчёта оставлен без удовлетворения (ответ от 24.08.2026: СРО АФД «не обладает полномочиями предоставлять математические алгоритмы расчета размера обязательств клиента»); об истребовании соответствующей методики (стандарта СРО) подано ходатайство № 25. В этих условиях в целях настоящего анализа (части III–V) принимаются следующие допущения (предположения):
1. «Нереализованный финансовый результат» рассчитывается по текущим рыночным котировкам для противоположного (встречного) заключения Отдельного договора — так же, как это делает терминал (п. 1.4);
2. «Требуемое обеспечение» не превышает нижнюю границу 1/32 (п. 12.10.2 ред. 2.3);
3. показатели «Обязательства» (в значении п. 9 ст. 4.1 ФЗ-39) и «Обязательства Клиента» (Рамочный договор, Базовый стандарт) рассчитываются так же, как база для расчёта маржи, — по базовой (первой) валюте валютной пары (базисного актива);
4. кросс-курс для расчёта «Требуемого обеспечения» рассчитывается так же, как и для маржи (по внутренним курсам сервера);
5. закрытие всех позиций происходит синхронно в момент наступления события стоп-аута (фактические задержки подачи заявок модулем Форекс-дилера — порядка 50 миллисекунд — см. п. 2.5.1); на этом допущении основаны числовые оценки части V.
6. «Цена Отдельного договора» (Рамочный договор) и «Стоимость» (терминал MetaTrader 5) признаются тождественными (допущение, обоснованное в п. 1.7); при таком допущении показатели Обязательств Клиента в Рамочном договоре и в Базовом стандарте могут быть представлены как сумма значений показателя «Стоимость» по всем открытым позициям.
Допущения введены для устойчивости выводов: даже если суд придёт к заключению, что все договорные показатели («Требуемое обеспечение», «Обязательства Клиента», «Обеспечение», в том числе рассчитанное по встречным ценам) исчислены корректно, то и тогда формулы стоп-аута платформы не совпадут с договорными (п. 3.1): расхождение сохраняется при прочих равных условиях, и для его устранения потребовалось бы изменить коэффициенты и настройки сервера (часть IV), что Форекс-дилером сделано не было.
3.1. Математическое обоснование
Введём обозначения:
–Об — Обязательства Клиента (суммарная денежная оценка всех Открытых позиций в валюте счёта, п. 4 Рамочного договора);
–Обесп — Обеспечение (денежные средства с учётом реализованного и нереализованного финансового результата, п. 4, 12.2 Рамочного договора);
Договорная модель (п. 12.8–12.9 Рамочного договора, п. 10 ст. 4.1 ФЗ-39). Стоп-аут наступает, когда соотношение Обеспечения и Обязательств достигает Минимального уровня обеспечения:
Обесп / Об = 1/39 (для неквалифицированных инвесторов по валютным парам),
т.е. срок исполнения обязательств наступает, когда Обеспечение снижается до Об / 39 (≈ 2,564 % от Обязательств).
Платформенная модель (факт). Стоп-аут наступает, когда уровень маржи достигает 81 % (ACCOUNT_MARGIN_SO_SO = 81 %), т.е.:
Е / М × 100 = 81 %,илиЕ = 0,81 × М.
Маржа по инструменту USDJPYrfd в режиме Forex (п. 1.1, 1.3, 2.1, 2.3):
М = Об / Плечо × К = Об / 40 × 1,25 = 0,03125 × Об = Об / 32,
где К = 1,25 — коэффициент маржи (Margin_Rate) по инструменту (установлен Форекс-дилером), плечо 1:40 (ACCOUNT_LEVERAGE). Доля маржи от номинала 1/32 совпадает с нижней границей Требуемого обеспечения 1/32 (п. 12.10.2 Рамочного договора), что подтверждает: Форекс-дилер фактически приравнял маржу к Требуемому обеспечению на нижней границе.
Сопоставление формул. Подставим М = Об/32 в платформенную модель:
Е = 0,81 × Об / 32 = 0,0253125 × Об = Об / 39,506.
Сравним с договорным порогом Об/39 = 0,0256410 × Об:
–1/39 = 0,0256410 (договорный порог);
–1/39,506 = 0,0253125 (фактический порог платформы при Е = 0,81 × Об/32).
Поскольку 0,0253125 < 0,0256410, фактический порог платформы ниже договорного. Разница составляет:
Следовательно, при понижении Обеспечения (Средств):
–сначала достигается договорный порог Об/39 (момент, когда по договору срок исполнения обязательств уже наступил),
–затем — лишь через дополнительную просадку δ×Об — срабатывает платформенный триггер 81 %.
Иными словами, даже при самом благоприятном для Форекс-дилера допущении (Маржа = Требуемое обеспечение = 1/32 номинала) платформенный механизм стоп-аута закрывает позиции позже договорного момента, причиняя Клиенту дополнительный убыток в размере δ×Об, который при закрытии позиций переходит в доход Форекс-дилера (Форекс-дилер является контрагентом по Отдельным договорам — п. 5.1 Рамочного договора).
Из п. 3.1 следует, что две формулы — договорная (Обеспечение/Обязательства ≤ 1/39) и платформенная (Средства/Маржа ≤ 81 %) — не тождественны. Они совпали бы лишь при условии, что уровень StopOut был бы установлен равным:
SO = 32/39 × 100 % = 82,05 % (а не 81 %).
Договорный момент наступления стоп-аута соответствует уровню StopOut82,05 % (SO = 32/39 × 100 %). Установив вместо него 81 %, Форекс-дилер сдвинул фактический момент принудительного закрытия за договорный предел: позиции закрываются позже момента, предусмотренного договором, — лишь после дополнительной просадки Обеспечения на величину δ×Об, что увеличивает убыток Клиента. Направленность расхождения неслучайна: чем ниже заданный процент, тем позже (при тем большем убытке Клиента) срабатывает стоп-аут и тем больше доход Форекс-дилера как контрагента по Отдельным договорам. Напротив, установка уровня выше 82,05 % (например, 84 %) закрывала бы позиции раньше договорного момента — с меньшим для Форекс-дилера доходом и с риском претензий Клиентов о преждевременном закрытии. Фактически выбрана настройка, при которой убыток Клиента систематически превышает договорный предел.
3.2.2. По данным Рамочного договора и понятия «Требуемое обеспечение»
1) «Требуемое обеспечение» не является «Обязательствами Клиента». Пункт 4 Рамочного договора (редакция 2.3): «Обязательства Клиента — суммарная денежная оценка всех Открытых позиций Клиента в Валюте счета». «Требуемое обеспечение» — расчётная величина, минимальное значение которой определяется через размер Обязательств Клиента: оно не может быть меньше 1/32 от Обязательств (п. 12.10.2 Рамочного договора). При этом в натуральном выражении («в деньгах») расчётная пропорция может оказаться и выше нижнего предела (например, 1/10 — то есть делитель больше 32), однако не может быть ниже 1/32 (делитель не может быть меньше 32). Таким образом, «Требуемое обеспечение» — производная от Обязательств расчётная величина, а не сами Обязательства; она пересчитывается Форекс-дилером в порядке п. 12.11 Рамочного договора и ст. 7 Базового стандарта на каждый торговый день. (Приведённое описание даётся с учётом допущений, принятых в настоящей записке.) Отождествление «маржи» и «Обязательств» математически некорректно.
2) «Маржа» ИТС ≠ «Требуемое обеспечение». «Требуемое обеспечение» — фиксированная на торговый день величина (п. 7.1 Базового стандарта, п. 12.11 Рамочного договора). Маржа в режиме Forex рассчитывается от текущей цены на каждом тике (п. 2.3). Они совпадают только в момент открытия позиции при условии точного равенства применённых коэффициентов. Даже с допущением «Маржа = Требуемое обеспечение = Об/32» штатная формула стоп-аута не обеспечивает договорного порога 1/39 (п. 3.1).
3) Единый процентный триггер для всех инструментов противоречит методике Требуемого обеспечения.VaR-показатель (а следовательно, и Требуемое обеспечение) индивидуален для каждого базисного актива; записи же «SO 80,93 % GBPCHFrfd», «SO … USDJPYrfd» и т.п. демонстрируют единый уровень ~80–81 % для всех инструментов (п. 2.5.1), что подтверждает использование единого технического триггера платформы, а не договорного механизма.
4) Утверждение Форекс-дилера из письма № XXXXXX/XX («в графе "маржа" в ИТС указан общий размер требуемого обеспечения») при буквальном прочтении означает признание тождества Маржа = Требуемое обеспечение. Но тогда стоп-аут по платформе должен был бы наступать при соотношении Об/39,506 (п. 3.1), а не при договорном Об/39 — то есть даже при собственном допущении Форекс-дилера его настройки не соответствуют договору.
5) Точная реализация договорной модели стоп-аута штатными средствами платформы невозможна; возможна лишь её аппроксимация с допущениями. В платформе отсутствуют понятия «Обязательства Клиента» и «Обеспечение» в договорном смысле (п. 1.6); расчёт ведётся по техническим величинам «Средства» и «Маржа». С определёнными допущениями (раздел «Допущения» перед п. 3.1) соответствие договорной модели может быть лишь приближено — путём корректного подбора параметров сервера (часть IV) либо путём разработки отдельного программного модуля, рассчитывающего показатели по алгоритму Рамочного договора. Допущения введены для того, чтобы даже в случае признания судом корректности расчёта «Требуемого обеспечения», «Обязательств Клиента» и «Обеспечения» (в том числе по встречным ценам) расчётные величины всё равно не соответствовали бы договору: формулы платформы не тождественны договорным (п. 3.1), и для их приведения в соответствие потребовалось бы изменить коэффициенты и настройки сервера, что Форекс-дилером не сделано.
3.2.3. Занижение показателя «Средства» (Обеспечение) на величину спреда (расчёт по ценам ликвидации)
Как показано в п. 1.4, нереализованный финансовый результат в ИТС рассчитывается по ценам обратной сделки (для Buy — Bid, для Sell — Ask), т.е. «Средства» занижены на величину спреда по всем открытым позициям. Рамочный договор такого занижения не предусматривает: «Нереализованный финансовый результат» определён (п. 4) как разница цены Отдельного договора на момент заключения и на дату Расчётов — без указания на цены обратной сделки. Следствия:
1. расчёт «Уровня обеспечения» (Обеспечение/Обязательства) в ИТС производится с заниженным на спред числителем — момент наступления стоп-аута искажается (наступает раньше, чем при расчёте по договору);
2. Клиент не имеет встроенной в терминал технической возможности воспроизвести значения «Средств» из данных терминала, поскольку спред включается в расчёт автоматически и его величина в каждый момент времени известна только серверу;
3. таким образом, даже показанный Клиенту уровень маржи (например, 80,93 %) не соответствует договорному соотношению Обеспечение/Обязательства.
3.3. Числовой пример (иллюстративный)
Таблица 2. Пример расчёта момента стоп-аута при номинале Об = 120 000 руб.
Показатель
Значение
Примечание
Баланс (Обеспечение на момент входа)
5 000 руб.
денежные средства на счёте
Обязательства Клиента (Об)
120 000 руб.
номинал открытой позиции
Плечо (ACCOUNT_LEVERAGE)
1 : 40
0,025
Коэффициент маржи (Margin_Rate)
1,25
по инструменту
Маржа М = Об/40 × 1,25
3 750 руб.
Об/32
Нереализованный фин. результат (НФР)
− 1 963 руб.
факт на момент стоп-аута
Средства Е = Баланс + НФР
3 037 руб.
—
Уровень маржи Е/М × 100
80,99 %
< 81 % → срабатывание
Соотношение Е/Об
0,025308 = 1/39,51
ниже договорного порога
Договорный порог Обесп = Об/39
3 076,92 руб.
НФР = − 1 923,08 руб.
Дополнительный убыток сверх договора
≈ 39,92 руб.
1 963 − 1 923,08
Из таблицы 2 видно: на момент фактического стоп-аута соотношение Средств к Обязательствам составило 1/39,51 вместо допустимого договором порога 1/39, т.е. Форекс-дилер допустил просадку Обеспечения ниже договорного минимума и закрыл позиции Клиента с дополнительным убытком ≈ 39,92 руб. с каждой такой просадки (при номинале 120 000 руб.), который перешёл в доход Форекс-дилера как контрагента.
ЧАСТЬ IV. КАК ФОРЕКС-ДИЛЕР МОГ НАСТРОИТЬ СЕРВЕР С УЧЁТОМ ДОПУЩЕНИЙ
Задача точной настройки: обеспечить, чтобы момент срабатывания стоп-аута в платформе совпадал с договорным моментом (Обеспечение/Обязательства = 1/39) при допущении «Маржа = Требуемое обеспечение». У Форекс-дилера имелось как минимум четыре независимых технических способа добиться этого, не прибегая к доработке ПО.
4.1. Вариант А — изменение уровня стоп-аута (процента)
Изменив лишь один параметр сервера — ACCOUNT_MARGIN_SO_SO — можно было достичь точного соответствия договору:
SO_точи = 32/39 × 100 % = 82,0513 % ≈ 82,05 %.
Проверка: Е/М = 0,820513; М = Об/32 → Е = 0,820513 × Об/32 = 0,02564103 × Об = Об/39 — в точности договорной порог. Фактически установлен 81 % вместо 82,05 %. Погрешность в 1,05 процентного пункта осталась не устранённой, хотя для её устранения достаточно было изменить одно значение в настройках сервера.
4.2. Вариант Б — изменение коэффициента маржи (Margin_Rate)
При сохранении уровня стоп-аута 81 % точное соответствие договору достигается установкой коэффициента маржи:
К_точи = 40 / 31,59 = 1,26622... ≈ 1,266.
Проверка: М = Об/40 × 1,266 = Об/31,59; Е = 0,81 × Об/31,59 = 0,025641 × Об = Об/39. Фактически установлен коэффициент 1,25 вместо 1,266 (для USDJPYrfd). Несложный пересчёт обнаруживает отставание фактического порога от договорного на δ = 0,0003285 номинала (п. 3.1).
4.3. Вариант В — изменение кредитного плеча
При уровне стоп-аута 81 % и коэффициенте 1,25 точное соответствие договору достигается установкой плеча:
Фактически установлено плечо 1:40. Отклонение в 0,51 единицы плеча также не было устранено.
4.4. Вариант Г — фиксированная маржа, равная «Требуемому обеспечению»
Штатные возможности сервера MetaTrader 5 позволяют задать фиксированную маржу (поле «Начальная маржа» / «Поддерживающая маржа» в спецификации символа), при которой расчёт от текущей цены не применяется [Ист. 1, Ист. 2]:
Если в спецификации символа в поле "Начальная маржа" задано какое-либо значение, отличное от нуля, то вышеуказанные формулы расчета маржи перестают действовать... Для типов расчета Forex и ContractsLeverage дополнительно учитывается кредитное плечо: Объем в лотах * Начальная маржа / Кредитное плечо.
Установив фиксированную маржу на лот в размере Номинала/32 / Плечо (в валюте маржи) и обновляя её ежедневно в соответствии с публикуемым «Требуемым обеспечением», Форекс-дилер мог бы обеспечить: (а) точное равенство Маржа = Требуемое обеспечение, (б) стабильный (не зависящий от тиковой цены) размер зарезервированных средств, соответствующий п. 12.12 Рамочного договора — «сумма денежных средств, равная размеру Требуемого обеспечения, не включается в расчет свободных денежных средств». Именно такой режим — фиксированное значение, изменяемое ежедневно, — соответствует по смыслу понятию «Требуемое обеспечение», что отмечалось Истцом и в ходатайстве № 14 (справка к платформе: платформа допускает настройку режимов расчёта маржинальных требований, в том числе «ForexNoLeverage» в сочетании с настройкой валюты маржинальных требований). Форекс-дилер указанную возможность не использовал, установив режим «Forex» с расчётом от текущей цены.
4.5. Выводы по части IV
Таблица 3. Возможные способы точной настройки и фактически установленные параметры
Параметр
Точное значение (по договору)
Фактически установлено
Отклонение
Уровень Stop Out
82,05 %
81 %
− 1,05 п.п.
Коэффициент маржи USDJPY
≈ 1,266
1,25
− 0,016
Кредитное плечо
≈ 1 : 39,49
1 : 40
+ 0,51
Режим маржи
фиксированная маржа / ежедневное обновление
Forex (от текущей цены)
принципиально
Все четыре способа являлись штатными и не требовали доработки программного обеспечения. Форекс-дилер, который, как установлено (п. 2.5.2), способен разрабатывать и эксплуатировать дополнительный программный модуль (подача заявок от имени Клиента), не мог не осознавать наличия данных возможностей. Выбранная же комбинация параметров (81 %; 1,25; 1:40; Forex) систематически смещает момент стоп-аута в сторону большего убытка Клиента, что не является ни случайным, ни вынужденным техническим ограничением платформы.
Вы так упоролись в эту тему глубоко - что обратной дороги нет - идите до Верховного... и не суда... главнокомандующего... )))
Кстати - написал - в личку - тоже посмотреть можете - сайт и название... сам думал обращаться к ним, когда решал вопросы свои по оплате труда (еще в процессе - заседание назначено на декабрь)
П.С. Обратной дороги нет и поражение не приемлемо- мочите их! Тварей!
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
почём вышло ?
Да, конечно, персонально обратиться к кому-то, было б хорошо.
Если на горячую линию президента обратиться(?), могут устроить внутреннее раследование. На это конечно время надо. Так понимаю, до решения суда мало осталось.
Решение суд уже вынес - чуть выше написал об этом.
Обратиться в полицию. Там есть отдел киберпреступлений. Закрыть по 30% вместо 20% можно трактовать, как мошенничество.
Там, не будут просить принести нужные файлы. Сами придут и скачают, и посмотрят. Возможно, это не единичный случай.
Первые посты в этой теме говорят только о том, что я не понимал договорные условия. Изначально в иске я просил предоставить документы для проверки отчёта, в том числе методологию расчёта кросс-курса, которая должна быть прописана в рамочном договоре, но по факту она не полная, так как не указано какие котировки (Bid/Ask/Mid) использовать в том или ином случае - без точных формулировок нельзя проверять договор на соответствие с отчётом, а так же просил увеличить срок на проверку отчёта с 3 до 10 дней (форекс-дилер 10 дней готовит отчёт по запросу - просил равноправия), признать, что отчёты без подписи не являются документом оформленным надлежащим образом, а значит и небыли предоставлены, просил обязать предоставлять полную форму отчёта со всеми реквизитами предусмотренными договором и с показателями, необходимыми для проверки отчёта по ФЗ-39, а так же признать предоставленные отчёты недостоверными - не отражены все торговые операции, а те что отражены во многом содержат ошибки, а так же неправильно указан финансовый результат по ним - это если без деталей, хотя тут выкладывал требования.
Вот что просил - развёрнуто:
"
1. Требования о предоставлении информации и документов
1.1. Обязать ООО «Форекс» предоставить информацию и документы:
1.2. Предоставить воспроизводимый алгоритм (методологию) расчёта кросс-курса с указанием, для каких целей и когда применяется конкретный расчёт.
2. Требования о признании отчётов недостоверными и их исправлении
2.1. Признать отчёты Форекс-дилера за 2024 и 2025 годы недостоверными в части неполного отражения Отдельных договоров и искажения финансового результата по ним.
2.2. Обязать Форекс-дилера предоставить исправленные отчёты за 2024 и 2025 годы, содержащие полную и достоверную информацию обо всех Отдельных договорах, включая даты, объёмы, цены, направления и финансовый результат по каждому.
3. Требования к форме и содержанию отчётов
3.1. Признать текущую форму отчёта, используемую ООО «Форекс», не соответствующей требованиям законодательства и Рамочного договора в части недостаточности и неопределённости информации.
3.2. Обязать ООО «Форекс» предоставлять мне отчёты по результатам торговых и неторговых операций, содержащие полную и достоверную информацию, необходимую для проверки всех этапов заключения, исполнения и прекращения отдельных договоров, в том числе:
3.3. Обязать ООО «Форекс»:
4. Требования о признании нарушения порядка предоставления ежемесячных отчётов
4.1. Признать действия ООО «Форекс» по непредоставлению ежемесячных отчётов за период с июня 2024 г. по июль 2025 г. нарушающими права Истца как получателя финансовых услуг.
4.2. Обязать ответчика в течение 5 (пяти) рабочих дней со дня вступления решения суда в законную силу предоставить Истцу надлежащим образом оформленные ежемесячные отчёты за период с июня 2024 г. по июль 2025 г. в соответствии с п. 15 Рамочного договора, а именно:
5. Требования об изменении условий Рамочного договора о сроках проверки отчёта
5.1. Признать недействительным условие пункта 15.13 Рамочного договора № *****-24/РМ от 03.06.2024 года (ред. 2.3) в части установления срока для проверки клиентом отчёта форекс-дилера — 3 (три) рабочих дня.
5.2. Обязать ответчика внести изменения в действующую редакцию Рамочного договора, установив срок для проверки отчёта — не менее 10 (десяти) рабочих дней.
5.3. Обязать ответчика заключить с истцом дополнительное соглашение, предусматривающее применение указанного срока (10 рабочих дней) к отношениям, возникшим на основании предыдущих редакций Рамочного договора, в том числе к отчётам, подлежащим проверке на дату подачи настоящего иска.
6. Требование о компенсации морального вреда
6.1. Взыскать компенсацию морального вреда в размере 100 000 (Ста тысяч) рублей 00 копеек.
7. Требование о взыскании судебных расходов
7.1. Взыскать с Форекс-дилера судебные расходы (госпошлина) в размере 3000 рублей.
"
почём вышло ?
Вступит решение суда в силу, ответчик обратиться в суд с ходатайством и присудит суд сумму. До этого мне не известно.
Могу сказать, что я потратил очень много сил, времени и здоровья.
Я всё же нашёл, вероятно (предположительно), ошибку в расчёте стоп-аута у форекс-дилера, которая приводит к задержке закрытия позиций относительно договорных условий. И в связи с этим и в связи с тем, что заключались отдельные договора не по котировкам сохранённым в истории терминала, просил произвести перерасчёт дополнительно к требованиям пункта 2 (выше требования писал).
Выписка из письменных пояснений (готовил для суда):
"
ЧАСТЬ III. ПОЧЕМУ ФАКТИЧЕСКИЕ НАСТРОЙКИ НЕ ОТВЕЧАЮТ УСЛОВИЯМ ДОГОВОРА ДАЖЕ С ДОПУЩЕНИЯМИ
Допущения, принимаемые в целях настоящего анализа
Официальная методика расчёта показателя «Обязательства Клиента» (п. 9 ст. 4.1 ФЗ-39) ни в Рамочном договоре, ни в Базовых стандартах не определена: в них отсутствует математический алгоритм (не указано, какая котировка — Bid, Ask или Mid — используется, не установлены правила агрегации позиций и перерасчёта). Запрос Истца в СРО АФД от 06.08.2026 о предоставлении алгоритма расчёта оставлен без удовлетворения (ответ от 24.08.2026: СРО АФД «не обладает полномочиями предоставлять математические алгоритмы расчета размера обязательств клиента»); об истребовании соответствующей методики (стандарта СРО) подано ходатайство № 25. В этих условиях в целях настоящего анализа (части III–V) принимаются следующие допущения (предположения):
1. «Нереализованный финансовый результат» рассчитывается по текущим рыночным котировкам для противоположного (встречного) заключения Отдельного договора — так же, как это делает терминал (п. 1.4);
2. «Требуемое обеспечение» не превышает нижнюю границу 1/32 (п. 12.10.2 ред. 2.3);
3. показатели «Обязательства» (в значении п. 9 ст. 4.1 ФЗ-39) и «Обязательства Клиента» (Рамочный договор, Базовый стандарт) рассчитываются так же, как база для расчёта маржи, — по базовой (первой) валюте валютной пары (базисного актива);
4. кросс-курс для расчёта «Требуемого обеспечения» рассчитывается так же, как и для маржи (по внутренним курсам сервера);
5. закрытие всех позиций происходит синхронно в момент наступления события стоп-аута (фактические задержки подачи заявок модулем Форекс-дилера — порядка 50 миллисекунд — см. п. 2.5.1); на этом допущении основаны числовые оценки части V.
6. «Цена Отдельного договора» (Рамочный договор) и «Стоимость» (терминал MetaTrader 5) признаются тождественными (допущение, обоснованное в п. 1.7); при таком допущении показатели Обязательств Клиента в Рамочном договоре и в Базовом стандарте могут быть представлены как сумма значений показателя «Стоимость» по всем открытым позициям.
Допущения введены для устойчивости выводов: даже если суд придёт к заключению, что все договорные показатели («Требуемое обеспечение», «Обязательства Клиента», «Обеспечение», в том числе рассчитанное по встречным ценам) исчислены корректно, то и тогда формулы стоп-аута платформы не совпадут с договорными (п. 3.1): расхождение сохраняется при прочих равных условиях, и для его устранения потребовалось бы изменить коэффициенты и настройки сервера (часть IV), что Форекс-дилером сделано не было.
3.1. Математическое обоснование
Введём обозначения:
– Об — Обязательства Клиента (суммарная денежная оценка всех Открытых позиций в валюте счёта, п. 4 Рамочного договора);
– Обесп — Обеспечение (денежные средства с учётом реализованного и нереализованного финансового результата, п. 4, 12.2 Рамочного договора);
– М — Маржа (зарезервированные залоговые средства) ИТС;
– Е — Средства (Equity) ИТС.
Договорная модель (п. 12.8–12.9 Рамочного договора, п. 10 ст. 4.1 ФЗ-39). Стоп-аут наступает, когда соотношение Обеспечения и Обязательств достигает Минимального уровня обеспечения:
Обесп / Об = 1/39 (для неквалифицированных инвесторов по валютным парам),
т.е. срок исполнения обязательств наступает, когда Обеспечение снижается до Об / 39 (≈ 2,564 % от Обязательств).
Платформенная модель (факт). Стоп-аут наступает, когда уровень маржи достигает 81 % (ACCOUNT_MARGIN_SO_SO = 81 %), т.е.:
Е / М × 100 = 81 %, или Е = 0,81 × М.
Маржа по инструменту USDJPYrfd в режиме Forex (п. 1.1, 1.3, 2.1, 2.3):
М = Об / Плечо × К = Об / 40 × 1,25 = 0,03125 × Об = Об / 32,
где К = 1,25 — коэффициент маржи (Margin_Rate) по инструменту (установлен Форекс-дилером), плечо 1:40 (ACCOUNT_LEVERAGE). Доля маржи от номинала 1/32 совпадает с нижней границей Требуемого обеспечения 1/32 (п. 12.10.2 Рамочного договора), что подтверждает: Форекс-дилер фактически приравнял маржу к Требуемому обеспечению на нижней границе.
Сопоставление формул. Подставим М = Об/32 в платформенную модель:
Е = 0,81 × Об / 32 = 0,0253125 × Об = Об / 39,506.
Сравним с договорным порогом Об/39 = 0,0256410 × Об:
– 1/39 = 0,0256410 (договорный порог);
– 1/39,506 = 0,0253125 (фактический порог платформы при Е = 0,81 × Об/32).
Поскольку 0,0253125 < 0,0256410, фактический порог платформы ниже договорного. Разница составляет:
δ = 1/39 − 0,81/32 = 0,0256410 − 0,0253125 = 0,0003285 (≈ 0,0329 % от номинала).
Следовательно, при понижении Обеспечения (Средств):
– сначала достигается договорный порог Об/39 (момент, когда по договору срок исполнения обязательств уже наступил),
– затем — лишь через дополнительную просадку δ×Об — срабатывает платформенный триггер 81 %.
Иными словами, даже при самом благоприятном для Форекс-дилера допущении (Маржа = Требуемое обеспечение = 1/32 номинала) платформенный механизм стоп-аута закрывает позиции позже договорного момента, причиняя Клиенту дополнительный убыток в размере δ×Об, который при закрытии позиций переходит в доход Форекс-дилера (Форекс-дилер является контрагентом по Отдельным договорам — п. 5.1 Рамочного договора).
Таблица 1. Сопоставление формул стоп-аута
Параметр
Договор (п. 12.8–12.9)
Платформа MT5 (факт)
Формула триггера
Обесп / Об ≤ 1/39
Е / М × 100 ≤ 81 %
Порог в долях номинала
1/39 = 0,0256410
0,81 × 1/32 = 0,0253125 (1/39,506)
Момент наступления
раньше (при меньшем убытке)
позже (при большем убытке)
Разница δ
—
0,0003285 × Об
"
"
3.2. Логическое обоснование
3.2.1. По данным математического обоснования
Из п. 3.1 следует, что две формулы — договорная (Обеспечение/Обязательства ≤ 1/39) и платформенная (Средства/Маржа ≤ 81 %) — не тождественны. Они совпали бы лишь при условии, что уровень Stop Out был бы установлен равным:
SO = 32/39 × 100 % = 82,05 % (а не 81 %).
Договорный момент наступления стоп-аута соответствует уровню Stop Out 82,05 % (SO = 32/39 × 100 %). Установив вместо него 81 %, Форекс-дилер сдвинул фактический момент принудительного закрытия за договорный предел: позиции закрываются позже момента, предусмотренного договором, — лишь после дополнительной просадки Обеспечения на величину δ×Об, что увеличивает убыток Клиента. Направленность расхождения неслучайна: чем ниже заданный процент, тем позже (при тем большем убытке Клиента) срабатывает стоп-аут и тем больше доход Форекс-дилера как контрагента по Отдельным договорам. Напротив, установка уровня выше 82,05 % (например, 84 %) закрывала бы позиции раньше договорного момента — с меньшим для Форекс-дилера доходом и с риском претензий Клиентов о преждевременном закрытии. Фактически выбрана настройка, при которой убыток Клиента систематически превышает договорный предел.
3.2.2. По данным Рамочного договора и понятия «Требуемое обеспечение»
1) «Требуемое обеспечение» не является «Обязательствами Клиента». Пункт 4 Рамочного договора (редакция 2.3): «Обязательства Клиента — суммарная денежная оценка всех Открытых позиций Клиента в Валюте счета». «Требуемое обеспечение» — расчётная величина, минимальное значение которой определяется через размер Обязательств Клиента: оно не может быть меньше 1/32 от Обязательств (п. 12.10.2 Рамочного договора). При этом в натуральном выражении («в деньгах») расчётная пропорция может оказаться и выше нижнего предела (например, 1/10 — то есть делитель больше 32), однако не может быть ниже 1/32 (делитель не может быть меньше 32). Таким образом, «Требуемое обеспечение» — производная от Обязательств расчётная величина, а не сами Обязательства; она пересчитывается Форекс-дилером в порядке п. 12.11 Рамочного договора и ст. 7 Базового стандарта на каждый торговый день. (Приведённое описание даётся с учётом допущений, принятых в настоящей записке.) Отождествление «маржи» и «Обязательств» математически некорректно.
2) «Маржа» ИТС ≠ «Требуемое обеспечение». «Требуемое обеспечение» — фиксированная на торговый день величина (п. 7.1 Базового стандарта, п. 12.11 Рамочного договора). Маржа в режиме Forex рассчитывается от текущей цены на каждом тике (п. 2.3). Они совпадают только в момент открытия позиции при условии точного равенства применённых коэффициентов. Даже с допущением «Маржа = Требуемое обеспечение = Об/32» штатная формула стоп-аута не обеспечивает договорного порога 1/39 (п. 3.1).
3) Единый процентный триггер для всех инструментов противоречит методике Требуемого обеспечения. VaR-показатель (а следовательно, и Требуемое обеспечение) индивидуален для каждого базисного актива; записи же «SO 80,93 % GBPCHFrfd», «SO … USDJPYrfd» и т.п. демонстрируют единый уровень ~80–81 % для всех инструментов (п. 2.5.1), что подтверждает использование единого технического триггера платформы, а не договорного механизма.
4) Утверждение Форекс-дилера из письма № XXXXXX/XX («в графе "маржа" в ИТС указан общий размер требуемого обеспечения») при буквальном прочтении означает признание тождества Маржа = Требуемое обеспечение. Но тогда стоп-аут по платформе должен был бы наступать при соотношении Об/39,506 (п. 3.1), а не при договорном Об/39 — то есть даже при собственном допущении Форекс-дилера его настройки не соответствуют договору.
5) Точная реализация договорной модели стоп-аута штатными средствами платформы невозможна; возможна лишь её аппроксимация с допущениями. В платформе отсутствуют понятия «Обязательства Клиента» и «Обеспечение» в договорном смысле (п. 1.6); расчёт ведётся по техническим величинам «Средства» и «Маржа». С определёнными допущениями (раздел «Допущения» перед п. 3.1) соответствие договорной модели может быть лишь приближено — путём корректного подбора параметров сервера (часть IV) либо путём разработки отдельного программного модуля, рассчитывающего показатели по алгоритму Рамочного договора. Допущения введены для того, чтобы даже в случае признания судом корректности расчёта «Требуемого обеспечения», «Обязательств Клиента» и «Обеспечения» (в том числе по встречным ценам) расчётные величины всё равно не соответствовали бы договору: формулы платформы не тождественны договорным (п. 3.1), и для их приведения в соответствие потребовалось бы изменить коэффициенты и настройки сервера, что Форекс-дилером не сделано.
3.2.3. Занижение показателя «Средства» (Обеспечение) на величину спреда (расчёт по ценам ликвидации)
Как показано в п. 1.4, нереализованный финансовый результат в ИТС рассчитывается по ценам обратной сделки (для Buy — Bid, для Sell — Ask), т.е. «Средства» занижены на величину спреда по всем открытым позициям. Рамочный договор такого занижения не предусматривает: «Нереализованный финансовый результат» определён (п. 4) как разница цены Отдельного договора на момент заключения и на дату Расчётов — без указания на цены обратной сделки. Следствия:
1. расчёт «Уровня обеспечения» (Обеспечение/Обязательства) в ИТС производится с заниженным на спред числителем — момент наступления стоп-аута искажается (наступает раньше, чем при расчёте по договору);
2. Клиент не имеет встроенной в терминал технической возможности воспроизвести значения «Средств» из данных терминала, поскольку спред включается в расчёт автоматически и его величина в каждый момент времени известна только серверу;
3. таким образом, даже показанный Клиенту уровень маржи (например, 80,93 %) не соответствует договорному соотношению Обеспечение/Обязательства.
3.3. Числовой пример (иллюстративный)
Таблица 2. Пример расчёта момента стоп-аута при номинале Об = 120 000 руб.
Показатель
Значение
Примечание
Баланс (Обеспечение на момент входа)
5 000 руб.
денежные средства на счёте
Обязательства Клиента (Об)
120 000 руб.
номинал открытой позиции
Плечо (ACCOUNT_LEVERAGE)
1 : 40
0,025
Коэффициент маржи (Margin_Rate)
1,25
по инструменту
Маржа М = Об/40 × 1,25
3 750 руб.
Об/32
Нереализованный фин. результат (НФР)
− 1 963 руб.
факт на момент стоп-аута
Средства Е = Баланс + НФР
3 037 руб.
—
Уровень маржи Е/М × 100
80,99 %
< 81 % → срабатывание
Соотношение Е/Об
0,025308 = 1/39,51
ниже договорного порога
Договорный порог Обесп = Об/39
3 076,92 руб.
НФР = − 1 923,08 руб.
Дополнительный убыток сверх договора
≈ 39,92 руб.
1 963 − 1 923,08
Из таблицы 2 видно: на момент фактического стоп-аута соотношение Средств к Обязательствам составило 1/39,51 вместо допустимого договором порога 1/39, т.е. Форекс-дилер допустил просадку Обеспечения ниже договорного минимума и закрыл позиции Клиента с дополнительным убытком ≈ 39,92 руб. с каждой такой просадки (при номинале 120 000 руб.), который перешёл в доход Форекс-дилера как контрагента.
"
И ещё чуток:
"
ЧАСТЬ IV. КАК ФОРЕКС-ДИЛЕР МОГ НАСТРОИТЬ СЕРВЕР С УЧЁТОМ ДОПУЩЕНИЙ
Задача точной настройки: обеспечить, чтобы момент срабатывания стоп-аута в платформе совпадал с договорным моментом (Обеспечение/Обязательства = 1/39) при допущении «Маржа = Требуемое обеспечение». У Форекс-дилера имелось как минимум четыре независимых технических способа добиться этого, не прибегая к доработке ПО.
4.1. Вариант А — изменение уровня стоп-аута (процента)
Изменив лишь один параметр сервера — ACCOUNT_MARGIN_SO_SO — можно было достичь точного соответствия договору:
SO_точи = 32/39 × 100 % = 82,0513 % ≈ 82,05 %.
Проверка: Е/М = 0,820513; М = Об/32 → Е = 0,820513 × Об/32 = 0,02564103 × Об = Об/39 — в точности договорной порог. Фактически установлен 81 % вместо 82,05 %. Погрешность в 1,05 процентного пункта осталась не устранённой, хотя для её устранения достаточно было изменить одно значение в настройках сервера.
4.2. Вариант Б — изменение коэффициента маржи (Margin_Rate)
При сохранении уровня стоп-аута 81 % точное соответствие договору достигается установкой коэффициента маржи:
К_точи = 40 / 31,59 = 1,26622... ≈ 1,266.
Проверка: М = Об/40 × 1,266 = Об/31,59; Е = 0,81 × Об/31,59 = 0,025641 × Об = Об/39. Фактически установлен коэффициент 1,25 вместо 1,266 (для USDJPYrfd). Несложный пересчёт обнаруживает отставание фактического порога от договорного на δ = 0,0003285 номинала (п. 3.1).
4.3. Вариант В — изменение кредитного плеча
При уровне стоп-аута 81 % и коэффициенте 1,25 точное соответствие договору достигается установкой плеча:
L_точи = 1,25 × 31,59 = 39,4875, т.е. плечо ≈ 1 : 39,49.
Фактически установлено плечо 1:40. Отклонение в 0,51 единицы плеча также не было устранено.
4.4. Вариант Г — фиксированная маржа, равная «Требуемому обеспечению»
Штатные возможности сервера MetaTrader 5 позволяют задать фиксированную маржу (поле «Начальная маржа» / «Поддерживающая маржа» в спецификации символа), при которой расчёт от текущей цены не применяется [Ист. 1, Ист. 2]:
Если в спецификации символа в поле "Начальная маржа" задано какое-либо значение, отличное от нуля, то вышеуказанные формулы расчета маржи перестают действовать... Для типов расчета Forex и Contracts Leverage дополнительно учитывается кредитное плечо: Объем в лотах * Начальная маржа / Кредитное плечо.
Установив фиксированную маржу на лот в размере Номинала/32 / Плечо (в валюте маржи) и обновляя её ежедневно в соответствии с публикуемым «Требуемым обеспечением», Форекс-дилер мог бы обеспечить: (а) точное равенство Маржа = Требуемое обеспечение, (б) стабильный (не зависящий от тиковой цены) размер зарезервированных средств, соответствующий п. 12.12 Рамочного договора — «сумма денежных средств, равная размеру Требуемого обеспечения, не включается в расчет свободных денежных средств». Именно такой режим — фиксированное значение, изменяемое ежедневно, — соответствует по смыслу понятию «Требуемое обеспечение», что отмечалось Истцом и в ходатайстве № 14 (справка к платформе: платформа допускает настройку режимов расчёта маржинальных требований, в том числе «Forex No Leverage» в сочетании с настройкой валюты маржинальных требований). Форекс-дилер указанную возможность не использовал, установив режим «Forex» с расчётом от текущей цены.
4.5. Выводы по части IV
Таблица 3. Возможные способы точной настройки и фактически установленные параметры
Параметр
Точное значение (по договору)
Фактически установлено
Отклонение
Уровень Stop Out
82,05 %
81 %
− 1,05 п.п.
Коэффициент маржи USDJPY
≈ 1,266
1,25
− 0,016
Кредитное плечо
≈ 1 : 39,49
1 : 40
+ 0,51
Режим маржи
фиксированная маржа / ежедневное обновление
Forex (от текущей цены)
принципиально
Все четыре способа являлись штатными и не требовали доработки программного обеспечения. Форекс-дилер, который, как установлено (п. 2.5.2), способен разрабатывать и эксплуатировать дополнительный программный модуль (подача заявок от имени Клиента), не мог не осознавать наличия данных возможностей. Выбранная же комбинация параметров (81 %; 1,25; 1:40; Forex) систематически смещает момент стоп-аута в сторону большего убытка Клиента, что не является ни случайным, ни вынужденным техническим ограничением платформы.
"
Вы так упоролись в эту тему глубоко - что обратной дороги нет - идите до Верховного... и не суда... главнокомандующего... )))
Кстати - написал - в личку - тоже посмотреть можете - сайт и название... сам думал обращаться к ним, когда решал вопросы свои по оплате труда (еще в процессе - заседание назначено на декабрь)
П.С. Обратной дороги нет и поражение не приемлемо- мочите их! Тварей!