Pull to refresh

Comments 25

Звучит клёво, а как будете работать с другими участниками банковской сферы, например, Сбербанком? Или вы предлагаете им потратить деньги на адаптацию к вашему видению? Есть ли у вас контакты с Банком России, что они думают на этот счёт?

Начали хорошо, описали часть проблемы, но потом всё скатилось к унылой рекламе "приходи в наш стартап".

Свифт это как морская торговля. Дело не в технологиях, а политике, кто этой корове пишет правила и конечном итоге доит.

Ничего нового. SWIFT не пинал только ленивый. И медленный, и страшный (в последнем не трудно убедиться, почитав толстенные талмуды со спецификациями сообщений). И древний. Но он работает. Уже полвека. Не быстро, но надежно. На его использование "заточено" просто чудовищное количество софта. Несколько раз предлагались его замены, разрабатывались международные стандарты (например, ISO-20022). Чтобы его заменить, мало хотеть. Надо предложить такую замену, которая позволила бы с минимальными затратами отказаться от SWIFT-а, не теряя надежности (речь ведь идет об активах - и не только, кстати о деньгах - на немеряные триллионы). Нужно внести изменения в законодательство. Переписать кучу софта, выстроить инфраструктуру зачетов и клирингов, обеспечить безопасность.

Пытайтесь, конечно, но помните, что финансы весьма консервативная сфера, любит тишину, предсказуемость, доверие участников.

И, к слову, внутри страны банки обычно SWIFT не используют и платежи идут весьма и весьма быстро. С использованием почему-то критикуемых вами коррсчетов. И это работает. Без бантиков, погремушек, скромненько так, но работает ) Четко, предсказуемо, быстро. Может быть, именно ваш банк позволяет себе подзадерживать платежи из-за чего у вас такое предубеждение? Но 20 минут на перевод из Москвы во Владивосток - реальность. Да, это стоит чуточку дороже, но если кому-то очень надо, то пожалуйста. А так списание из банка А и зачисление в банк Б происходит в течение пары-тройки часов.

Абсолютно согласен с надежностью - SWIFT свои задачи решал полвека. Но сейчас мы уперлись в потолок. Вы упомянули ISO-20022. Это ключевой момент. В Qazna мы реализовали поддержку ISO-20022 "из коробки" (в бинарном формате Protobuf для скорости). Мы не предлагаем сжечь мосты. Мы предлагаем движок, который понимает старый мир (XML), но внутри работает как современная Real-time система. Это эволюция, а не революция.

А теперь напиши рецепт яблочного пирога

20 лет назад, смс-ка из Грузии с "перевод пришёл" прилетала раньше, чем распечатывался чек в банке.

Золотая Корона.

А вот СберБанк проводил платёж в своё грузинское представительство 7 (вроде) рабочих дней.

Нужно внести изменения в законодательство.

Это ключевое. И дело не в самом SWiFT как таковом (если надо будет, курьер чемодан с платежками повезет, или шифрованным пакетом через обычную электронную почту перешлют), а в вопросах сертификации протоколов (не сетевых) межбанковского обмена (включающих помимо прочего проверки на "чистоту перевода").

И, к слову, внутри страны банки обычно SWIFT не используют и платежи идут весьма и весьма быстро. С использованием почему-то критикуемых вами коррсчетов. И это работает. Без бантиков, погремушек, скромненько так, но работает ) Четко, предсказуемо, быстро.

Так собственно информация о транзакции там может даже мгновенно пролетать. Все задержки обусловлены дополнительными проверками и могут достигать десяти рабочих (не календарных!) дней (или больше? просто самый большой срок, с которым я сталкивался, был именно 10 дней).

Ваши интерфейсы - дрянь. Они перегуржены мусором и заляпаны рекламой. Ваш AI не может найти переводы за последние полгода, а видит только июньские. Ваша анимация динамически мигает в течение долгих секунд подгружая 10 чисел (примерно 80 байт). Тоже мне, лучшие инженера́.
А свифт и кор.счета... Ну тормозят. Но слава богу, хоть туда ваши ручонки еще недотянулись.

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

Если для получения этих 10 чисел нужно пройтись по 100 индексам на миллион строк с фильтрами, то спасибо за анимацию, если она хотя бы прогресс показывает )

Кажется, произошло недопонимание. Qazna - это не мобильное приложение банка и не финтех-стартап, который продает кредиты. У нас нет сториз, рекламы или даже пользователей-физлиц.

Мы разрабатываем Open Source ядро (Ledger) на Rust для инженеров. Это "подкапотная" технология. Те "тормоза и мусор", о которых вы пишете — это как раз следствие того, что современные красивые интерфейсы натянуты на дряхлый бэкенд 70-х годов. Мы меняем именно этот фундамент.

Зайдите в наш репозиторий ссылка в профиле или документацию. Там нет рекламы, только код, gRPC и хардкорная арифметика.

Рекомендую разобраться сначала с юридической и бизнесовой стороной международных переводов (а не только с политической), прежде чем предлагать что-то свое. А то будет как с криптой, которая уже 10 лет как должна была убить обычные деньги.

Sepa instant давно уже мгновенно переводит деньги между странами 🤷

Reconciliation конечно идёт отдельно, но учитывая механизм авторизации списания - ошибки маловероятны

Нам нужен новый стандарт финансового интернета. Финансовый Linux.

Иронично, особенно учитывая, что дистрибутивов 700 шт.

Верно подмечено про дистрибутивы :) Но у всех 700 есть одно общее Ядро (Kernel).

Мы в Qazna претендуем именно на роль Ядра: базовый слой учета (двойная запись, строгая консистентность, ISO 20022), который работает одинаково надежно везде. А какой "дистрибутив" (продуктовую логику, интерфейсы, правила комплаенса) построить сверху - это уже выбор конкретного банка или страны. Главное, чтобы "ядро" не паниковало при нагрузках.

Замах интересный, но он со стороны техники. А что есть у вас с организационной стороны? Если за вами нет влиятельных сил для внедрения хотя бы в ограниченном объёме (в рамках группы банков, скажем), то просто техническая инициатива, скорее всего, умрёт. Даже если техническая часть идеальна. Так устроен мир.

Но даже техническая часть неидеальна. Например, много банков сидят на Java, они захотят кастомизировать что-то под себя, от вас решение одно - некий xml для обмена. То есть нет логики, нет расширяемости для тех, кому недостаточно только передать вам xml. Выбор вами возможно и перспективных языков, но не принятых массово в тех же финансах, говорит о будущих трудностях с адаптацией. Ну и go как язык, скажем так, вообще удивляет.

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

Скажем так - за свои деньги такое делать не стоит. А вот за чужие - ну почему бы и нет? Сразу все вопросы про сложность снимаются. Точнее, перекладываются на владельца "чужих" денег.

Вы затронули самый важный риск - организационный. Абсолютно согласен: техническое совершенство не гарантирует внедрения. Linux победил Unix не только кодом, но и лицензией/экосистемой.

  1. Про "Влиятельные силы": Именно поэтому Qazna - это Open Source протокол, а не проприетарный стартап. Мы создаем стандарт, к которому могут присоединиться игроки, уставшие от vendor-lock. Мы не продаем "коробку", мы даем "рельсы".

  2. Про Java и кастомизацию: Тут концептуальная разница. Банки привыкли покупать АБС (автоматизированную банковскую систему) и переписывать ее код под себя годами. Мы предлагаем подход "База Данных". Вы же не переписываете код PostgreSQL на Java, чтобы хранить там данные? Вы просто общаетесь с ней по протоколу. Qazna — это такое же "финансовое ядро". Оно на Rust/Go для скорости и надежности, но общаться с ним можно хоть из Java, хоть из 1С через gRPC API. А кастомизация логики (лимиты, комиссии) вынесена в слой WASM-плагинов - пишите их на чем хотите.

  3. Про миллиарды: Бюджеты нужны, чтобы поддерживать старое. Чтобы создать новое, нужна инженерная смелость. Биткоин или Linux в начале стоили 0 миллиардов.

Вы согласились с важностью организационных моментов. Танцуя от этой печки мы приходим к необходимости эту важность как-то оценить. Сколько в мире конкурирующих проектов, аналогичных Linux? Ну штук 5, причём за каждым стоит толстая контора, или сразу ассоциация бегемотов. Правда внутри каждого аналога могут быть ветви с десятком-другим заметных альтернатив, но в вашем случае речь идёт лишь о корневой технологии, то есть про ветки пока вообще говорить нет смысла.

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

На фоне указанных выше весьма сложных входных условий ваши ответы в основном упирают на технические аспекты. То есть про конкуренцию с альтернативами можно понять одно - она предлагается только в технической плоскости. Но вы же согласились с важностью организационных моментов. И тем не менее перечисляете технические решения. Чего-то всё же не хватает, нет?

Но, с другой стороны, масса опенсорсных проектов в том или ином виде используются в бизнесе. Правда роль зачастую сильно скромнее "ядра". На уровне ядра, упрощая, имеем десяток-другой технологий (ОС, БД, ЯП, IDE, etc). В каждой ядерной нише пусть по 5-10 альтернатив. Итого до 200 штук олимпийцев. На фоне миллионов опенсорсных проектов. Так себе соотношение в плане статистики успеха.

Вот поэтому вам нужно одно - бегемот, а лучше группа мастодонтов, дабы проталкивали в борьбе за существование. Ну и об этом я ранее пытался сообщить.

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

В общем - рад за ваше техническое начинание, но печален за ваше рыночное будущее.

Вы зрите прямо в корень. Это самый болезненный и честный комментарий, спасибо.

Про «рынок занимают бегемоты» - абсолютная правда. Именно поэтому мы не строим «еще один стартап», который пытается продать лицензии банкам в лоб. Это самоубийство.

Наша стратегия завоевания Олимпа выглядит иначе, и она полностью отвечает на ваш вопрос про «подпирающую силу»:

  1. Почему сейчас? Бегемоты (ЦБ разных стран, крупные финтех-хабы) сами загнаны в тупик. SWIFT становится политическим оружием. Visa/Mastercard - дорогим удовольствием. Им нужна альтернатива, но строить её с нуля в одиночку - дорого и страшно.

  2. Кто наш Бегемот? Мы не идем в одиночку. Мы подаем заявку в Linux Foundation. Наша цель - сделать Qazna проектом уровня Hyperledger. Чтобы за нами стоял не «казахский стартап», а нейтральный, уважаемый глобальный фонд.

  3. Альянс Недовольных. Мы делаем ставку на «Digital Sovereignty». Это то, что сейчас нужно странам Ближнего Востока, Азии, Латинской Америки. Им нужен не Oracle (SaaS из коробки, который могут отключить), а Linux (код, который принадлежит им).

Мы строим Linux, а не Windows. Линус Торвальдс тоже не имел маркетингового бюджета. Он просто дал бесплатную альтернативу дорогим UNIX-системам ровно в тот момент, когда Интернет потребовал дешевых серверов. Мы верим, что сейчас Мир (фрагментированный и недоверчивый) требует дешевых и суверенных финансовых серверов.

Если мы ошибемся и это никому не нужно - что ж, останется хороший Open Source код на GitHub. Но если мы правы - это изменит игру.

от вас решение одно - некий xml для обмена

Если они используют стандартные xsd из ISO-20022, то на входе и выходе уже не некий xml, а вполне себе международный формат обмена финсообщениями. Например ЦБ РФ их опубликовал. Если не ошибаюсь, с 2018 этот формат продвигают. Дальше пилотных проектов дело, вроде, еще не дошло, но в узких кругах ходят упорные слухи, что ЦБ таки наклонит банки на них переходить. Посмотрим... В отличие от расхристанного SWIFT-а, эти xml хотя бы парсятся по людски, не через известный проход )

Спасибо за уточнение про ISO-20022. Всё верно - регуляторы (не только ЦБ РФ, но и в ЕС, и в Азии) неизбежно переводят всех на этот стандарт. Проблема текущих реализаций в том, что эти XML часто "парсятся" как попало или маппятся на старые плоские структуры 90-х. Мы же сделали нативную поддержку: ядро "думает" структурами ISO.

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

Или qazna.org не ваше? Если не ваше, нафига везде именно оно написано?

Рукалицо.

Спасибо за комментарий! Это фундаментальный вопрос позиционирования.

Разница - в Модели Доверия. Ripple (XRPL) и Stellar отлично подходят для расчетов между недоверяющими друг другу сторонами в открытой сети (Inter-bank settlement).

Qazna создана для ситуаций, когда центральный администратор ЕСТЬ (банк, необанк, платежный шлюз), и он несет юридическую ответственность за реестр (Intra-bank ledger).

Отказ от публичного Консенсуса дает нам другие преимущества:

  1. Производительность: 100k+ TPS на одном узле (против <1-4k у большинства публичных чейнов), так как нет сетевых задержек на синхронизацию тысяч узлов.

  2. Приватность: Данные живут внутри вашего периметра, а не в публичном графе транзакций.

  3. Финальность: Мгновенная и детерминированная.

Qazna - это суверенная инфраструктура («свой собственный процессинг»), а не участие в чужой сети.

Sign up to leave a comment.

Articles