Why Banking IT Looks Stable — But Not the Bank
- Sunil Dutt Jha
- 4 days ago
- 4 min read
CIO Diagnostic Series — Banking Edition
From the outside, banking IT appears robust.
Core Banking is stable. Digital channels function. Payments run at national scale. Treasury and ALM systems operate. AML, KYC, and fraud platforms are in place. CRM and analytics tools run across the bank. Cloud, API, and modernization programs are underway.
It looks structured — until something breaks.
The Illusion of Structure
Banks proudly list systems:
Our core banking system is upgraded.
UPI/RTGS/ACH are integrated.
AML and fraud engines are automated.
LOS, CRM, and card platforms are mature.
Treasury and ALM are digitized.”
We have data lakes, MDM, and analytics.
We modernized our API and DevOps stack.
Useful achievements. But they reflect P5 implementation, not P1–P4 architecture.
That is the distinction most banks never make.
What the Enterprise Really Looks Like (Architecturally)
Every banking activity — onboarding, lending, payments, trading, risk management, compliance, finance, service — runs across six architectural layers:
P1 — Strategy
Why the function exists. What value it must deliver.
P2 — Process
How the work should flow. Dependencies. Hand-offs.
P3 — Business Logic / System Logic
Rules, validations, calculations, timing, meaning.
P4 — Components
APIs, tables, datasets, configurations, product specs.
P5 — Implementation
Systems, workflows, releases, integration, vendor tools.
P6 — Operations
Behavior in production: exceptions, delays, stability, reliability.
Banks spend 90% of their time, budget, and conversations at P5.
The enterprise above it — P1–P4 — remains unmapped.
On Paper, the Bank Looks Like This
Across the D1–D15 enterprise functions, each domain points to a long list of systems.
Retail & Corporate Banking
CBS, LOS, Card Platform, Collections, Deposits Engine, Trade Finance → P5
Payments & Digital Channels
UPI, RTGS, ACH/NEFT, IMPS, Card Switch, Payment Hub, Wallet, Tokenization → P5
Treasury & Capital Markets
Treasury Core, Deal Capture, Trading, ALM, Market Risk Engines → P5
Risk Management
Credit Scoring, Limits, EWS, Model Management, Stress Testing → P5
Compliance & Legal
AML, Sanctions Screening, Case Management, Reporting → P5
Fraud & Cybersecurity
Fraud Analytics, SIEM, IAM, DLP, Endpoint Security → P5
Finance & Revenue
GL, Sub-ledgers, Reconciliation Engines, Profitability Tools → P5
Customer Experience & CRM
Contact Center, CRM, Complaint Management, CX Analytics → P5
Marketing & Product
MarTech, Campaign Management, Pricing Engine, Product Catalog → P5
Technology, Integration & Infrastructure
API Gateway, ESB, BPM, ITSM, Monitoring, DevOps, Cloud → P5
These are systems, not architecture.
They run the enterprise. They do not define it.
The Banking Illusion: “We Have the Systems, So We Must Have the Architecture”
The assumption is:
If CBS is modern, the retail stack is solid
If UPI/RTGS work, payments are architecturally sound
If AML screens correctly, compliance is structurally covered
If treasury platforms run, exposures and limits are coherent
If CRM is integrated, customer experience is unified
If the API layer is active, the bank is modern
None of these are true without P1–P4.
A modern P5 system running on a fragmented P1–P4 foundation simply delivers structured instability.
Where Banking Actually Breaks (Architectural View)
Banks fail in predictable places — never at P5 first.
✦ P3 Logic Drift
Rules for fees, interest, KYC, routing, reconciliation, limits get duplicated across:
CBS
CRM
channels
card systems
LOS
AML
switch
treasury
APIs
None have a single enterprise owner.
✦ P2 Process Divergence
Retail, Corporate, Payments, Risk, and Finance define flows differently.
Onboarding differs by channel. Pricing differs by product. KYC differs by segment. Reconciliation differs by ledger. Settlement differs by payment rail.
✦ P4 Component Fragmentation
Customer tables differ everywhere. Product definitions differ everywhere. Pricing components differ everywhere. Fee tables differ everywhere. Risk attributes differ everywhere.
✦ P1 Strategic Misalignment
Growth, compliance, risk, CX, and digital strategy operate as separate streams.
All of these failures begin before IT, but appear in IT systems.
Which is why the CIO gets blamed.
The Reality: Banks Run Systems — Not Enterprise Anatomy
So banking IT is “structured” only in the sense that:
hundreds of systems exist
thousands of integrations connect them
millions of transactions pass through them
But underneath:
strategy is not unified (P1)
processes are inconsistent (P2)
logic is scattered (P3)
components are duplicated (P4)
So the bank runs systems, not architecture.
This is why:
transactions fail
reconciliations break
AML produces false positives
pricing varies by channel
reporting surprises occur
compliance escalates
modernization slows
customer experience diverges
P5 symptoms reflect P1–P4 gaps.
The CIO Sentence That Changes Everything
“Show me the D# and the P# — then we’ll know what to fix.”
This flips the conversation from:
Core failed
Payments failed
AML failed
Digital failed
to:
D4 × P3 logic
D12 × P4 components
D7 × P2–P3 alignment
D9 × P3–P4 meaning
D1 × P3 pricing divergence
This creates clarity, ownership, and accountability.
Key Intelligence for Banking CIOs
Banking IT looks structured only because P5 systems run hard.
But the architecture above them — P1–P4 — is incomplete.
That is the hidden reason banks modernize slowly, fail repeatedly, and escalate continuously.
Once the bank is expressed as D1–D15 × P1–P6:
failures become predictable
exceptions become diagnosable
rules become ownable
change becomes stable
modernization accelerates
Banks don’t need better tools. Banks need better anatomy.