IndusTrust Bank

The Problem

My original Bank Management System was a console-based Java/JDBC app — a Scanner loop against MySQL with plaintext passwords and PINs, double for money, and a transfer that never even checked the receiving account existed. It worked as a class exercise, but it wasn't safe to expose to a browser, let alone a stranger.

Architecture & Approach

Rebuilt as IndusTrust Bank — a session-authenticated Spring Boot service with Spring Security, a genuine double-entry ledger, and BigDecimal money throughout. Every transfer locks both accounts with PESSIMISTIC_WRITE (lowest account number first, so two opposing transfers can't deadlock each other), verifies the receiver exists, and writes two linked ledger legs under one shared reference. Expanded past the original scope with saved beneficiaries, bill pay (which debits a real account through the same locked path, not a shadow record), virtual cards, a support desk, and a password-change flow — all behind per-user ownership checks enforced server-side, not just hidden in the UI.

Engineering Challenges & Solutions

• Replacing double balances and plaintext passwords/PINs with BigDecimal and BCrypt, without changing the arithmetic semantics anywhere else in the app
• Locking both accounts in a transfer in a deterministic order (lowest account number first) so two opposing transfers can't deadlock each other
• Keeping bill pay from becoming a second, un-audited way to move money — it now calls the exact same locked debit path as a manual withdrawal, just with its own description and a shared ledger reference
• Recovering a git history gap before deployment — an early commit had silently dropped the entire resources folder and CI workflow, caught and rebuilt from the last compiled build before it reached production

Outcome & Results

A fully deployed, session-authenticated banking service — 23 REST endpoints across accounts, transfers, beneficiaries, bill pay, cards, and support — with an integration suite proving cross-user access is forbidden and insufficient-balance transfers are rejected, running in CI on every push.

Lessons Learned

The scariest bugs aren't the ones that crash — they're the ones that quietly corrupt a number. A transfer with no locking and no receiver check will work in every demo and fail exactly once, expensively, in production. Building the ledger and the locking first, before any feature sat on top of them, made every later addition safe by construction instead of by review.