Як створити онлайн-банкінг для бізнесу: роадмап, бізнес-вимоги та ключові модулі. Chapter 1

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

Усім привіт! Мене звати Костянтин Каширін. Більшу частину своєї карʼєри я працював у банкінгу, і це мій перший допис про дистанційне банківське обслуговування (ДБО). Якщо точніше — про те, як ми будемо створювати ДБО для юридичних осіб з абсолютного нуля. І так, це перша стаття, наступні будуть краще оформлені, сподіваюсь.

Але почнемо з початку. Трохи непотрібної передісторії та значно цінніших планів (роадмапи).

Відправна точка

Вся ця історія почалася з моменту, коли я прийшов до прекрасного «Ощадбанку» для оформлення зарплатної картки. Побачивши абсолютно незручний інтерфейс і логіку того, як менеджер створював мене як клієнта та прив’язував до зарплатного проєкту, я згадав про свого друга (не себе, чесно!). Він працював в одній нішовій конторі, яка розробляла ДБО для банків саме для того, щоб була можливість відмовитися від старого доброго «iFobs».

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

Цілі

У нас буде одна велика практична ціль: написання серйозного бекенду та «вайбкод» фронтенду. Чому фронт ми просто «вайбкодимо»? По-перше, дизайн — річ суб’єктивна, а по-друге (і це головне), я поганий UI/UX дизайнер.

Увесь код буде доступний на GitHub, і ви зможете робити з ним усе, що заманеться. Для наочності уявимо, що ми пишемо ДБО саме для Ощадбанку. (Шановні юристи поважного Ощаду, дуже прошу не подавати на мене в суд за використання назви та елементів дизайну. Ціль суто освітня, грошей за це я не беру).

Важливо

Це буде проєкт із кінцевою датою та широким функціоналом. Ми не будемо робити «аби було». Це буде повноцінний продукт, який можна забрати собі, підкрутити під власні потреби і використовувати.

Кінцева дата релізу — 15.04.2027.

Роадмап

Роадмап проєкту: Від ідеї до Product in Prod

Щоб ви розуміли масштаб і обсяг роботи на найближчі місяці, наш шлях буде поділено на чотири логічні фази. Просто написати код — це лише 20% успіху, тому ми пройдемось по всьому життєвому циклу розробки (Stage-Gate):

1. Фаза 1: Бізнес, Вимоги та Комплаєнс (G1). Визначаємо бізнес-цінність, закладаємо фундамент безпеки (GDPR, PCI DSS, DORA) та формуємо чіткі системні вимоги.
2. Фаза 2: Архітектурне бачення (G2). Проєктуємо High-Level Design (HLD), обираємо стек (Java, Spring Boot, бази даних, брокери повідомлень) і, найголовніше, налаштовуємо Quality Gates (CI/CD, лінтери, SonarQube можливо якщо на це буде настрій) до початку активної розробки.
3. Фаза 3: Детальне проєктування та розробка (G3). Пиляємо мікросервіси, налаштовуємо Event-Driven взаємодію, розподілені транзакції (Saga, Outbox і інші патерни які можна знайти тут microservices.io) та Security by Design.
4. Фаза 4: Інфраструктура та Observability. Контейнеризація, моніторинг (метрики, трейсинг, логування), навантажувальне тестування та підготовка до релізу.

Початок (Всі ситуації та персонажі вигадані)

Уявімо, що ми — крута фінтех-компанія «DutchRudder». До нас приходить «Ощадбанк» із запитом:

«Напишіть нам ДБО для юридичних осіб. Перед цим нам його робила якась лайнокомпанія з Києва, що сидить у пошарпаному БЦ, де у розробників туалет за стіною і чути, як туди ходять. СТО та СЕО там — любителі випити, набирають суцільних джунів, видаючи їх за сеньйорів із зпшкою по 500 доларів. Всі давно забили болт на продукт, і тепер ми сидимо в шоці: ні грошей, ні системи, а клієнтам треба ще на вчора».

Щоб усе це переварити і зробити «по красотє», ми спочатку оберемо стратегію, налаштуємо процеси, проаналізуємо реальні потреби банку, побудуємо архітектуру, і вже після цього — напишемо код. Щоб не перетворитися на таку ж сумнівну контору, ми починаємо з дисципліни — з етапу G0.

Тож почнемо по Quality Gates, а саме з G0

На цьому етапі ми повинні розуміти, чого ми хочемо і взагалі для чого. У G0 ми описуємо ЩО ми хочемо дати клієнту як цінність. А от ЯК саме система перевірятиме КЕП і таблиці маршрутизації підписів — це ми залишимо для G1.

Щоб не перетворити наш продукт на нескінченний довгобуд, ми маємо одразу зафіксувати межі нашого ДБО. Ми ділимо систему на великі бізнес-модулі. На етапі G0 нам не потрібні технічні деталі, нам важливо розуміти, який функціонал ми «продаємо» банку та його клієнтам.

1. Клієнтський сегмент та Рольова модель

Корпоративний бізнес — це не моноліт. Наше ДБО має адаптуватися під два абсолютно різні типи клієнтів:

• ФОПи: Їм потрібна швидкість, простота і мінімум бюрократії.
• Юридичні особи (ТОВ, і багато інших наборів букв): Їм потрібен складний контроль, багаторівневість та ієрархія.

Тому ми закладаємо підтримку гнучких корпоративних ролей: CEO, CFO, Головний бухгалтер, лінійні менеджери,

2. «Access Management & Безпека»

Бізнес хоче контролювати свої гроші. Тому ми закладаємо:

• Гнучку матрицю доступів: можливість надати конкретному менеджеру доступ лише до одного рахунку з лімітом у 50 000 грн.
• Складну логіку накладання підписів (КЕП): наприклад, бухгалтер створює платіж, а фінансовий директор та CEO повинні його підписати.

3. «Транзакційне ядро» (Платежі)

Кровоносна система будь-якого ДБО. Ми маємо реалізувати:

• Платежі в національній валюті та миттєві перекази.
• Міжнародні валютні перекази (SWIFT/SEPA, купівля/продаж валюти).
• Бюджетні платежі (податки, збори зі специфічними реквізитами).
• Масові (пакетні) платежі для розрахунку з десятками контрагентів в один клік.

4. «Зарплатні проєкти»

HR та бухгалтерія не повинні щомісяця страждати. Ми робимо модуль для:

• Перегляду та управління активними зарплатними угодами.
• Легкого онбордингу: подача заявок на випуск карток для нових співробітників або підключення існуючих карток до зарплатного проєкту.

5. «Кредити та Депозити»

Фінансові інструменти для примноження та залучення капіталу:

• Перегляд поточних заборгованостей або траншів.
• Можливість відкриття нових депозитів чи подачі заявок на кредитні лінії онлайн.

6. «Комунікація та Нотифікації»

Клієнт повинен розуміти, що відбувається. Це пуш-повідомлення про списання, системні алерти про зміну статусів платежів та безпечний канал зв’язку з банком.

7. «Back-Office (Адмін-панель банку)»

Ми пишемо ДБО не тільки для клієнта, а й для працівників банку. Це окрема прихована частина системи, де:

• Менеджери банку обслуговують клієнтів.
• Адміністратори керують глобальними лімітами, комісіями та здійснюють технічну підтримку.
• А також по суті вся робота менеджерів буде проходити в Адмін панелі
• Працювати з фіз особами в мацбутньому

8. «Регуляторна відповідність та Стійкість» (Compliance)

Це фундамент, без якого банк просто втратить ліцензію. Бізнесу на цьому етапі байдуже на патерни в коді, але йому важливо спати спокійно. Ми одразу закладаємо вимоги до:

• GDPR: Жорсткий контроль персональних даних клієнтів (право на забуття, шифрування, анонімізація).
• PCI DSS: Ізоляція та безпека роботи з картковими даними.
• DORA (Digital Operational Resilience Act): Операційна стійкість. Система повинна вижити і продовжити роботу, навіть якщо один із дата-центрів повністю вийде з ладу.

9. «Управління рахунками та Виписки»

Базовий, але критично важливий інструмент для головного бухгалтера. Ми маємо передбачити:

• Перегляд залишків та консолідований контроль коштів по всіх рахунках групи компаній на одному дашборді.
• Генерацію виписок за будь-який період із гнучкими фільтрами.
• Експорт даних в усіх корпоративних форматах: PDF, CSV, Excel, XML та спеціалізованих банківських стандартах (наприклад, MT940).

10. «Інтеграції та Open API»

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

• Інтеграції з банком та іншими установами по типу НБУ.
• Надання безпечного Open API (B2B Gateway) для автоматичного імпорту платежів та отримання виписок машинами без участі людини.

11. «Документообіг та Інвойси»

Клієнтам зручно тримати всі фінансові процеси в одному вікні. Ми додаємо:

• Генерацію та виставлення інвойсів контрагентам прямо з інтерфейсу банку.
• Внутрішній електронний документообіг (ЕДО) для обміну договорами, актами та довідками з накладанням КЕП.

12. «Аналітика, Звітність та DWH»

Керівникам (СЕО та CFO) потрібні не просто транзакції, а розуміння фінансового здоров’я бізнесу. Ми реалізуємо:

• Візуалізацію грошових потоків, аналітику за категоріями витрат і доходів.
• Інструментарій для вивантаження великих масивів даних у корпоративні сховища клієнта (DWH) для їхніх внутрішніх систем.

13. «Інтеграційний прошарок з бексистемою банку»

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

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

До зустрічі.