Три цвета счетов: как на самом деле переходит право на акции

Вы купили акции. Где они лежат?

Интуитивный ответ — «у брокера» или «на счёте» — верен ровно настолько, насколько верно «деньги лежат в банкомате». На самом деле между вами и записью в реестре акционерного общества выстроена матрёшка из посредников, и каждый следующий не видит, что происходит у соседа. Пока всё идёт штатно, эта конструкция незаметна. Она становится очень заметной в тот день, когда бумаги уходят и не приходят.

Вторую лекцию курса по рынку ценных бумаг в программе MBA CIO читал практик с брокерской стороны, и почти вся она — про одну эту механику: как право собственности физически переезжает с одного счёта на другой. Разберём её целиком, а заодно посмотрим, где сегодня в такой работе помогают современные модели.

Оговорка та же, что и в первой части: лекция читалась в 2015 году, конкретные нормы и практики с тех пор менялись. Текст — про устройство и логику, а не про действующие требования.

Три цвета счетов

На доске лектор рисовал схему цветными маркерами, и цвета в ней оказались удобнее любых терминов.

Красные счета — те, что открыты в самом реестре. Реестродержатель ведёт их для акционерного общества и знает только их. Красный счёт бывает двух видов: счёт владельца — там записаны бумаги конкретного человека или компании, — и счёт номинального держателя, тоже красный, но особенный.

Особенность в том, что владелец счёта номинального держателя не является владельцем бумаг. Он просто учитывает на своём счёте чужие бумаги. Для реестра это один большой мешок с записью «здесь лежит столько-то акций, и они не мои».

Синие счета живут внутри номинального держателя — например, внутри НРД, расчётного депозитария Московской биржи. Это счета его клиентов: брокеров, других депозитариев, крупных владельцев.

Зелёные счета — следующий уровень: счета клиентов внутри того брокера, который сам держит синий счёт в НРД. Ваш брокерский счёт — как раз зелёный.

Ключевое правило звучит так: каждый уровень видит только свой цвет. Реестр знает красные счета и не имеет представления о синих. НРД оперирует синими и не знает ни красных, ни зелёных. Брокер знает зелёные. Это не недоработка, а осознанное разделение ответственности — к нему вернёмся ниже.

flowchart TD
    R["Реестр акционерного общества<br/>ведёт реестродержатель"]
    R --- R1["Красный счёт владельца<br/>бумаги конкретного лица"]
    R --- R2["Красный счёт<br/>номинального держателя"]
    R2 --> D["НРД<br/>расчётный депозитарий"]
    D --- D1["Синий счёт брокера"]
    D --- D2["Синий счёт<br/>другого депозитария"]
    D1 --> B["Брокер"]
    B --- B1["Зелёный счёт клиента"]
    B --- B2["Зелёный счёт клиента"]

Что пишут в передаточном распоряжении

Право собственности переходит по передаточному распоряжению — поручению реестродержателю переписать бумаги с одного счёта на другой. В нём указывают четыре вещи.

Поле	Зачем оно
Вид бумаги	Один реестродержатель ведёт реестры многих обществ, и на одном счёте лежат разные бумаги
Количество	Сколько акций переводим
Цена	Появилась, когда реестры начали брать комиссию в зависимости от объёма сделки
Счёт получателя	Куда переводим

И вот здесь первое ограничение, из которого растёт всё остальное: в передаточном распоряжении можно указать только красный счёт. Синий или зелёный указать нельзя — реестр о них не знает и не обязан знать.

Если получатель держит бумаги прямо в реестре, на этом всё и заканчивается. Одно поручение, одна запись, право перешло.

Дополнительная инструкция: договор вместо счёта

А теперь представьте, что бумаги нужно доставить вашему брокеру. Формально они уедут на красный счёт номинального держателя — тот самый большой мешок. НРД увидит поступление и задаст резонный вопрос: и на какой из моих синих счетов это положить?

Ответ приходит вместе с поручением, в поле, которое называется по-разному — «комментарии», «дополнительные инструкции». Там пишут не номер счёта, а номер договора.

Логика простая: любой счёт внутри депозитария открыт на основании договора — депозитарного, междепозитарного. Договор и есть надёжный идентификатор счёта. НРД читает инструкцию, находит счёт, открытый по этому договору, и зачисляет бумаги туда. Практика при этом двойная: рядом с договором обычно указывают ещё и номер счёта, потому что нумерация договоров у каждого депозитария своя и теоретически может совпасть.

Инструкции при этом вкладываются друг в друга. В поручении их пишут сразу несколько: одну для НРД — «положи на счёт по договору такому-то», вторую для брокера — «а ты дальше положи на счёт по договору такому-то». Каждый участник цепочки читает свою строку, исполняет и передаёт остаток дальше.

Где здесь помогают современные модели. Заполнение таких реквизитов — ровно та работа, которую человек делает хуже машины: восемь полей, из них половина скопирована из письма клиента. Модель, которой скормили переписку и шаблон поручения, собирает черновик и — важнее — проверяет его на связность: есть ли договор для каждого уровня цепочки, соответствует ли номер счёта тому договору, не пропущен ли уровень. Это не автоматизация принятия решений, это вычитка перед отправкой. И именно её обычно не делают.

Одно неверное поле — и бумаги зависли

Теперь про цену ошибки. Допустим, в дополнительной инструкции указан договор, которого не существует.

Бумаги придут на большой красный счёт номинального держателя, НРД не найдёт, куда их положить, и отправит на отдельный технический счёт — счёт невыясненных поступлений. Там они и останутся.

Сравните с деньгами. Платёж, ушедший не по тем реквизитам, через какое-то время вернётся отправителю сам — вы можете вообще ничего не делать. С бумагами так не работает: сами они не вернутся. Исправить дополнительную инструкцию может только тот, кто её подавал, — продавец.

А теперь сложите картину целиком. Продавец подал поручение, показал вам выписку со своего счёта, вы отдали деньги. Бумаги зависли где-то посередине. Вам нужно, чтобы продавец пошёл и исправил инструкцию, — а он уже получил деньги и в вас больше не заинтересован.

На вопрос из зала «как покупатель может проконтролировать отсутствие ошибки у продавца» лектор ответил честно: никак. Покупатель видит только отчёт продавца об исполнении его же поручения. Единственная реальная защита — аккуратность на этапе заполнения и понимание, что правило «сначала бумаги, потом деньги» — это не закон, а обычай делового оборота. Никакого обязательного «Т+2» нет: стороны вольны договориться о любом порядке, просто так сложилось.

Обратный путь: три поручения вместо одного

Обратная дорога — от брокера в реестр — устроена зеркально, но проще для клиента.

Вы подаёте передаточное распоряжение своему брокеру и указываете обычные реквизиты: номер счёта в таком-то реестре. Никаких дополнительных инструкций: вам не нужно знать, как устроена цепочка выше, и эта информация была бы там лишней.

Дальше поручение подаёт брокер — уже своему депозитарию, НРД, потому что для него это внешний вывод. Затем поручение подаёт НРД — внутри реестра, со своего большого красного счёта на ваш маленький красный. Итого три передаточных распоряжения, из которых вы заполняете одно.

flowchart LR
    A["Клиент → брокеру:<br/>поручение №1"] --> B["Брокер → НРД:<br/>поручение №2"]
    B --> C["НРД → в реестре:<br/>поручение №3"]
    C --> D["Запись на красном<br/>счёте владельца"]

Зачем вообще эта матрёшка

Резонный вопрос: не проще ли всем держать бумаги прямо в реестрах?

Считаем. Допустим, вы хотите владеть бумагами полутора сотен эмитентов, реестры которых ведут разные регистраторы. Без депозитарной схемы вам пришлось бы открыть счёт в каждом из них, с каждым заключить договор и с каждым дальше поддерживать отношения. С депозитарной схемой вы открываете один счёт у одного брокера.

Отсюда же следует ответ на упрёк, который прозвучал на лекции: получается, реестродержатель перекладывает свою головную боль на владельца счёта, заставляя того выписывать всю цепочку реквизитов?

Нет. Реестродержатель физически не может знать, что происходит внутри номинального держателя, — и не должен. Ваши отношения с депозитарием касаются вас и депозитария; постороннему участнику незачем видеть их структуру. Он получит эти сведения, если возникнет предусмотренная законом ситуация, и только тогда. Это не перекладывание работы, а границы ответственности, проведённые ровно там, где проходят границы отношений.

Спор о едином реестре

Логичное продолжение — а не свести ли всё в один общий реестр? Технически в электронном виде это реализуемо.

Аргументы против прозвучали такие. Первый — историческая инерция: система росла десятилетиями, реестры вели десятки регистраторов, с каждым заключены договоры. Переделать её целиком по масштабу сопоставимо с пересмотром приватизации.

Второй аргумент интереснее и универсальнее. Единый реестр — это единая точка отказа. Пока реестров много, проблема у одного из них — сбой, утечка, недобросовестность — остаётся проблемой одного кусочка. Централизуйте всё, и любой сбой становится сбоем всей системы.

Третий: выигрыша всё равно не будет. Издержки конечного владельца при нынешней схеме и так минимальны, единый депозитарий их не уменьшит.

При этом де-факто централизация уже произошла — просто не там, где её искали. Всё, что реально торгуется, приходит на Московскую биржу; значит, приходит и в НРД, который открывает счёт номинального держателя в каждом нужном реестре. Так что единый источник информации существует. Разница в том, что информация сведена, а ответственность осталась распределённой между регистраторами. Это, пожалуй, лучший из возможных компромиссов.

Где здесь помогают современные модели. Когда бумаги всё-таки зависли, начинается археология: поднять поручение, выписки, переписку, найти, на каком уровне цепочки инструкция разошлась с реальностью. Разбор разнородных документов и сведение их в одну хронологию — сильная сторона современных моделей, и здесь она экономит не проценты, а дни. Восстановление истории по документам вместо ручного перебора — та же логика, что и в аудите процессов: сначала увидеть, как всё двигалось на самом деле, потом делать выводы.

Байки эпохи скупки

Лектор вспомнил и практику девяностых-двухтысячных, когда по стране ездили скупщики акций, полученных при приватизации.

Схема мошенничества была элементарной. Продавец брал у реестродержателя пять выписок со счёта на одну и ту же дату, продавал одни и те же бумаги пятерым покупателям, собирал деньги со всех — и первым подавал передаточное распоряжение себе. Работала она ровно потому, что покупатель верил бумажке вместо записи, а перевод происходил не одновременно с оплатой.

Отдельная история — доверенности. Отдавать деньги против доверенности неправильно; правильно идти вместе с продавцом в реестр и делать операцию. Сегодня таких сделок почти не осталось: все, кто хотел продать приватизационные бумаги, продали их давно.

Что из этого следует за пределами биржи

Механика реестров кажется узкоспециальной, но принцип в ней универсальный: инструкцию исполняет тот, кто не может её проверить. НРД не знает ваших договорённостей с брокером, брокер не знает реестра, реестр не знает никого. Каждый добросовестно делает ровно то, что написано в его строке.

Ровно так же устроены счета на оплату с неверными реквизитами, задачи подрядчику, поля в CRM и любая передача работы через границу отдела. Ошибка не отлавливается там, где сделана, — она отлавливается там, где стало поздно. И тот же вывод, что и в процессном управлении: проблема живёт не внутри звеньев, а на стыках между ними.

Отсюда практическое правило: если в вашем процессе есть поле, ошибку в котором может исправить только тот, кто уже получил своё и ушёл, — это поле надо проверять до отправки, а не после. Проверка перед отправкой стоит минуты. Проверка после — переговоры с человеком, которому вы больше не нужны.

Вывод

Право собственности на акцию — это запись, а не бумага, и переезжает она по цепочке посредников, каждый из которых видит только свой уровень. Передаточное распоряжение указывает счёт в реестре; дополнительные инструкции проводят бумаги дальше, по номерам договоров; ошибка в одном поле оставляет бумаги на счёте невыясненных, откуда их вытащит только отправитель.

Три вещи стоит унести с собой. Каждый участник видит только свой цвет — и это правильная конструкция, а не недоработка. Деньги возвращаются сами, бумаги — нет, поэтому цена ошибки в реквизитах несимметрична. И централизация информации не равна централизации ответственности: НРД собрал у себя данные, но реестры продолжают отвечать каждый за свой участок, и именно это делает систему устойчивой.

Следующий шаг: найдите в своём бизнесе одно поле, ошибку в котором исправляет не тот, кто её сделал. Реквизиты в договоре, артикул в заявке поставщику, адрес в накладной. Поставьте на него проверку перед отправкой — хоть чек-лист, хоть сверку моделью. Это самая дешёвая страховка из всех, что вам доступны.