Бізнес-аналітик в епоху Bank 4.0

💡 Усі статті, обговорення, новини для аналітиків — в одному місці. Приєднуйтесь до Analysts спільноти!

Ця стаття є результатом не тільки роботи в NASDAQ, але й осмислення результатів співбесід. Але під іншим кутом зору, а саме з погляду концепції «Bank 4.0». Може ці роздуми та аналіз стануть в пригоді колегам, або тим, хто планує переходити у сферу фінтеху.

Як відомо, Bank 4.0 — це концепція майбутнього банкінгу, яку популяризував Бретт Кінґ у книзі «Bank 4.0: Banking Everywhere, Never at a Bank». Головна ідея проста: банк перестає бути місцем, просто банк стає дією, вбудованою в будь-який цифровий простір

Шлях від Bank 1.0 до 4.0

Джерело ( на основі https://www.mckinsey.com/industries/financial-services/our-insights/global-banking-annual-review-2023#)

Якщо коротко, то концепція банкінгу Bank 4.0 це ідея того, що фінансові послуги стають вбудованою частиною цифрового життя користувача. Банк просто перестає бути місцем або окремим додатком. Він стає фоном, набором API та автоматизованих сервісів, що працюють у реальному часі.

У центрі Bank 4.0 :

1. API-first архітектура,
2. швидкість,
3. Максимально повна автоматизація,
4. штучний інтелект,
5. відкриті дані,
6. embedded finance та
7. фінансові функції, інтегровані в сторонні екосистеми.

Для банків це означає перехід від традиційних процесів до сервісної моделі, де банкінг «всюди»: у месенджерах, маркетплейсах, мобільних застосунках партнерів і будь-яких цифрових точках взаємодії.

Це потребує від аналітиків глибокого розуміння інтеграцій, моделей даних, побудови «хореографії» процесів, open banking стандартів, безпеки, NFR та поведінки систем у реальному часі. Концепція Bank 4.0 визначає, як повинні мислити, працювати та проектувати рішення сучасні бізнес-аналітики.

А що конкретно відбувається з роллю бізнес-аналітика? Все дуже просто — еволюція банкінгу від Bank 1.0 до 4.0 демонструє, що роль бізнес-аналітика зміщується від локального опису функцій, функціональних та не функціональних вимог до проєктування взаємодії цифрових екосистем, де банк є просто «вбудованою» частиною.

Оскільки концепція Bank 4.0 це «подієва», децентралізована, «всюди присутня» банківська логіка, то з погляду бізнес-аналізу та архітектури це класична «хореографія», але з елементами «оркестрації». Бо оркестрація у Bank 4.0 безумовно теж присутня, але вже як допоміжний шар суто для формальних, регламентованих, контрольованих процесів.

Таким чином в ролі бізнес-аналітика, яка відповідає періоду Bank 4.0 спостерігається головний зсув. Ми йдемо від «процесного» аналітика до, так би мовити, до «архітектора взаємодій». Наприклад в епоху Bank 3.0 BA був орієнтований на: бізнес-процеси, екрани, вимоги, сценарії, UX взаємодію користувача з банком.

В епоху Bank 4.0 BA органічно стає технологічним аналітиком екосистеми, де головне вже: інтеграції, події, API, дані та поведінка сервісів у реальному часі.

Що стає у фокус уваги БА в епоху Bank 4.0 ? Перш за все:

1. Інтеграції, API та подієва взаємодія. BA повинен:

• проєктувати подієві потоки (event flow)

• описувати контракти в стандарті REST API , або в gRPC який є топовим стандартом для внутрішніх мікросервісів, де важлива швидкість, ефективність і низька затримка, або Webhooks коли це механізм push-подій коли система сама надсилає повідомлення іншій системі автоматично при настанні події («Я тобі напишу сама, коли щось станеться»)
• забезпечувати правильну логіку idempotency, retry, SLA
• продумувати обробку помилок між десятками сервісів
• враховувати роботу сторонніх провайдерів (Open Banking / partner API)

Чому? Бо банк більше не контролює всіх учасників процесу, бо логіка розподілена між різними системами. В рамках Bank 4.0 бізнес-аналітик повинен проєктувати «event choreography», а саме:

• Визначити, які сервіси «слухають» ці події
• які атрибути входять у payload (це корисне інформаційне навантаження повідомлення: тіла JSON-повідомлень у REST, тіло події у Kafka, або структура Protobuf у gRPC. Іншими словами Payload містить бізнес-дані (суми, ідентифікатори, клієнтів, статуси), на відміну від заголовків та метаданих.)
• як версуються ці події
• як забезпечити idempotency
• як обробляти помилки (retry, dead letters)

Хореографія подій, а не оркестрації ось тепер ключ Bank 4.0 з погляду бізнес-аналітика, і це веде його в глибину Data Engineering

1. Моделі даних стають важливішими за «екрани та кнопки»

У епоху Bank 4.0 BA повинен мислити: canonical model, domain-driven design, mapping між системами, data validation rules, event payload schema, data lineage. Іншими словами, усе тримається на якості даних. Таким чином, Data Engineering і Data Governance стали критично важливими для BA. У Bank 4.0 банк можна описати так «дані» + «події» + «інтеграції».

У такій архітектурі BA вже не просто «описує вимоги», а проєктує логіку руху даних між: core banking, каналами (mobile/web), антифрод/AML, скорингом, казначейством Data Warehouse / BI, партнерськими API. Тому роль аналітика змістилася у бік глибокої роботи з даними, що раніше було доменом Data Engineering .Просто для БА слід тримати у фокусі відповіді на такі прості питання:

• звідки надходять дані? (sources)
• в якому форматі? (варіанти XML/JSON/CSV)
• які трансформації відбуваються? (mapping rules)
• у яку таблицю/сервіс дані врешті потрапляють? (target model)
• хто споживає ці дані? (downstream systems)

Це ключова частина роботи БА у fintech: бо все падає завжди через неправильну модель даних. Тому тепер, Canonical Model це наше все (що ми й робили в наших проектах в NASDAQ, хоча це малу іншу офіційну назву, не Canonical Model) Це уніфікована модель даних, спільна для всіх сервісів. В рамках цієї моделі BA повинен:

• визначити сутності ( наприклад Account, Customer, Transaction, Limit, RiskScore)
• визначити атрибути
• визначити правила заповнення
• забезпечити, щоб усі системи «мапилися» саме на canonical model. Без цього всього повний хаос і несумісність даних

Далі про Data Mapping

Бізнес-Аналітик повинен створити таблиці перетворень:

XML → JSON: JSON → SQL: SQL → Data Warehouse: Events → Streams (Kafka) У NASDAQ, наприклад, це створення mapping. Business rules (BR) tables, де звіряються дані ingestion → validation → transformation → reporting. Насправді це «чиста» Data Engineering робота, але зараз й БА повинен також занурюватись в цю проблему

Як відомо, INGESTION це процес завантаження даних, або первинне отримання даних із джерел. Що відбувається на цьому етапі:

• отримання даних із корбанкінгу (core), платежів, AML, treasury, CRM
• прийом файлів (CSV/XML), API-викликів, подій (Kafka)
• парсинг форматів (XML → JSON → internal format)
• збирання даних у raw-layer (landing area)

І щож тут робить бізнес-аналітик? А соб що;

• описує схему вхідних даних (input schema)
• прописує обов’язкові поля
• визначає правила парсингу
• задає правила обробки помилок (reject, quarantine, skip)
• формує «ingestion contract»

«Вічні» та «типові» проблеми ingestion: відсутні поля, некоректна дата, зіпсований формат XML, дублікат події, некоректні валютні суми невідповідність schema v1/v2 ( або в загалі відсутність)

Іншими словами в фінтех бізнес-аналітик відповідає за моделі даних, BR-правила, canonical model, mapping, data lineage та якість даних на всіх етапах. Помилка на будь-якому шарі робить недостовірними фінансові показники, ризикові метрики та регуляторну звітність.

1. Визначення «єдиного джерела правди» (Single Source of Truth (SSOT)

Наприклад: Customer master → MDM: Account master → Core Banking; Transaction master → Ledger: Risk data → Risk Engine

Іншими словами BA визначає: де саме істина? які дані authoritative?

А ще є окрема проблема обробки даних від SEPA. Саме БА визначає Single Source of Truth для всіх сутностей платежу, а саме:

Аналізує всі системи, через які проходить транзакція (Channel → Orchestrator → Gateway → Core → DWH). Визначає, де зберігається еталонна версія: pain.001 payload, статус, сума, дебет/кредит, settlement-дати, return-коди. Документує це як Data Ownership Matrix. Зараз це ключове слід знати, що без SSOT SEPA-процес розвалюється

Окремо слід зупинитись на використання технології блокчейна в фінтеху. Іноді є непорозуміння з цього питання. Пройдемось по деяких нюансах.

SEPA це централізована схема європейських платежів ( з врахуванням стандарту ISO 20022) та яка працює через централізовані CSM (Clearing & Settlement Mechanisms). В SEPA є чіткий перелік центральних клірингових платформ:

• EBA Clearing (STEP2)
• RT1 (Instant Payments)
• Target2 / TIPS
• локальні ACH (меншою мірою)

Всі банки під’єднуються до цих центральних інфраструктур.
Це класична hub-and-spoke модель (це архітектурна топологія, у якій є центр (hub)де є головний вузол, який керує всіма операціями, а усі інші системи (банки, учасники) під’єднані через «спиці» (spokes) до цього центру. Взаємодія учасників завжди проходить через hub. Головна ідея полягає в тому, що усі дані, повідомлення та транзакції проходять через центральну точку.
Учасники не взаємодіють безпосередньо один з одним) тобто це точно не peer-to-peer. Іншими словами, жоден банк не надсилає pacs.008 іншому контрагенту напряму. Усе проходить через централізований кліринг.

Що потрібно мати на увазі БА? В епоху Bank 4.0. слід знати, що внутрішня архітектура банку децентралізована (події, мікросервіси), але зовнішній світ платежів (SEPA/SWIFT) залишається централізованим. Тобто: внутрішньо для банку — це «хореографія» (event-driven, pub/sub) а зовні виключно hub-and-spoke (CSM, SWIFT, clearing houses) тобто там — «оркестрація».

Це ключове для BA, бо проектуєш події всередині банку, але маєш інтегруватися з централізованими схемами клірингу.

А де ж тут блокчейн? У Bank 4.0 блокчейн не є основою SSOT чи внутрішньобанківських процесів. SSOT реалізується через ledger, подієве сховище та canonical model.

Блокчейн застосовується лише там, де потрібна міжорганізаційна довіра: cross-border settlement, tokenization, digital identity або trade finance. Це важливо знати БА якщо є потреба в розвитку сервісів в рамках концепції Bank 4.0

ВИСНОВОК:

Концепція Bank 4.0 радикально змінила банківську індустрію: від «банку як місця» до «банку як API», від процесів до подій, від центральних систем до інтегрованих цифрових екосистем.

Роль бізнес-аналітика під цим впливом перетворилася майже повністю. Роль BA зміщується від «процесного аналітика» до «архітектора взаємодій»

У епоху Bank 1.0–3.0 BA працював з: бізнес-процесами; екранами; формами; сценаріями; UX-поведінкою; «крок → дія → крок» логікою.

У Bank 4.0 BA вже працює з: подіями, чергами, стрімами, API, контрактами, payload-схемами, мікросервісними взаємодіями, хореографією сервісів, версіюванням подій, правилами idempotency, retry, SLA

Тобто BA перестає бути людиною «просто розкажіть, які вам потрібні екрани та що ви очкуєте ?» і стає людиною яка ставить головне питання «як саме має поводитися цифрова екосистема». І це ключова зміна. Подієва архітектура.

Тепер BA працює ( або буде працювати) з «хореографією», а не з «оркестрацією»

Слід знати, що в концепції Bank 4.0: core логіка всередині банку = event-driven, але взаємодія зовні (SEPA/SWIFT) = hub-and-spoke оркестрація. Тому BA повинен вміти проектувати: які події виникають, хто їх «слухає», яка структура payload повинна бути, які правила повтору (retry), як уникнути дублікатів (idempotency), data lineage між сервісами та dead-letter черги та реакції на них.

Це вже не класична операційна аналітика це вже елементи аналітичної архітектури. Моделі даних стають важливішими за екрани та кнопки. BA стає частково «Data Engineer + Data Governance» спеціаліст. Data Engineering та Data Governance стає тепер зоною відповідальності BA.

Від БА вимагається системне мислення та розуміння архітектури, тобто слід розуміти: мікросервіси, API gateway, event streaming (Kafka), event sourcing, CQRS (тобто це архітектурний патерн, у якому читання даних (Queries) і зміна даних (Commands) розділяються на різні моделі, сервіси або навіть різні сховища. Це придумали для складних систем (банки, платежі, ризик, core ledger): де читання даних дуже часте, але зміна даних дуже критична. Тобто ці два типи операцій мають різні вимоги до швидкості, консистентності та структур даних. Тому їх і розділяють.), message queues, orchestration/choreography, retry patterns, schema versioning. Без цього неможливо описати event-driven продукт.

Я якщо зовсім коротко, бізнес-аналітик в епоху Bank 4.0 це людина, яка розуміє, як працюють ( й «течуть») дані, API, події та інтеграції. Він не просто «малює процеси» в нотації BPMN або UML, він проектує, як різні ( не банківські системи) будуть обмінюватися інформацією з банківською системою та що вважати «правдою». Це головна різниця з тим, яким був BA ще 5–10 років тому.