How to build a Conceptual Data Model for Financial Services Institutions?

Abstract

Financial services institutions, particularly banks, rely on robust data management frameworks to support operational efficiency, regulatory compliance, and customer experience. The conceptual data model (CDM) provides a high-level, technology-agnostic representation of business data entities and their relationships, enabling alignment between business stakeholders and technical teams. This paper presents a structured approach to building a CDM for banking organizations. It reviews relevant literature, identifies core banking entities, and proposes a methodology for developing, governing, and applying a CDM within financial institutions. The paper further demonstrates practical use cases such as customer 360 views, compliance reporting, and open banking integration.

1. Introduction

Banks operate in a data-intensive environment characterized by diverse products, complex transactions, and stringent regulatory requirements. Misalignment between business objectives and technical implementations often leads to inefficiencies, duplicated data, and compliance risks. A conceptual data model bridges this gap by capturing the essential business semantics of data while abstracting away technical details. This research explores a framework for developing a CDM specifically tailored to the banking sector.

2. Literature Review

Several industry frameworks provide guidance on financial data modeling:
– DAMA-DMBOK emphasizes data governance, ownership, and standardization.
– TOGAF defines enterprise architecture practices that include conceptual modeling within the Business and Data Architecture phases.
– IBM Banking Industry Data Model (BIDM) and Financial Services Data Model (FSDM) provide domain-specific data models for banking.
– Academic research highlights the role of conceptual models in reducing system integration challenges and enhancing compliance reporting.

3. Methodology for Building a Conceptual Data Model

3.1 Requirement Gathering

Requirement gathering involves identifying business capabilities (retail banking, corporate banking, treasury, Risk, Finance, Operations, ..etc.), capturing regulatory drivers (BSBC 239, DAMA, NDMO, Basel III, IFRS9), and collecting stakeholder needs from business units, Data Teams and IT teams.

3.1.1 Work Package 1: Identify Business Functions

3.1.1.1 Objective

Define the organizational scope by decomposing the institution into its core business areas.

3.1.1.2 Activities

• Review organizational structure, capability maps, and strategic plans.
• Identify major business functions (e.g., Retail Banking, Corporate Banking, Treasury, Operations, HR,Risk & Compliance .. etc).
• Define scope boundaries (in/out of CDM).

3.1.1.3 Artifacts

List of prioritized business functions (Retail Banking, Corporate Banking, Treasury, Risk Management, IT, Operations, Customer Service, etc.).

3.1.2 Work Package 2: Identify Key Stakeholders per Business Function

3.1.2.1 Objective

Map stakeholders who own or consume data in each function.

3.1.2.2 Activities

• Identify Business Owners (e.g., Head of Retail Banking, Risk Analysts, Product Managers, Customer’s Segment Manager).
• Identify Operational Users (e.g., Branch Managers, Loan Processors/Officers, Relationship Managers).
• Identify Data Stakeholders (Data Stewards, Application Team/Support, Data Custodians, IT Architects).

3.1.2.3 artifacts

• Stakeholder Matrix (function vs. roles).
• Ownership and accountability map for data domains.

3.1.3 Work Package 3: Identify Key Data-Driven Processes

3.1.3.1 Objective

Understand critical processes that rely on data to operate or report.

3.1.3.2 Activities

• Map end-to-end business processes (e.g., Customer Onboarding, Loan Origination, Payment Processing, Risk Reporting).
• Identify data touchpoints (systems, handoffs, reporting).
• Highlight processes subject to regulatory compliance (Fraud monitoring, IFRS9 impairment calculations).

3.1.3.3 artifacts

• List of data-driven processes with descriptions.
• Mapping of business processes → required data assets.

3.1.4 Work Package 4: Plan & Execute Elicitation Sessions

3.1.4.1 Objective

Gather detailed information about data entities, attributes, and business rules.

3.1.4.2 Activities

• Elicitation Techniques:
  • Workshops with business users.
  • One-on-one interviews with SMEs.
  • Document analysis (existing reports, regulatory submissions).
  • Shadowing (observing real processes).
• Develop elicitation questions:
  • What are your key reports?
  • Which data entities are reused across processes?
  • What are the relationship between these data entities?
• Capture candidate data entities and attributes (e.g., Customer → Name, ID, Risk Rating; Account → Type, Balance, Status).

3.1.4.3 artifacts

1. Workshop summaries, stakeholder inputs, pending actions, documentation collection and follow-up feedback emails.
2. Preliminary list of data entities & main identifying attributes.

3.1.5 Work Package 5: Define & Validate Main Data Assets

3.1.5.1 Objective

Consolidate findings into draft conceptual entities and confirm with stakeholders.

3.1.5.2 Activities

• Consolidate workshop results into entity definitions.
• Identify main identifying attributes (business keys).
• Identify & document key business rules & constrains.
• Validate relationships (e.g., “Customer owns Account” = One-to-Many).
• Present initial model to stakeholders for refinement.

3.1.5.3 artifacts

• Draft Conceptual Entity List (Customer, Account, Transaction, Product, Channel, etc.).
• Draft Entity-Relationship View (diagram) with key attributes.
• Validation sign-off from stakeholders and project sponsor for contracted architecture projects.

3.1.6 Work Package 6: Establish Traceability & Governance

3.1.6.1 Objective

Ensure sustainability, maintainability and alignment with enterprise data management.

3.1.6.2 Activities

• Map entities to business functions and stakeholders.
• Record data ownership and stewardship.
• Build traceability matrix from business processes → data entities → key attributes.

3.1.6.3 Deliverables

• Governance RACI for data entities.
• Traceability matrix.

3.2 Identification of Core Entities

The following entities represent the backbone of a banking CDM:

• Customer/Party: Individuals, organizations, regulators.
• Account: Savings, loans, investment accounts.
• Product & Service: Mortgage, credit cards, insurance.
• Transaction: Payments, transfers, deposits.
• Channel: Branch, online, ATM, mobile.
• Risk & Compliance Entities: Credit score, Credit Applications, Credit Lines.

3.3 Defining Relationships

• Customer ↔ Account: One-to-many, supporting joint ownership.
• Account ↔ Transaction: One-to-many, enforcing integrity of financial records.
• Product ↔ Service: Hierarchical, capturing business offerings.

3.4 Model Visualization

Develop an Entity-Relationship Diagram (ERD) showing high-level entities and cardinalities. The model is business-centric and avoids database-specific details.

3.4.1 Using The IE Notation

An IE notation (Information Engineering) conceptual data model is often used to capture high-level business entities, relationships, and cardinalities before moving into logical/physical data models.

Example of a conceptual data model on a hotel reservation information system database

3.4.2 Using The Anchor Notation

You may get more details about Anchor modelling from https://www.anchormodeling.com/

3.5 Validation & Governance

Engage stakeholders through workshops to validate definitions. Establish ownership for each data domain (e.g., customer data steward, product data steward). 

4. Conclusion

A conceptual data model is essential for bridging the gap between business goals and data implementations in banking organizations. Future research may extend this work by mapping CDM constructs into logical and physical data models.

Appendix A: Conceptual ERD Diagram

The following figure illustrates a high-level conceptual data model for a banking organization. It highlights the key business entities and their primary relationships.

Appendix B: Timeline Overview