As bankers, there is one concept we understand instinctively: Custody.
We would never build a state-of-the-art physical vault, install three feet of reinforced steel, and then instruct the tellers to simply shovel cash, gold bars, loan contracts, and safety deposit keys into a giant, mixed pile in the center of the room.
We know that security without organization is useless. If a client asks for their assets, and we have to dig through a mountain of mixed items to find them, we have failed.
Yet, this is exactly what happens when banks build a “Data Lake” without first designing the “Logical Structure.”
The Data Swamp
In the tech world, vendors will often sell the dream: “Ingest everything now and figure it out later.” They sell the Data Lake as a massive, bottomless reservoir.
The problem? If you pour water from 50 different rivers (ATM systems, mobile apps, loan processing, trading desks) into one lake without filtration or separation, you don’t get a pristine reserve of water. You get a swamp. It becomes murky, toxic, and expensive to clean.
To get value from data, we must stop treating it like a byproduct of IT systems and start treating it like a bankable asset.
Logical Structure First
In banking, we often confuse storage with strategy. We think that if we buy a big enough container (the technology), the data will manage itself.
This is false. Storage is just a container. Structure is the intelligence.
To understand why, let’s look at a simple example that has nothing to do with banking: The Supermarket.
Building a Supermarket
Imagine you are the CEO of a major grocery chain. You have thousands of products arriving daily: milk, bread, cleaning spray, magazines, fresh fish. You have two ways to organize your store:
Option A: The “Dump” Approach You build a massive, expensive warehouse. You tell the delivery trucks to back up to the loading dock and dump everything into the center of the room.
- The Result: You have a mountain of mixed goods. The milk is leaking onto the magazines. The fish is rotting next to the bleach.
- The Customer Experience: A customer walks in asking for “Breakfast.” You have to dig through the pile for 3 hours to find a box of cereal. By the time you find it, the customer has left.
- The Business Impact: You have all the assets (the products), but you have zero value. You cannot sell what you cannot find.
Option B: The “Logical Structure” Approach Before you let a single delivery truck arrive, you draw a map. You don’t focus on the building (the technology); you focus on the categories (the logic).
- Define the Categories: “We need a Dairy section. We need a Bakery. We need Household Goods.”
- Define the Relationships: “Chips should go next to the Salsa because people buy them together.”
- Stock the Shelves: Now, when the trucks arrive, the milk goes straight to the fridge in Aisle 1. The bread goes to Aisle 2.
The Banking Translation In this analogy:
- The Building is your Cloud/Data Lake.
- The Products are your Data (Transactions, KYC forms, Loan Contracts).
- The Aisles are your Logical Structure.
If you don’t build the aisles first, your Data Lake becomes that rot-filled warehouse in Option A.
Why This Matters for the P&L
When we organize by Logical Structure instead of by IT System, we gain three massive advantages:
- Speed: We don’t have to search the whole warehouse. If we need “Customer Addresses,” we go straight to Aisle 1 (Party).
- Accuracy: We don’t have duplicate milk cartons spoiling in different corners. We have one source of truth for “Customer Name.”
- Cross-Selling: Just like putting salsa next to chips, we can easily see connections. “Oh, this customer is in Aisle 2 for a Mortgage… let’s offer them Home Insurance from Aisle 2 as well.”
Technology (The Lake) is just the floor space. Logic (The Structure) is how you make money.
How We Apply This to Banking — Domains
We stop asking “Which IT system is this data from?” and start asking “Which business aisle does this belong to?”
We organize our bank into 4 Logical Aisles:
Aisle 1: The Party Domain (Who)
- Supermarket equivalent: The Shopper.
- Banking reality: Whether they are a borrower, a saver, or a guarantor, they are a Party. We store all human data here.
Aisle 2: The Agreement Domain (What)
- Supermarket equivalent: The Product Catalog.
- Banking reality: A Mortgage, a Credit Card, and a Savings Account are all Agreements. They all have terms, limits, and dates. We store all contracts here.
Aisle 3: The Event Domain (When)
- Supermarket equivalent: The Checkout Scan.
- Banking reality: A payment, a login, a fee charge, or a phone call. These are Meaningful Events that happen at a specific time.
Aisle 4: The Location/Asset Domain (Where)
- Supermarket equivalent: The Store Branch or Shelf Number.
- Banking reality: The Branch ID, the Mobile App version, or the Physical Property securing a loan. Basically the Where and the What that secures the deal.
How to Read the Map
If we build the structure correctly, we can form complete sentences about our business simply by connecting the domains.
[Party] executes an [Event] on an [Agreement] via a [Location] or simply: [Who] did [What] via [Which Channel] regarding [Which Product]?
An example: Mr. Smith (Party) made a $500 Deposit (Event) into his Savings Account (Agreement) at Branch 402 (Location).
If we just dump data into a Lake, we break the sentence. We lose the story.
The Governance Rule: Pipes vs. Water
This brings us to the hardest part: Ownership. Who is responsible when data is wrong? The usual answer is “IT.” This is the single biggest mistake in data strategy.
To fix ownership, we must draw a hard line between Technology and Business.
- IT Owns the Pipes. They are responsible for ensuring the systems are up, the security is tight, and the data moves from Point A to Point B without leaking.
- Business Owns the Water. They are responsible for what flows through those pipes. If the water (data) is muddy (inaccurate), it is not the plumber’s fault.
The Golden Rule of Data Ownership — The Owner is the person who has the authority to change the definition of the data, and the person who suffers the most if the data is wrong.
The Conflict Resolution Scenario
The Issue: The Risk Department complains that “Employment Income” data is missing for 40% of customers. The IT Trap: The CIO says, “The database is working fine; the field is just empty.” The meeting ends in frustration. The Ownership Solution:
- We look at the Party Domain. The Owner is the Head of Retail.
- The Head of Retail investigates and realizes their branch staff are skipping that field because it takes too long to type during the account opening process.
- The Fix: The Head of Retail updates the front-end process to make the field mandatory or changes the staff incentive. This sounds simple, but it requires political will. It requires the Board to back the Data Owner over the Sales target in the short term.
- The Result: IT didn’t write a line of code. Business changed a process. The data improved.
Once we have clear ownership (Pipes vs. Water), we need to change the scoreboard. We cannot measure success by ‘uptime’; we must measure it by ‘usability’.
Key Quality Indicators
Now, typically, this is the part of the article where a Chief Data Officer passionately pulls out a 50-row spreadsheet of “Key Quality Indicators” (KQIs) and teaches you how to calculate standard deviation on null values.
I know you are devastated that I’m skipping that thrill.
But let’s be honest: asking a banker to digest “Data Architecture” and “Governance Metrics” in one sitting is a violation of the Geneva Convention. You have suffered enough logic for one day.
So, out of mercy, I am saving the “How to Measure Success” guide — complete with traffic-light dashboards and scary acronyms — for my next post. Stay tuned.
The Bottom Line
We cannot “buy” our way out of complexity with a Data Lake. We must “think” our way out of it with Logical Structure. When we prioritize structure over storage, we stop hoarding digital noise and start building a digital vault.
