IBM робить ставку на те, що банки не довірять хмарі токенізовані депозити

Кожен керівник платформи у регульованому банку, який дивиться на дорожню карту токенізованих депозитів до 2026 року, тепер має провести розмову з постачальником до закриття четвертого кварталу. IBM щойно повідомила ринку, що інституційний стек цифрових активів не обов'язково має розміщуватись у гіперскейлері, і вибрала момент для оголошення так, щоб він збігся з пілотом Swift, до якого вже залучені Citi, HSBC, UBS, BNY та Wells Fargo. Це не просто запуск продукту — це позиційний хід проти кожного крипто-орієнтованого постачальника кастодіальних послуг, який останні три роки просував хмарну архітектуру банкам першого рівня.

Що сталося

IBM оголосила про два оновлення своєї платформи Digital Asset Haven, орієнтованих на регульовані фінансові установи, і реакція ринку була стримана: акції впали на 0,4% у доторговий час у четвер на тлі загальної слабкості, а роздрібні настрої на Stocktwits охолонули з бичачих до нейтральних за попередній день, як повідомив TradingView. Реакція акцій не відображає стратегічної ваги того, що було випущено.

Перше оновлення підключає клієнтів Digital Asset Haven до блокчейн-спільного реєстру Swift — того, що Swift представила на Sibos 2025 і створила на основі прототипу від Consensys. Swift охоплює понад 12 500 фінансових установ у більш ніж 200 ринках. Реєстр розроблявся разом із понад 40 банками, і шлях від початкової концепції до живого використання зайняв дев'ять місяців — темп, який кожен, хто доставляв рішення всередині регульованого консорціуму, визнає незвично агресивним. Сімнадцять установ-ранніх adopter'ів, зокрема Citi, HSBC, UBS, BNY та Wells Fargo, зараз пілотують транзакції токенізованих депозитів на цьому реєстрі.

Точка входу IBM у цей пілот — новий продукт під назвою ISO 20022 Messaging Adapter, який дозволяє банкам давати інструкції для транзакцій у реєстрі, використовуючи стандартні формати платіжних повідомлень, які вони вже запускають через свої наявні рейки. У формулюванні IBM підключення до Swift дає банкам змогу брати участь через стандартні платіжні повідомлення ISO 20022 без перебудови інтеграційного рівня.

Друге оновлення змінює математику вибору постачальника. Digital Asset Haven тепер можна розгорнути повністю на власному обладнанні клієнта IBM Z або LinuxONE без необхідності підключення до публічної хмари. Програмне забезпечення та управління криптографічними ключами залишаються всередині середовища банку, підтримуються апаратними модулями безпеки Crypto Express та офіційними процесами key-ceremony, розробленими для створення документації для регуляторів. IBM цитує дослідження J.P. Morgan Payments, згідно з яким 93% фінансових установ модернізують свою платіжну інфраструктуру, щоб окреслити контекст попиту.

Технічна анатомія

Тут важливі два архітектурні рішення, і вони вказують в одному напрямку: тримати криптографічну поверхню атаки всередині існуючої площини управління банку.

Почнемо з інтеграції Swift. Блокчейн-спільний реєстр, що знаходиться за адаптером повідомлень ISO 20022, є архітектурно нудним навмисно. Банки вже мають основні банківські системи, перевірку санкцій, механізми боротьби з шахрайством і конвеєри звірки, підключені до потоків ISO 20022. Якщо токенізовані депозити надходять як ще один тип повідомлення через той самий шаблон адаптера, перевірка операційного ризику стає інкрементальною зміною, а не розробкою з нуля. Це різниця між шестимісячною інтеграцією та дворічною. Consensys створив прототип, тому базовий реєстр майже напевно значною мірою запозичує моделі облікових записів і стану в стилі Ethereum, хоча Swift тримає специфіку виробничого стека при собі. Кожен, хто розробляє інструменти для корпоративних реєстрів, має читати поточний стан специфікацій Ethereum, щоб розуміти, які шаблони отримують інституційну підтримку.

Тепер про on-prem сторону. Запуск Digital Asset Haven на IBM Z або LinuxONE з HSM Crypto Express і без залежності від публічної хмари одночасно робить три речі. Він тримає криптографічний корінь довіри фізично всередині центру обробки даних банку, що і хоче побачити юридичний директор, коли регулятор запитує, хто може отримати доступ до ключів. Він виводить гіперскейлера за межі аудиторської зони, що прибирає цілий клас питань щодо ризиків третіх сторін із циклу перевірки. І він дозволяє банку проводити офіційні процеси key-ceremony — ті самі хореографовані багатосторонні процедури, що використовуються для центрів сертифікації та майстер-ключів платіжних карт, — з документацією, упакованою для наглядачів.

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

Хто програє

Очевидними невдахами є хмарно-орієнтовані постачальники інституційного кастодіального зберігання. Fireblocks, BitGo, Anchorage та кожен стартап, що пропонує «корпоративний» кастодій поверх AWS або GCP, тепер мають відповідати на запитання, яке їм не потрібно було ставити шість місяців тому: чому ключовий матеріал і реєстри токенізованих депозитів взагалі повинні торкатися гіперскейлера, якщо IBM постачить ту саму функціональність всередині власного центру обробки даних банку з доданою процедурою key-ceremony, готовою для регулятора. Це жорстке заперечення, коли покупець — банк першого рівня з існуючими контрактами IBM Z.

Самі гіперскейлери отримують більш тонкий удар. AWS, Azure та Google Cloud позиціонували конфіденційні обчислення та анклави в стилі Nitro як відповідь на банківські крипто-навантаження. Крок IBM переосмислює цю пропозицію як недостатню для найбільш цінного сценарію використання — токенізованих депозитів, що переміщуються через Swift. Очікуйте швидкої відповіді принаймні від одного гіперскейлера протягом двох кварталів, мабуть, упакованої як спеціалізований регіон фінансових послуг із договірними гарантіями суверенітету ключів.

Фінансовий директор будь-якого кастодіального або токенізаційного стартапу серії B, що продає послуги банкам, цього тижня має запитати свого керівника відділу продажів, чи передбачає воронка угод хмарне розгортання як щось само собою зрозуміле, бо це припущення щойно стало слабшим. Якщо половина угод у воронці потребує on-prem або гібридного розгортання для закриття, план щодо інженерних кадрів на 2026 рік є невірним, а математика темпів витрат потребує перегляду.

Команди інфраструктури публічних блокчейнів також відчувають це опосередковано. Реєстр Swift, побудований разом із 40+ банками і тепер пілотований 17-ма з них, включно з найбільшими іменами в кореспондентському банківництві, є конкуруючою розрахунковою тканиною для токенізованих грошей. Йому не потрібно перемагати з точки зору децентралізації — він має перемагати за регуляторною ясністю та сумісністю з існуючими рейками. За цими критеріями він починає з перевагою.

Посібник для крипто та DeFi

Для команд, що будують навколо інституційного крипто, наступні 90 днів мають чіткий вигляд.

Якщо ви продаєте банкам програмне забезпечення для кастодіального зберігання або токенізації, цього кварталу випустіть варіант on-prem розгортання або bring-your-own-HSM. Не слайд дорожньої карти, а реальну еталонну архітектуру з посібником з проведення key-ceremony. Очікування покупця щойно змінилися. Якщо ваш продукт не може працювати без вашого хмарного орендаря в межах довіри, ви конкуруєте за ціною проти історії, яку не можете повторити.

Якщо ви керуєте DeFi-протоколом, орієнтованим на інституційну ліквідність, припускайте, що токенізовані депозити спочатку розраховуватимуться на дозволених рейках, а потім будуть переходити до публічних блокчейнів. Проектуйте свою інтеграційну поверхню так, щоб токенізований депозит на стороні банку міг входити до вашого протоколу через обгорнуте представлення без необхідності для банку торкатися гаманця публічного блокчейну. Шаблон повідомлень ISO 20022 є підказкою: установи хочуть давати інструкції, а не підписувати.

Якщо ви консультуєте щодо регуляторної позиції, перегляньте нормативну базу SEC стосовно сценарію, де розрахунки за токенізованими депозитами стануть стандартною банківською інфраструктурою протягом 18 місяців. Визначення кастодія, трансфер-агента та брокера-дилера всі проходять стрес-тест у світі, де реєстр знаходиться всередині банку, а Swift маршрутизує повідомлення.

Якщо ви наймаєте персонал, ринок інженерів, які розуміють і процедури key-ceremony для HSM, і семантику реєстрів, суміжних із EVM, ось-ось стане дуже напруженим. Ці навички є, можливо, у кількох сотнях людей у всьому світі. Утримайте тих, що у вас є, за допомогою пакетів утримання, перш ніж банки почнуть виписувати чеки.

Юридичний директор будь-якого постачальника кастодіальних або токенізаційних послуг цього тижня має запитати свого керівника платформи, чи може поточна архітектура пережити RFP від клієнта, що вимагає відсутності хмари, контрольованої постачальником, у шляху управління ключами. Якщо відповідь — ні, це розмова на рівні ради директорів, а не інженерний квиток.

Ключові висновки

• IBM випустила конектор до реєстру Swift через ISO 20022 Messaging Adapter і повністю on-prem розгортання Digital Asset Haven на IBM Z або LinuxONE, орієнтовані на пілот Swift із 17 банків, включаючи Citi, HSBC, UBS, BNY та Wells Fargo.
• On-prem варіант із HSM Crypto Express та офіційними процедурами key-ceremony переосмислює банківський крипто-кастодій як розширення існуючого управління мейнфреймом, а не як нове хмарне навантаження.
• Хмарно-орієнтовані постачальники інституційного кастодіального зберігання тепер мають пояснити, навіщо ключовий матеріал взагалі торкається гіперскейлера, — що є суттєво складнішою розмовою про продаж порівняно з минулим кварталом.
• Перехід Swift від концепції до живого використання за дев'ять місяців разом із 40+ банками-співрозробниками сигналізує, що дозволені рейки токенізованих депозитів випереджають інституційне прийняття публічних блокчейнів за регуляторними та інтеграційними параметрами.
• Команди, що оцінюють інституційну крипто-інфраструктуру, тепер мають запитувати, чи може їхній постачальник надати on-prem еталонну архітектуру з посібником з проведення key-ceremony, готовим для регулятора, цього кварталу, а не наступного року.