sujith123143/bank-

Purpose and Entry Points

NexBank is a Flask-based bank-management system exposing a REST API and serving an interactive browser dashboard. Runtime startup is run.py; application construction and route/middleware registration are centered in app/main.py. The static dashboard assets are index.html, script.js, and style.css.

HTTP API Boundary

API controllers are partitioned by banking capability: authentication, accounts, customers, cards, loans, transactions, reporting, employee operations, and administration. Controllers form the request boundary and should delegate domain work rather than access storage directly.

• app/api/auth.py

• app/api/accounts.py

• app/api/transactions.py

• app/api/admin.py

• app/api/loans.py

Request Security and Authorization

Requests pass through authentication/error middleware, JWT session handling, and role-based permission checks. Password and PIN protection are separate concerns: bcrypt-style password handling, PBKDF2 PIN hashing, and encryption utilities protect sensitive data. This boundary determines identity and allowed operations before service execution.

• app/middleware/auth_middleware.py

• app/middleware/error_middleware.py

• app/authentication/jwt.py

• app/authentication/password.py

• app/authorization/rbac.py

Business-Service Layer

Services implement core banking use cases, notably login/session behavior, account lifecycle operations, and transaction execution. They mediate between API schemas/validation and persistence repositories, making them the primary location for transactional business rules.

• app/services/auth_service.py

• app/services/account_service.py

• app/services/transaction_service.py

• app/dependencies/deps.py

Persistence and Domain Model Boundary

Repositories isolate database operations behind account and transaction access abstractions; models represent persisted banking entities. Database setup selects SQLite or MySQL support, with the checked-in SQLite database operating in WAL mode (nexbank.db, nexbank.db-wal).

• app/repositories/base_repository.py

• app/repositories/account_repository.py

• app/repositories/transaction_repository.py

• app/database/connection.py

• app/database/init_db.py

• app/models/account.py

• app/models/transaction.py

Data and Control Flow

The primary flow is: dashboard or API client → Flask controller → middleware/JWT/RBAC → validation/schema handling → service → repository → SQLite/MySQL → normalized JSON response. Error middleware and custom exceptions provide a cross-cutting failure boundary, while response schemas standardize API output.

• app/schemas/response.py

• app/validators/input_validators.py

• app/exceptions/custom_exceptions.py

• app/constants/status_codes.py

Operations and Supporting Infrastructure

Configuration is environment-driven, seeded data can initialize usable banking records, and application logging provides operational visibility. External/runtime dependencies are Python/Flask, SQLite or MySQL, JWT-based clients, and the browser frontend.

• app/config/settings.py

• .env.example

• scripts/seed_data.py

• app/logging/logger.py

• requirements.txt