From Core Banking to Lakehouse: A Modern Banking Data Architecture with ODS and the Medallion Architecture

In a post shared in the Data Architecture Community group on 03/11/2026, author Data Engineer Kỹ sư dữ liệu (@cole.dataengineer) laid out a data architecture roadmap for banks across five diagrams: from a Core Banking overview and its transaction channels, through the OLTP–OLAP processing model and the traditional data warehouse architecture, to a modern design that combines an ODS with a Lakehouse organized by the Medallion Architecture (Bronze – Silver – Gold) on top of Apache Spark, Iceberg, Trino, Airflow, Kafka and MinIO/S3. This article reorganizes that material layer by layer.

Quick answer

• Every banking transaction — Mobile Banking, ATM/POS, branch teller — flows into Core Banking through a Payment Hub and a Card Switch, generating a large, continuous and diverse stream of data. This is the original data source for every analytics system downstream.
• OLTP and OLAP have opposite goals but complement each other. OLTP records the current state of the business with short, precise transactions; OLAP reads aggregated historical data for analysis and decision-making.
• The traditional architecture (ODS → ETL → Data Warehouse → Data Mart → BI) works well for batch reporting but struggles with real-time needs. Data is copied through many layers, mostly on Oracle, IBM DB2, SQL Server and SAP platforms.
• The modern architecture keeps an ODS for real-time operations and adds a Lakehouse for analytics. The Lakehouse uses the open Apache Iceberg table format on S3 object storage and organizes data with the Medallion Architecture in three layers: Bronze, Silver and Gold.
• The six core Lakehouse technologies in the diagrams are Apache Spark, Apache Iceberg, Trino, Apache Airflow, Apache Kafka and MinIO/S3. Each plays exactly one role: compute, table format, query, orchestration, streaming and storage.

What is a Lakehouse?

A Lakehouse is a data platform architecture that combines the strengths of a data lake (cheap, flexible storage on object storage) with the governance of a data warehouse (ACID transactions, schema management, high-performance analytical queries). In the original post's architecture, the Lakehouse does not replace everything that exists: it sits next to an ODS (Operational Data Store) that serves real-time operations, while the Lakehouse itself handles large-scale storage and analytics for reporting, risk analysis, transaction monitoring and AI/ML applications.

What is the Medallion Architecture?

The Medallion Architecture organizes Lakehouse data into three layers of increasing quality. The Bronze layer (Raw/Landing Zone) keeps source data exactly as received, unmodified, including CDC and streaming data. The Silver layer (Cleaned & Conformed) holds data that has been cleaned, deduplicated and standardized. The Gold layer (Curated) is the highest tier: business data models and aggregated data marts, optimized for BI with high data quality. This layering makes every transformation traceable and lets each user group work with the layer that fits their needs.

Which channels generate banking data?

According to the overview diagram at the top of this article, data starts from three transaction channels: Mobile/Internet Banking, ATM/POS (card transactions) and the branch Teller (cash deposits/withdrawals, internal transfers). Transactions are routed through two intermediary layers — a Payment Hub (with a Fraud/Rules Engine, NAPAS/SWIFT connectivity and the ISO 20022 standard) and a Card Switch (ISO 8583 standard, connecting Visa/Mastercard/NAPAS) — before reaching Core Banking, which manages accounts and balances, the accounting Ledger and reconciliation, with mandatory requirements of Realtime Posting, ACID Transactions and Data Integrity. Around this core sit external systems (NAPAS, SWIFT, Visa/Mastercard, merchant partners) and support systems (CRM/Customer 360, KYC/eKYC, AML/CDD, Notification, Reporting/MIS, Data Warehouse), all on an infrastructure of high availability, disaster recovery, encryption, access control and monitoring/alerting.

How does the foundational data processing model work?

The author's second diagram describes the root layer of every data architecture: the real world of customers and activities (purchases, money transfers, deliveries, production) is recorded by business systems — Web/Mobile App, Core Banking, Order Management, CRM, Inventory — into an OLTP database. OLTP stores the current state of the business as normalized relational tables (customer, account, transaction, branch, employee), guarantees ACID and supports many concurrent users. As the author notes in the diagram: before Big Data, AI or Lakehouse existed, a business only needed a way to record what was happening — and OLTP is exactly that.

How do OLTP and OLAP differ?

Criterion	OLTP (operations)	OLAP (analytics)
Purpose	Running systems: fast, accurate transaction processing	Decision-making: analysis, aggregation, reporting
Data	Current, detailed, short and simple transactions	Historical, aggregated, complex queries
Data changes	Frequent: continuous inserts/updates/deletes	Rare: mostly reads, occasional appends
Data model	Normalized (3NF)	Dimensional model / Star Schema
Performance optimized for	Fast writes, concurrent transactions	Fast reads over very large volumes

Between the two systems sits a data foundation with three storage layers (raw data, integrated data, curated data) plus Data Governance covering quality, security, compliance and lineage. The relationship is one-directional and clear: OLTP is the data source; data is collected and stored, organized and prepared, and OLAP extracts the value from it.

What layers does the traditional enterprise data architecture have?

The third diagram describes the architecture that was standard at banks and large enterprises for many years: sources (Core Banking on Oracle, card systems on IBM DB2, electronic channels on SQL Server, HR/Finance/GL systems and external feeds) are loaded into ODS/Staging, pass through an ETL layer (Oracle Data Integrator, IBM InfoSphere DataStage, Microsoft SSIS, SAP Data Services) that extracts, transforms and loads them into a central Data Warehouse (EDW). From the EDW, data is distributed into subject-area Data Marts — retail banking, risk, finance, compliance — and finally reaches the BI/Reporting layer (Oracle BI, Power BI, IBM Cognos, Excel) serving managers, analysts and auditors. This architecture is stable and proven, but the entire flow is batch-based on fixed ETL schedules, data is copied across many expensive storage layers, and it offers almost no real-time analytics capability.

How is the modern ODS + Lakehouse architecture organized?

The fourth diagram is the target architecture the author proposes, with these main blocks from left to right:

• Data sources: Core Banking (transactions, accounts, customers, loans), card systems (authorizations, transactions, settlements, chargebacks), third parties (credit bureau, KYC/AML, payment gateways), mobile apps (clickstream, events, behavior) and logs/files.
• Ingestion & Orchestration: Apache Airflow orchestrates DAGs with monitoring, retries and alerts; batch ingestion uses Apache Spark with ELT; streaming ingestion uses Apache Kafka, GoldenGate and Debezium with CDC (Change Data Capture).
• Real-time ODS: Oracle Exadata or SingleStore for high ingest throughput, ACID transactions and low latency, plus an API Hub/Service Layer exposing standardized APIs for operational apps, real-time dashboards and operational reports.
• Lakehouse: S3-compatible storage on-premise or on Dell ECS, using Apache Iceberg as the table format (ACID, Schema Evolution, Time Travel, Hidden Partitioning), a Hive Metastore or Gravitino catalog, the Medallion Architecture for organization, and Apache Spark (batch) plus Apache Flink (streaming) for compute.
• Query & Serving: Trino with the Iceberg Connector and Apache Doris (MPP OLAP, Materialized Views) serve dashboards, reports and ad-hoc analytics for user groups from Data Analysts and Data Scientists to regulators.
• Platform operations: monitoring with Prometheus, Grafana, Alertmanager, Loki and OpenTelemetry on Kubernetes; Kerberos and LDAP/Active Directory authentication; Apache Ranger authorization; Apache Atlas governance and catalog (metadata, lineage, data classification).

What are the six core Lakehouse technologies?

Technology	Role	Key capabilities per the original post
Apache Spark	Compute Engine	Large-scale batch and streaming data processing
Apache Iceberg	Open Table Format	ACID transactions, Time Travel, Schema Evolution, Hidden Partitioning
Trino / Presto	Query Engine	Fast, interactive SQL queries across every data source
Apache Airflow	Orchestration	Pipeline scheduling and coordination, monitoring, retries, alerts
Apache Kafka	Streaming Platform	Events, logs, message broker for real-time ingestion
MinIO / S3	Object Storage	Durable table storage, S3-compatible, low cost

How do the traditional and the ODS + Lakehouse architectures compare?

Criterion	Traditional (EDW)	Modern (ODS + Lakehouse)
Storage	Closed relational systems (Oracle, DB2), high cost per capacity	S3-compatible object storage, open Iceberg table format
Data ingestion	Batch ETL on fixed schedules	Batch plus real-time streaming/CDC (Kafka, Debezium)
Data latency	Hours to days	Seconds to minutes in both the ODS and the Lakehouse
Data organization	Subject-area Data Marts right from the EDW	Medallion: raw Bronze, clean Silver, curated Gold
Query serving	Mainly BI/Reporting	BI, ad-hoc analytics, transaction monitoring, AI/ML
Scaling	Specialized hardware upgrades	Storage and compute separated, each scales independently

What value does a Lakehouse bring to a bank?

According to the author, the core value is a single unified data platform instead of many disconnected data stores: the same stream of transaction data both serves real-time operations through the ODS and is standardized in the Lakehouse for management reporting, risk analysis, transaction monitoring and anomaly detection, and progressively for AI/ML applications. In other words, a Lakehouse is not merely a storage solution — it is the platform that helps a bank move from operating on data to extracting business value from data.

Frequently asked questions

How does a Lakehouse differ from a traditional Data Warehouse?

A traditional Data Warehouse stores data in a closed relational system, requires schema definition and transformation before loading (ETL), and has high storage costs. A Lakehouse stores data on cheap object storage with an open table format such as Apache Iceberg, still provides ACID and schema management like a warehouse, ingests both batch and streaming data, and serves both BI and AI/ML.

Why does the modern architecture keep an ODS instead of using only a Lakehouse?

The ODS serves operational needs that demand extremely low latency and ACID transactions on the freshest data: operational applications, real-time dashboards and alerts. The Lakehouse is optimized for large-scale storage and analytics. Keeping both lets each workload use the right tool instead of forcing one system to do everything.

Can Bronze-layer data be corrected when an error is found?

No. Under the Medallion model in the original post, Bronze is the immutable raw zone that keeps data exactly as it arrived from the source, including CDC and streaming data. Cleaning, deduplication and standardization happen in the Silver layer, and business-ready results live in Gold — so every transformation can be traced and replayed.

How is Apache Iceberg better than plain file formats?

Iceberg is a table format, not just a file format: it brings ACID transactions on object storage, Schema Evolution without rewriting data, Time Travel to query past versions of the data, and Hidden Partitioning so users do not have to manage partition directories manually in queries.

Does a bank have to abandon its existing Oracle/DB2 systems to move to a Lakehouse?

No. The architecture in the original post is on-premise and designed for integration: source systems such as Core Banking on Oracle or card systems on IBM DB2 keep running as they are, and data is moved across via batch and CDC. Even in the modern architecture, the ODS can still run on Oracle Exadata. It is a step-by-step evolution, not a wholesale replacement.

Original source

This article was compiled and reorganized from the post by Data Engineer Kỹ sư dữ liệu (@cole.dataengineer) shared in the Data Architecture Community group on Facebook on 03/11/2026: original Facebook post. All five diagrams from the original post's album are included in this article; the architectural content and technology choices are the professional views of the original author.