Nokk Soft Client-Bank

Портал web-банкінгу

Повнофункціональний веб-портал банківського обслуговування для фізичних осіб, розроблений у складі пакету “Nokk Client-Bank” з інтеграцією до основної банківської інфраструктури, SMS-шлюзу та стороннього процесингового мережевого вузла.

Огляд

Галузь: Банківська справа / Фінтех
Тип продукту: Веб-застосунок роздрібного інтернет-банкінгу
Архітектура: Java MVC-моноліт із шаром автентифікації Spring Security, JSP/Bootstrap frontend, серверна інтеграція з банком через внутрішню мережу

Портал надавав клієнтам роздрібного банку самостійний доступ до рахунків, карток, платежів та каналів зв’язку. Він функціонував як фронтальний вузол, що транслював усі запити до внутрішнього core banking сервера банку; адміністративне управління делегувалося конфігураційному інструменту IPadmin 5. Система підтримувала розгортання для кількох банків із налаштуванням функціоналу та кастомних платіжних шаблонів на рівні адміністратора.

Архітектурний контекст

Середовище

Розгортання на стороні банку: портал взаємодіє з core banking сервером через внутрішню мережу
Адміністративний backend: IPadmin 5 — управління користувачами, призначення рахунків, контроль прав
SMS-шлюз: “SMS Nokk” — транзакційні та інформаційні сповіщення для роздрібних і корпоративних клієнтів
Процесинг платежів: інтерфейс UFS (ПрАТ “Українська Фінансова Мережа”)
Початкова точка — legacy: servlet-based backend, plain HTML/JS frontend — повне переписування ініційовано в середині проєкту

Стек

Backend: Java, Spring Security, Spring MVC, JSP
Frontend: HTML5, Bootstrap, JavaScript, jQuery, AJAX
Рівень автентифікації: логін + пароль + SMS OTP (двофакторний)
Інтеграції: платіжний API UFS, SMS-шлюз Nokk

Функціональність

Дворівнева модель доступу: лише перегляд vs. повний транзакційний доступ, налаштовується на рівні адміністратора
SMS OTP для підтвердження платежів та входу
Система платіжних шаблонів із користувацькими та банківськими категоріями
Регулярні платежі з UI управління на основі календаря
Внутрішній месенджер між банком і клієнтом
Розширюваність під конкретний банк: модулі кредитів і депозитів реалізовані як опціональні надбудови

Мій внесок

Початкова фаза — стабілізація legacy: аналіз servlet-based кодової бази, виявлення структурних обмежень, що блокували розробку функціоналу
Прийняття та реалізація архітектурного рішення про повне переписування платформи на Spring Security + MVC; міграція frontend на стек Bootstrap/jQuery
Реалізація повної конфігурації Spring Security: флоу автентифікації, управління сесіями, рольовий контроль доступу (перегляд vs. транзакційний)
Побудова SMS OTP-інтеграції для флоу входу та підтвердження платежів через шлюз SMS Nokk
Розробка повного модуля платежів: разові платежі, платежі за шаблонами, регулярні платежі з календарним UI, інтеграція процесингу UFS
Реалізація управління рахунками та картками: відображення балансу, отримання виписок, управління лімітами, підписки на SMS-сповіщення, блокування карток
Побудова флоу самообслуговування: реєстрація, хук верифікації особи у відділенні, особисті налаштування, історія входів
Проєктування та реалізація системи внутрішніх повідомлень (банківські сповіщення та персоналізовані пропозиції клієнтам)
Доставка повного UI порталу: розмітка, дизайн компонентів, адаптивна поведінка через Bootstrap

Інженерні кейси

Рішення про стабілізацію legacy. Проєкт розпочався як супровід servlet-based системи з flat HTML/JS на фронтенді — без фреймворку, без абстракції безпеки, без розділення відповідальності. Аналіз першопричин показав, що кодова база не може підтримати необхідний функціонал без накопичення непосильного технічного боргу. Замість поступового латання я запропонував і виконав повне переписування платформи: Spring MVC для обробки запитів, Spring Security для автентифікації та контролю доступу, Bootstrap для підтримуваного frontend. Рішення вимагало додаткових витрат на старті, але було єдиним реальним шляхом до production-готового продукту.

Дворівнева модель контролю доступу. Банківський контекст вимагає точного контролю прав як на рівні UI, так і на рівні API. Я реалізував рольову модель, що розрізняє доступ лише для перегляду (виписки, інформація про продукти, месенджер) і повний транзакційний доступ (платежі, перекази, управління рахунками) — виконується через Spring Security на рівні контролера, а не лише в представленні. Призначення прав у IPadmin 5 відображалося в контексті сесії при вході, унеможливлюючи підвищення привілеїв через маніпуляції на стороні клієнта.

Інтеграція процесингу платежів UFS. Підключення до мережі UFS вимагало реалізації їхнього процесингового інтерфейсу в платіжному флоу зі збереженням транзакційної узгодженості: платіж, ініційований на порталі, мав бути підтверджений через SMS OTP перед відправкою до процесора. Шляхи збоїв (тайм-аут OTP, відхилення процесора) потребували явної обробки стану для уникнення подвійних відправок або тихих збоїв — нетривіальний крайній кейс у банківському контексті.

Три роки розробки без виходу в продакшн. Повний набір функціоналу для роздрібного банкінгу було доставлено та валідовано протягом трьох років. Незважаючи на функціональну завершеність, система так і не була розгорнута в продакшні — бізнесовий/організаційний результат поза інженерною зоною відповідальності. З точки зору platform engineering проєкт доставив повністю специфіковану та реалізовану референсну архітектуру Spring-based порталу роздрібного банкінгу.

Технології

Java, Spring MVC, Spring Security, JSP, HTML5, CSS, Bootstrap, JavaScript, jQuery, AJAX