Retail Internet Banking Portal
A full-featured web banking portal for individual clients, built as part of the “Nokk Client-Bank” suite, integrating with core banking infrastructure, SMS gateway, and a third-party payment processing network.
Overview
Industry: Banking / Fintech
Product Type: Retail Internet Banking Web Application
Architecture: Java MVC monolith with Spring Security auth layer, JSP/Bootstrap frontend, bank-side server integration via internal network
The portal gave retail banking clients self-service access to accounts, cards, payments, and communication channels. It operated as a front-end node that brokered all requests to the bank’s internal core banking server, with administrative control delegated to the bank’s IPadmin 5 configuration tool. The system supported multi-bank deployment, with per-bank feature configuration and custom payment templates managed at the administrator level.
Architecture Context
Environment
- Bank-hosted deployment: portal communicates with core banking server over internal network
- Administrative backend: IPadmin 5 — user management, account assignment, permission control
- SMS gateway: “SMS Nokk” — transactional and informational notifications for retail and corporate clients
- Payment processing: UFS (Ukrainian Financial Network / ПрАТ “Українська Фінансова Мережа”) processing interface
- Legacy starting point: servlet-based backend, plain HTML/JS frontend — full rewrite initiated mid-project
Stack
- Backend: Java, Spring Security, Spring MVC, JSP
- Frontend: HTML5, Bootstrap, JavaScript, jQuery, AJAX
- Auth layer: Login + password + SMS OTP (two-factor)
- Integration: UFS payment processing API, SMS Nokk gateway
Features
- Two-tier access model: read-only vs. full transactional access, configured per user at admin level
- SMS OTP for payment confirmation and login
- Payment template system with user-defined and bank-defined categories
- Scheduled (recurring) payments with calendar-based management UI
- In-portal messaging between bank and client
- Per-bank extensibility: credit and deposit modules implemented as optional overlays
My Contribution
- Executed initial phase as legacy stabilization: analyzed servlet-based codebase, identified structural limitations blocking feature development
- Made and owned the architectural decision to rewrite the platform from scratch on Spring Security + MVC; migrated frontend to Bootstrap/jQuery stack
- Implemented full Spring Security configuration: authentication flows, session management, role-based access control (read-only vs. transactional)
- Built SMS OTP integration for both login and payment confirmation flows via SMS Nokk gateway
- Developed the complete payments module: single payments, template-based payments, recurring payments with calendar UI, UFS processing integration
- Implemented account/card management: balance display, statement retrieval, limit management, SMS notification subscriptions, card blocking
- Built user self-service flows: registration, in-branch identity verification hook, personal settings, login history
- Designed and implemented internal messaging system (bank-to-client notifications and personalized offers)
- Delivered full portal UI: layout, component design, responsive behavior via Bootstrap
Engineering Highlights
Legacy stabilization decision. The project started as maintenance of a servlet-based system with flat HTML/JS on the frontend — no framework, no security abstraction, no separation of concerns. Root-cause analysis showed that the codebase could not support the required feature set without accumulating unsustainable technical debt. Rather than patching incrementally, I proposed and executed a full platform rewrite: Spring MVC for request handling, Spring Security for auth and access control, Bootstrap for a maintainable frontend. The decision added upfront cost but was the only viable path to a production-ready product.
Two-tier access control model. Banking context requires fine-grained permission enforcement at both UI and API level. I implemented a role model distinguishing read-only access (statements, product info, messaging) from full transactional access (payments, transfers, account management) — enforced via Spring Security at the controller layer, not just the view. Admin-side permission assignment in IPadmin 5 was reflected in session context on login, ensuring no client-side manipulation could escalate privileges.
UFS payment processing integration. Connecting to the UFS network required implementing their processing interface within the payment flow while maintaining transactional consistency: a payment initiated on the portal had to be confirmed via SMS OTP before being submitted to the processor. Failure paths (OTP timeout, processor rejection) required explicit state handling to avoid double submissions or silent failures — a non-trivial edge case in a banking context.
Three-year development without production launch. The full retail feature set was delivered and validated over three years. Despite functional completeness, the system was never deployed to production — a business/organizational outcome outside engineering scope. From a platform engineering standpoint, the project delivered a fully specified, implementable reference architecture for a Spring-based retail banking portal.
Technologies
Java, Spring MVC, Spring Security, JSP, HTML5, CSS, Bootstrap, JavaScript, jQuery, AJAX
