Data warehouse (DWH) projects in banking are among the enterprise's most critical investments: regulatory reports, risk calculations, customer 360 and performance analytics all feed from this layer. Yet most project failures stem from missing architectural discipline, not technology choice. Five critical decisions distilled from large-scale banking DWH practice.
1. Source-System Integration: Batch or CDC?
The classic overnight batch from core banking into the DWH is still common. But as regulators push reporting frequency below the daily level (BDDK does so for certain report types), CDC (Change Data Capture) integrations have become mandatory. Debezium/Kafka-based solutions stream changes without impacting core-system performance.
2. Historical Modelling: SCD Type 2 Is Not Everywhere
Slowly Changing Dimension Type 2 (historical preservation) is not required for every dimension. Type 2 is essential for customer address changes; Type 1 (overwrite) is enough for product categories. Over-using Type 2 inflates storage 3-4× and degrades query performance. Every dimension deserves a business-driven decision.
3. Separating Regulatory and Analytical Reporting
For BDDK, TCMB and MASAK reports, data must be immutable: the same report must be reproducible a year later with the same parameters. The regulatory layer has to be isolated from the analytical layer. Our recommended pattern is to keep a regulatory snapshot version of fact tables alongside the analytics current version.
4. Performance: Partitioning and Clustered Columnstore
On SQL Server and Azure Synapse-based DWHs, date partitioning combined with clustered columnstore indexes can reduce query time by up to 90%, especially on fact tables with 50M+ rows. If this configuration is not put in place at the start, retrofitting requires heavy reloads and downtime.
5. Permissions and Access: RLS and Data Masking
Sensitive data such as customer tax IDs and account balances has to live in the DWH — but not every developer or analyst should see it. For KVKK compliance, row-level security (a branch manager sees only their branch's customers) and column-level masking (an analyst sees tax IDs as a hash) must both be in place simultaneously.
