The Core’s Original Sin
There is no way to say with confidence which of those records belong to the same person. Many early systems are based on account numbers, and not designed to answer what the bank knows about a customer. To say with confidence that records in dozens of different systems belong to the same customer is a mental leap made best by engineers who are on the verge of retirement who know the system itself, and the technical fix is a colossal engineering challenge.
Was this email forwarded to you? Subscribe here.
This design foundation, built on technology and software that is its own problem, has created the tightly wound, “brittle” systems that the average bank is reluctant or unable to touch. A CIO probably won’t be fired for a status quo that preserves a conservatively run business. But they would certainly be fired for signing off on a decision that had a devastating domino effect on the bank’s critical functions. The exit ramp is systemically and personally perilous, and prone to half-measures.
The exponential problem
That’s five databases. What’s missing? Card processing, loan origination, CRM, bill pay, Zelle, contact center, fraud systems, document management, document imaging, wires, compliance, marketing platforms? There are probably dozens.

Note: Representative at a very small scale. Image: Claude
There isn’t a one-click solution to the database problem, even with a COBOL translator or an AI agent at your fingertips.
The half-measure solution
Necessary half-measures may include the years-long implementation of a middleware-type solution (connecting systems) or the painful and prolonged process of hollowing out the core (decomposing and replacing functions piece by piece). The dream of internal behavioral, transactional, and customer profile data is more of a hack than a reality when new vendors sit in their own siloes on top of the tightly wound system that’s already in place, and depend on or are isolated from other systems. They are another patch on an old quilt.
The basic anatomy of a mind-warping mess
It takes just a few truncated, simulated tables to see how the buildup happened, and got worse over time. The core was designed to track money, not people: The deposit ledger is keyed on account number. The account record points to the customer information file. That was fine for a bank that only offered deposit accounts, and only through a branch. If the customer data didn’t match on account opening and a safeguard wasn’t in place, the core created a duplicate record on account opening.

The deposit ledger (and seemingly why buying a branch network includes the purchase of deposits). Image: Claude.
Database hell begins. The original “source of truth” becomes the source of just “something,” complicated and obfuscating the picture of a customer that didn’t exist to begin with.

The customer information file, which links back to the deposit ledger with the customer information number. Consistency is not guaranteed. Image: Claude.
The ACH system is keyed on account number, which links back to the deposit account ledger, which links back to the customer information file. Enter a new, linear, clearly connected series of dependencies.

The ACH system, which links back to the deposit ledger, which links back to the customer information file. Image: Claude.
Fast-forward to the digital banking platform. There was a day, which may still be today, when after you opened an account you had to key in your account number and some identifying information before you set up your digital banking account. Once the account was linked to digital banking, much that was linked to the account could be resolved to digital banking. The digital banking platform resolves to a user ID, and contains event types, event detail, channel, and details about the session.

The digital banking system is closer to the customer (via user ID) but can do little to solve the account-first record keeping system. Image: Claude.

The bill pay system links back to at least a few systems. Image: Claude.
The bill pay system resolves to the digital banking user ID and has its own key assigned by the bill pay vendor’s system. That information may appear in the account ledger in its own tab. The data is probably reflected in the account ledger as a check or ACH direct debit.
Despair is not the only destination
In a perfect world, of unified data across the bank, what would it look like? A customer graph. A graph would sit on top of every data source a bank could access and make them work together as one: One place where everything the bank knows about a customer is connected, resolvable, and accessible in natural language.
The “customer 360” is a buzzword in search of a solution that isn’t just a data dumping ground. For a unified view, a bank needs infrastructure built from the ground up. And that may mean building a new bank altogether.
Thanks for reading today’s issue of Fintech Notebook. Deep thinking and color commentary on the present and future of fintech by Tyler Brown.
Reach out to me by replying to this email, connecting on LinkedIn, or visiting my website @ tylerbrown.co.
AI assisted research, image generation, and editing for this article.
