Banking Director EA FAQs - Why Banking Enterprise Architecture ≠ 180 IT Projects ?
- Sunil Dutt Jha
- Dec 10
- 6 min read
Updated: 6 days ago
Most banks still treat Enterprise Architecture as an IT exercise, which is why EA efforts don’t change customer journeys, credit decisions, risk exposure, or operational outcomes.
Bank EA ≠ Bank IT.
This Director EA FAQ explains where traditional EA breaks down and how a true enterprise anatomy reveals the structure that IT alone cannot see, align, or repair.
It explains logic of shadow anatomies, 12 banking use cases, and the One Bank One Anatomy™ advantage.
Q1: Why do 180 IT projects ≠ Banking Enterprise Architecture?
Myth:
Banking EA = Core Banking + Digital Channels + Compliance IT.
Reality:
Banking operates through 15 departments (D1–D15) such as Credit, Risk, Compliance, Treasury, Payments, KYC/AML—each with its own P1–P6 rule cycles.
Banking IT is only one department.
That is EA(IT), not the enterprise’s full anatomy.
Q2. Why do so many IT projects fail to represent the enterprise in this industry?
Because banking IT automates only a small fraction of P5 tasks, while a bank’s actual operating architecture lives entirely in P1–P4.
Every banking function — Credit, Risk, Operations, Compliance, Treasury, Payments, Collections — runs on a full P1–P6 structure:
P1 (Strategy) defines credit and risk strategy.
P2 (Processes) defines process flows for onboarding, underwriting, servicing, and collections.
P3 (System logic) defines scoring logic, pricing rules, limit checks, fraud rules, exception pathways.
P4 (Component Spec) defines components such as datasets, rule tables, eligibility checks, document types, and calculation engines.
This is the architecture of the bank.
IT projects, however, touch P5 only — the manual task layer — and typically automate just thin slices of it:
capturing application data
routing cases
performing simple validations
calling scoring services
updating status fields
generating notifications
The underlying structure (P1–P4) remains inconsistent and largely undocumented.
This creates the core mismatch:
The IT system automates "tasks" i.e. subset of P5.
The bank runs on Architecture (P1-p4). Those poilicy, rules and decisions were never architected.
Because P1–P4 is missing:
risk rules behave differently across LOS, core, and channels
pricing logic diverges by product and system
limit and exposure checks vary across workflows
AML/KYC meaning differs across departments
exception handling is inconsistent across branches and digital
collections escalations follow different logic by region
Banking IT does not fail due to lack of capability. It fails because it is built on an incomplete representation of the bank’s architecture.
Until P1–P4 is modelled, IT will continue to automate isolated P5 tasks, not the bank’s enterprise logic.
Q3. What drives the high project count in this industry?
Because every change touches multiple rule layers at once.
Banking bottlenecks:
Risk appetite changes ripple into pricing, limits, and onboarding
Regulatory updates trigger dozens of downstream system modifications
Customer lifecycle rules vary across product lines
Each product requires its own exception-handling logic
High project count is the symptom of deep rule complexity, not poor execution.
Q4. What is unique about this industry’s D1–D15 functions?
Each Bank has a distinctive 15-function anatomy (D1-D15) X P1-P6.
Banking highlights:
D4 Risk - houses heavy scoring and policy engines
D8 Compliance - drives constant regulatory change
D10 Credit Operations - handles exceptions that IT cannot codify
D12 Collections - runs multi-stage rule cycles
These functions generate the strongest P1–P6 drift, making alignment critical.
Q5. What does P1–P6 look like in banking industry?
This explains how strategy (P1) → operations (P6) breaks down.
Banking P1–P6 drift: • P1 Strategy: growth targets, risk appetite, product strategy • P2 Process: onboarding, credit, servicing, collections • P3 Logic: pricing rules, scoring models, limit checks • P4 Components: LOS, CRM, CBS, RPA workflows, rule engines • P5 Implementation: fragmented builds across vendors and teams • P6 Operations: branch, digital, back-office inconsistencies
Misalignment and lack of linking across these perspectives causes the enterprise to behave unpredictably.
Q6. We already have 1,000+ pages of architecture documentation. Why redo this?
Myth: More documentation means we understand the enterprise.
Reality: Documentation shows parts of the bank. Enterprise Anatomy shows the bank as one integrated system.
Think of the human body:
It has 11 organ systems — circulatory, respiratory, nervous, endocrine, immune, digestive, etc. Each system has its own functions, but they are not optional, not interchangeable, and not isolated. They work as one integrated model, with thousands of interdependencies.
No amount of medical paperwork can replace understanding how the body actually works as a single system.
A bank is the same.
A bank’s anatomy = 15 Functions (D1–D15) × 6 Perspectives (P1–P6)
This creates hundreds of functional flows and thousands of decision, data, and rule connections across:
• Strategy (P1) • Process (P2) • Rule / logic cycles (P3) • Component definitions (P4) • Implementation tasks(P5) • Daily operations (P6)
Traditional documentation tries to describe these parts separately — system by system, department by department.
But none of those 1,000+ pages show:
• How decisions actually flow through the bank • Where processes diverge from rules
• Where logic fragments get duplicated • Why departments behave differently for the same customer • Where drift starts and how it spreads
You get a library — not a model.
Enterprise Anatomy collapses complexity into ONE integrated model
Instead of:
• 1,000 pages of descriptions • dozens of process maps • hundreds of system diagrams • unconnected rule documents • inconsistent SOPs • vendor-specific architecture artifacts
You get One Bank One Anatomy™: • One P1–P6 spine • One D1–D15 functional map • One enterprise rule model • One view of strategy → operations • One logic meaning across channels, systems, and departments
This is something documentation can never achieve.
Why documentation must be redone through Enterprise Anatomy
Because today’s documentation:
• describes symptoms, not the enterprise • is project-centric, not anatomy-centric • cannot be used to diagnose drift or misalignment • cannot be used by leadership to guide execution
Enterprise Anatomy gives you:
• one integrated model
• one source of truth
• one way to diagnose
• one way to execute
Exactly the way the human body works — integrated, interdependent, and non-negotiable.
In short:
Documentation shows parts. Enterprise Anatomy shows the enterprise.
That is why even with 1,000+ pages of architecture documentation,you still need One Bank One Anatomy™.
Q7. How do we evolve from EA (IT) → EA (Departments) → One Bank One Anatomy?
Most organisations stop at EA = IT architecture.
The next evolution is:
Step 1: EA (IT)
• Systems, integrations, technology stack
Step 2: EA (Departments)
• 15 functions mapped end-to-end (P1-P6)
• Clear view of Strategy, processes, system logic, component specs, Implementation tasks and Business Operation
Step 3: One Bank One Anatomy™• A single P1–P6 model across the full enterprise • Shared understanding of how decisions flow • Alignment of operations, channels, products, and controls
This is where structural drift stops — and execution accelerates.
Q8. What can One Bank One Anatomy™ do that traditional EA cannot?
Traditional EA focuses on systems, integrations, and documentation. It cannot see that every department in a bank is running its own shadow anatomy — its own version of strategy, process, rules, data checks, and operations.
A medium-size bank typically carries 100–300 shadow anatomies, for example:
• Lending has shadow rules in LOS, CBS, CRM, Collections
• Risk has shadow scoring models across channels and product lines
• Compliance has parallel KYC/AML workflows in 5–7 systems
• Payments has validation logic scattered across gateways and back-office
• Treasury has pricing, limit, and reconciliation rules stored in isolated engines
Traditional EA tries to document these inconsistencies. One Bank One Anatomy™ eliminates them.
What One Bank One Anatomy™ enables
It collapses hundreds of shadow anatomies into one coherent enterprise anatomy across P1–P6:
• One strategy model • One process model (not 27 onboarding variants) • One rule/logic model (pricing, scoring, limits, AML, validations) • One data meaning across all systems • One decision flow from front-office to operations
This unification allows the bank to solve issues that traditional EA has never been able to solve.
How it impacts the 12 Core Banking Use Cases
Using One Bank One Anatomy™, the bank can finally address enterprise-wide failures across use cases such as:
Credit Approval ConsistencyOne interpretation of policy across LOS, branches, digital, and core.
Pricing & Limit DeterminationOne rule engine instead of multiple embedded logic fragments.
KYC / AML DecisioningUnified identity, risk rating, and alert-handling flow.
Customer OnboardingOne P1–P6 model for data capture, rule checks, and document flows.
Payments Straight-Through ProcessingConsistent validations across channels and payment rails.
NPA / Collections StrategyOne logic sequence for bucket movement, triggers, and action flows.
Loan Lifecycle OperationsServicing rules align with onboarding and credit logic — not scattered exceptions.
Product Setup & Variant ControlA single place to define logic, pricing, limits, eligibility.
Regulatory ReportingOne meaning for each data element, not 12 interpretations.
Risk Scoring & Exposure ManagementOne scoring logic across channel, product, and workflow variations.
Treasury & Liquidity OperationsUnified availability, limit checks, and exception rules.
Customer Experience AlignmentSame decision logic across branch, mobile, web, partner journeys.
With One Bank One Anatomy™, every one of these use cases becomes predictable, coherent, and improvable — because they all run on a single enterprise logic stack.
Why traditional EA cannot achieve this
Traditional EA cannot unify:
• departmental rule cycles• decision logic fragmentation• process deviations• inconsistent data definitions• buried exceptions in RPA, SQL, workflow, and operator SOPs
• compliance logic scattered across case-management and core systems
It documents the drift — but cannot remove it.
One Bank One Anatomy™ removes the drift by replacing 100–300 shadow anatomies with one shared enterprise anatomy, readable by leadership and executable by teams.
If EA remains limited to IT, the enterprise continues to drift—department by department, rule by rule, process by process.
A bank regains coherence only when its entire P1–P6 structure is mapped as one integrated anatomy.
Write to us if you’d like a diagnostic walk-through of how this works in your environment.
