ІТ-ризики при процедурі придбання акцій



Коли ви, сидячи вдома, в 3 години ночі раптом вирішуєте купити якусь цінну папір, починається міжнародний інцидент. Адже, якщо замислитися, фактично, ви віддаєте команду на те, щоб взяти шматок однієї країни і перенести його ближче до вас, в Росію. А це вимагає купи оформлень на міжнародному рівні.

Природно, все це добре автоматизовано вже дуже давно, але проблеми трапляються. Розглянемо конкретно ІТ-ризики у процесі.

Ділянка від вас до брокера

Раніше ця ділянка виглядав дуже просто. Ви набирали номер брокера і говорили йому: «Купуй яблука!». Він спускав завдання кричати на торговий поверх і таким чином купував вам акції компанії Apple (насправді немає, Apple тоді на біржі не було). Якщо замість вас йому дзвонив зловмисник, а брокер виконував його доручення – це безумовний його косяк, що випливає з відсутності авторизації користувача (вас). Відповідно, ризики ніс брокер (його компанія). Ще брокер міг вас невірно почути, неправильно зрозуміти або ще як-то накосорезить. Це був ризик спотворення інформації при передачі і ризик інтерфейсу. В даному випадку неодноразово порушувалися судові справи на тему «я сказав продавай, а не купуй». Був навіть історичний період, коли брокери реально боялися того, що клієнт при несподіваному стрибку ринку «піде назад» і почне судитися з приводу того, що він давав зовсім інші торгові накази.

Природно, в цьому процесі потрібна авторизація, ідентифікація і логгирование. Все це плавно доэволюционировало до сучасних систем. Перші електронні торги почалися в 1971 році, а в 90-х вже майже всі біржі переключилися на виключно електронні методи. З великих вузлів найдовше трималася токійська біржа: останні крики там прозвучали аж у 1999.

Сьогодні все це робиться, як правило, через додаток, який ви встановлюєте у себе на комп'ютері. Сам брокер (компанія, що має право і можливість займатися такими операціями для вас) не бере участь свідомо в процесі: ви говорите купувати, роботи купують, відразу оформляючи всі документи через брокера як через проксі. Важливо, що у брокера є необхідні дозволи та активи для здійснення таких операцій. Тобто спочатку ті ж акції купує сам брокер, як учасник біржового ринку, а потім передає їх вам.

Проблеми можуть бути в обміні клієнтської програми та торгової платформи. Базовий ризик зараження терміналу і компрометація або підміна транзакції. Як правило, поширений досить рідко.

Другий ризик – невірне сприйняття сигналу торговою платформою. Це коли ви вирішили купувати акції Google, а в результаті купили акції Уральського вагонобудівного заводу. І не дві штуки, а контрольний пакет.

Природно, подібні баги досить рідкісні. Найпопулярніша в Росії система торгів вылизывается як літак вже, напевно, років двадцять точно. І це рішення використовують в якості платформи майже всі гравці ринку. При виникненні проблеми, про це дізнаються майже миттєво і майже все, тому, тьху-тьху, за останні роки яскравих випадків не було. Для самої платформи кожна байка – репутаційний випадок, тому, напевно, мало хто підходить до процесу тестування так само ретельно, як вони. Можна сказати, що це люди, які не знають про фразу EULA «Не несемо відповідальності за втрату даних у результаті використання ЗА». Несуть, але не безпосередньо, а репутацією.

Найпопулярніша система називається QUIK і розробляється в Новосибірську. Базова функціональність — забезпечує оперативне отримання інформації та доступ до різних ринків і режимам торгів через єдиний термінал. Є відкладені заявки («Кишеню транзакцій») з пакетним виставленням в торговельну систему, є умовні заявки, що виставляються при настанні певної умови, імпорт транзакцій з інших джерел, плюс підтримується програмний введення заявок засобами вбудованих мов програмування і введення заявок з графіка. Поверх базових речей навішуються різні модулі сервера і користувальницькі програми на місцях. Саме користувальницькі додатки і створюють той різноманітний «зоопарк» торгового, який ви бачите у різних гравців ринку. Приклад — та ж торгова система Tradematic Trader FIX (конструктор торгових роботів), яка працює безпосередньо з QUIK-сервером.

Друга за поширеністю система рівня платформи – Transaq.

Природно, можливі ризики на рівні налагодження роботи роботів (особливо, якщо вони «доморощені») та на точках інтеграції різного ПЗ в цьому стеку. Також вкрай рідко зустрічаються проблеми з реалізацією протоколів, але за останні роки таких випадків я згадати не можу.

На самій біржі

Біржа – теж досить надійна система. У безпека роботи вкладаються величезні гроші, але падіння трапляються. Рідко. але трапляються, причому на кожній біржі вони свої.

На нашій Московській біржі система дозволяла проводити до 20 тисяч операцій в секунду. Функції торгівлі та клірингу (розрахунків за укладеними угодами) історично були прописані прямо в ядрі як мінімум з 2007 року. Рано чи пізно біржі приходять до виносу цих функцій в окремі модулі: наприклад, в Лондоні і Нью-Йорку на поточний момент ці підсистеми вже поділено. Це не рятує від збоїв (вони бувають і на NYSE, і на NASDAQ), але дозволяє зменшувати їх масштаб до розмірів інкапсульованого модуля.

В архітектурі з кодом торгів та клірингу в ядрі помилки клірингу могли призвести до зупинення торгів. Як показали нечисленні призупинення торгів за два роки, приблизно половина пов'язана з кодом, решта – телеком і залізо (збій балансувальника 28 червня, некоректна робота телеком-обладнання 12 серпня, збій в М1 і «мережевий шторм» 8 вересня).

21 вересня цього року після повного завершення тестування нової системи і двотижневої бойової експлуатації стався достатньої незвичайний збій біржі — деякі гравці побачили «перевернутий стакан», тобто помінялися місцями ціни покупки і продажу. Для того, щоб полагодити код, торги були зупинені на 2 години.

У 2016 році біржа планує запустити ще один дата-центр з новою архітектурою, що дозволить клонувати торгові ядра. У цьому випадку при збоях буде спостерігатися деградація або відключення певних інструментів (наприклад, тільки торгів з дорогоцінних металів), але не загальне падіння.

Треба відзначити, що раніше, в 2013 році, код біржі суттєво модифікувався (поверх ядер 2007 року), тому що додавався функціонал переходу на режим розрахунків Т + 2, створення центрального депозитарію, початок переходу на розрахунки з централізованим клірингом в сегменті РЕПО, запуск торгів фізичним золотом і ПФИ. При цьому збоїв було досить мало, що говорить про досить добре поставленому процесі. Напевно, досить весело відчувати себе розробником, чия помилка в коді може коштувати країні пару мільярдів рублів мінімум.

Чому про вкрай рідкісні двогодинні падіння пишуть в новинах і на що це впливає – у сьогоднішньому ж пості на Гиктаймс.

Третій тип ризику

Ще один ризик – це коли операція вже за фактом пройшла, а ви не отримуєте свої акції в депозитарій. Якщо операція пройшла акція повинна впасти до брокера і бути видно у вас. Відповідно, при баги може статися так, що ви купуєте долбанное ніщо (і потім треба вистежувати транзакції для виправлення) або що за фактом угоди пройшли, але ви бачите старе стан і не можете скинути ф'ючерси, наприклад.

Для того, щоб не пропустити такі моменти, класичний брокер показує клієнту постійні звіти (як правило, надсилає на пошту і дублює в особистому кабінеті), або ж встановлюється спеціальна система, яка порівнює суму всіх транзакцій з фактичним результатом, тобто, по суті, аудирує рахунку та звіряє залишки на них.

Як це лікується

Миттєві операції не лікуються ніяк. Саме тому дуже важливо мати «чистий» код продакшне.

Операції з відкладеним розрахунком (наприклад, наші ETF вважаються на Т+2, тобто протягом двох днів) цілком можна перерахувати після усунення збою. Власне, в секції «повільних» угод так і відбувається. Наприклад, у випадку падіння «перевернутої склянки» біржа виловила всі транзакції і скасувала їх до закінчення Т+2. Режим Т+2 можливий при тристоронній угоді – не моментальному обміні з ким-то, а при проведенні операції через національний кліринговий центр, який і «притримує» все до підтверджень і перевірок.

Для випадків третього типу ризику з неправильним залишком важливо, щоб система звіряння залишків по рахунках та аудіювання транзакцій від вас і до вас зловила помилку до закінчення періоду скасування в Т+2, щоб можна було встигнути розгорнути угоду.

Резюме

В минулому пості ви запитували, навіщо нам потрібно 5 дата-центрів для торгівлі ETF в Росії навіть при роботі в режимі Т+2, при перевірці двома незалежними організаціями (Лондон, Ірландія) і через європейський кліринг. Сподіваюся, тепер я докладно відповів на ваше запитання. Сам по собі інструмент ETF прибрав операційні ризики (зав'язані на людський фактор). Своєю інфраструктурою і З ми постаралися мінімізувати IT-ризики. Залишилися тільки ринкові (зростання чи падіння ринку).

посилання:



Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.