WHAT MOST PEOPLE DON'T REALIZE ABOUT BANKING SOFTWARE
When people think about software for banks, they usually think about the customer-facing side: mobile apps, internet banking, transaction interfaces.
That's the visible layer.
But underneath it, banks run on a completely different category of software: internal operations systems that manage everything from physical assets and procurement to tax compliance, vendor contracts, and fleet logistics. These systems are invisible to customers but critical to everything the bank does operationally.
For 15 months, from November 2022 to February 2024, I was part of the engineering team that built one of these systems for IFIC Bank, one of Bangladesh's largest private commercial banks.
What we delivered was a 20-module Financial ERP covering the bank's entire internal operations lifecycle. This is the story of what that actually involved: the scope, the complexity, the technical decisions, and what building software at banking-grade standards taught me.
THE SCOPE: 20 MODULES, ONE SYSTEM
The first thing that strikes anyone looking at this project is the sheer breadth of what needed to be built.
Twenty modules. Each one a complete functional system in its own right. Each one deeply interconnected with the others. All of them operating inside the compliance and audit requirements of a regulated financial institution.
Here's what the full scope looked like:
Asset Lifecycle Management
Fixed Asset Management handled the complete lifecycle of every physical asset the bank owned, including acquisition, depreciation, location tracking, maintenance scheduling, and valuation reporting. Disposal Management covered the formal process of retiring assets, with approval workflows, write-off accounting, and audit documentation. Together these two modules gave the bank a single source of truth for its entire asset portfolio.
Financial Operations
General Ledger was the financial backbone of the entire system. Every transaction across every module flowed into the GL, ensuring that procurement orders, asset write-offs, rental payments, and vendor invoices all reconciled automatically into accurate financial reporting. Budget Control sat on top of this, giving department heads real-time visibility into spending against allocated budgets.
Procurement & Inventory
Procurement managed the full vendor engagement cycle: requisitions, approvals, purchase orders, goods receipt, and payment processing. Inventory tracked stock levels across the bank's locations in real time, triggering procurement workflows automatically when thresholds were crossed.
Compliance & Tax
VAT & Tax Management automated tax calculation across all procurement and payment transactions, ensuring compliance with Bangladesh National Board of Revenue requirements. Archive Management maintained a complete, searchable record of all documents and transactions for regulatory audit purposes.
Operations & Logistics
Cash in Transit managed the movement of physical cash between bank branches, including tracking, authorization, and reconciliation. Transport Pool handled the bank's fleet of vehicles: assignment, maintenance scheduling, fuel tracking, and cost allocation. Rental Management covered the bank's leased properties and equipment.
Workforce & Vendor Management
Outsourced Manpower tracked third-party vendor workforce deployed across the bank's operations. Resource Tracker managed internal resource allocation across departments and projects.
Communication & Delegation
Memo digitized the bank's internal formal communication workflows. Delegation Management handled authority handoff, ensuring that when a senior official was unavailable, their approvals and responsibilities transferred correctly to designated alternates.
Core Banking Integration
CBS Integration connected the entire ERP to IFIC Bank's Core Banking System so that financial transactions in the ERP reflected accurately in the bank's core financial records in real time.
Twenty modules. Built as one coherent system.
THE TECHNICAL DECISIONS THAT MATTERED MOST
Working on a system at this scale forces you to make architectural decisions that have consequences for years. Here are the ones I think about most when I look back at this project.
The General Ledger Integration Problem
The hardest architectural challenge in any multi-module financial system is keeping the GL accurate across all transaction types. When a procurement order is raised, approved, goods are received, and payment is processed, each of those events has a different accounting implication. When an asset is disposed of, the write-off needs to flow correctly into the balance sheet. When a rental payment is made, it needs to be allocated to the right cost center.
Getting this right required designing a transaction event system where every module published standardized financial events, and the GL consumed them through a consistent interface. This meant the GL didn't need to understand the business logic of procurement or asset management. It just needed to receive well-formed financial events and record them correctly.
This separation of concerns sounds obvious in principle. Making it work across twenty modules with different data models and business rules required significant upfront design discipline.
Banking-Grade Audit Trails
Banks operate under regulatory requirements that demand complete, tamper-evident records of every system action. Every approval. Every modification. Every status change. With a timestamp, a user identifier, and a before/after state.
This wasn't an afterthought. We designed the audit trail infrastructure before we built the first module. Every write operation in the system passed through a centralized audit layer that recorded the change without the individual module needing to implement it explicitly. This kept the audit logic consistent and ensured nothing slipped through.
The CBS Integration Architecture
Connecting the ERP to the Core Banking System was one of the most technically sensitive parts of the project. CBS systems in banking are mission-critical infrastructure, and any integration that affects their data integrity or performance is treated with extreme caution.
We designed the integration as a one-directional financial sync. The ERP pushed validated, reconciled financial summaries to the CBS at defined intervals, rather than writing directly to CBS tables in real time. This protected CBS stability while ensuring the ERP's financial data stayed aligned with the bank's core records.
Role-Based Access Control at Scale
Twenty modules. A large organization. Multiple departments. Strict need-to-know data access requirements. The permission system needed to be granular enough that a procurement officer could see their module's data without seeing HR records, while a finance manager could see GL entries from all modules without accessing operational details.
We built a hierarchical RBAC system where permissions were defined at the module level, the feature level, and the data level independently, giving system administrators the flexibility to configure access precisely without needing developer intervention for every new role.
WHAT BANKING-GRADE DEVELOPMENT ACTUALLY MEANS
Working in a banking environment changed how I think about software quality in ways that have stayed with me on every project since.
In most software environments, "it works" is an acceptable standard for shipping. In banking, "it works" is the starting point for a much longer conversation.
Does it work correctly under every edge case? Does it fail gracefully when an external system is unavailable? Does it produce audit-ready records of every transaction? Does it handle concurrent access without data inconsistency? Does it enforce authorization at every level, not just the API surface?
These questions are standard in banking. They should be standard everywhere.
The discipline of designing for correctness first, not just functionality, is something I now apply to every system I build, regardless of the industry. A university payroll system that pays people incorrectly has the same severity of consequence as a banking system that misrecords a transaction. The stakes are just differently visible.
WHAT I TAKE FROM THIS PROJECT
Fifteen months on a 20-module banking ERP taught me things about system design that I couldn't have learned any other way.
I learned that large systems don't fail because of bad code. They fail because of bad boundaries: modules that know too much about each other, data models that can't accommodate business rule changes, integration points that couple tightly to implementation details that change.
I learned that in high-stakes environments, the most valuable engineering skill isn't writing fast code. It's asking the right questions before writing any code. Understanding the compliance requirement before designing the data model. Understanding the approval workflow before building the API. Understanding the reporting need before choosing the schema.
And I learned that the best way to build something at this scale is with a team that takes collective ownership, where every engineer understands not just their module but how their module fits into the whole.
That systems thinking (designing for correctness, designing for boundaries, designing for the whole) is what I bring to every project I take on now.
CLOSING
If you're building internal operations software for a financial institution, an enterprise, or a complex organization, and you need engineers who understand what banking-grade delivery actually requires, I'm available for consulting and development engagements.
📩 Send me a direct message or connect directly. I'm happy to talk through what you're building.
Top comments (1)
If you’re building or buying ERP for a university or large org—or wrestling with budget, payroll, or finance–HR integration—I’m happy to swap notes. Drop a comment or question and I’ll jump in.