ON DEMAND: What It Actually Takes to Build a Data Foundation

Do you know who your top 50 clients are, right now? Within 5 minutes? An hour? The answer, and how long it takes to get one, says more about your data maturity than any technology you have bought.

That question was the starting point for a conversation on August 12, 2026, when KlariVis founder and CEO Kim Snyder sat down with John Kowal, Chief Technology Officer at Peapack Private Bank & Trust, and Marcos Souza, KlariVis’ Chief Data & Analytics Officer. Together they worked through what it actually takes to build a data foundation, and why that foundation has to come before any AI ambition a bank holds.

The full recording is below. Read on to dive into what they discussed:

 

A Four-Year Build, and the Problem That Started It

John opened with the story behind Peapack Private’s data warehouse. The bank runs on three separate core platforms, a bank core, a wealth core, and a leasing core, which meant client data was scattered before it ever had a chance to tell a coherent story. Getting a true 360-degree view of a relationship required getting those systems to talk to each other, along with the data sitting in spreadsheets and, in the worst cases, in the heads of one or two employees.

Speed was the other driver. Monthly and weekly reports could not keep pace with how quickly money moves today. John pointed to a digital bank that gathered more than $7 billion in deposits in its first year as evidence of how fast client behavior can shift, and argued that pace will only accelerate with AI and digital currency in the mix. When a report arrives a week or a month after the fact, the money has often already moved, and that lag has become a real source of risk.

Four years in, the warehouse now pulls from more than 27 different sources, and John was clear that the number keeps growing. A data foundation is closer to an operating discipline the bank keeps up than a project with a finish line.

 

Why You Can’t Leapfrog Straight to AI

Marcos brought a career’s worth of pattern recognition to the question of why so many AI efforts stall. Across stops at Bank of America, Ally Bank, and the telecom world, his job title changed but the underlying work never did: turn raw data into something some one can act on.

His read on AI failures is blunt. When an AI program fails, truly, the model is rarely the problem. The data underneath it was never properly built, and that is what breaks the effort. He pointed to the widely cited MIT finding that a large share of enterprise AI pilots fail, with data quality as a leading cause, and argued community banks are living the same pattern at smaller scale.

John’s version of the same point came from experience running AI tools that touch Peapack’s data warehouse daily, including a new loan review process and compliance monitoring, along with a meeting-prep tool for client-facing teams. His conclusion was that AI exposes whatever weaknesses already live in the data. A client record with a birthdate of January 1, 1900, a default value from a system field nobody filled in, will happily produce a 126-year-old customer if nobody corrects it. The remedy lives in the data itself.

Kim connected both points back to KlariVis’ research with Cornerstone Advisors on data EQ, and to Ron Shevlin’s framing that there is no AI strategy without a data strategy.

 

Starting Simple

One of the more practical exchanges was about how to actually get moving. Kim pushed back on a pattern she hears constantly in conversations with bank leaders, the belief that nothing can start until the data is clean. Her point was direct. If you wait for clean data before you begin, you will never begin, because building the processes and governance around your data is part of the work itself.

John’s own build reinforced that. Peapack Private started on traditional Microsoft SQL, deliberately keeping the early architecture simple rather than reaching for a more complex platform out of the gate. His advice: don’t shop for a fishing boat and come home with a yacht. A more sophisticated platform only helps if the team has the expertise to run it once the implementation team leaves.

He was equally direct about what building actually requires long term: database engineers, pipeline management, an ETL function, a QA function. None of that disappears once the initial build is done, and underestimating the long-term maintenance cost is where these projects most often go wrong. That reality does not scale down the same way to a smaller community bank. A dedicated, banking-literate data analyst is a genuinely hard role to fill, and hiring only one person to own it introduces real key-person risk. This is precisely where a partner earns its place, handling the economies of scale a smaller institution cannot practically build in-house.

 

What Governed AI Actually Looks Like

John shared the story of Project Atlas, an internal AI tool that can answer natural-language questions against Peapack’s data warehouse, such as identifying top-performing bankers by client growth in a specific market, without any follow-up prompting. The effect on the bank’s culture was immediate. When answers become cheap, people start asking more questions, and that is how a bank becomes genuinely data-driven.

But John framed Atlas as the final step of a long process, arriving only after the groundwork underneath it was done. The tool works because of exhaustive documentation underneath it. AI has no tolerance for ambiguity. If a client has both a personal relationship manager and a business banker, a person can pick up the phone and work out who really owns the relationship, while AI has to be given that answer up front. Every term a bank uses in a board meeting, a “commercial loan,” a “lead relationship manager,” has to be translated into an exact, unambiguous definition in the data before AI can be trusted to work with it.

On governance, John pointed to a real event. One of the first SEC filings disclosing a data breach tied to improper AI use came out of community banking, when an employee uploaded sensitive client information to an unauthorized AI tool while preparing a presentation. His takeaway was to apply the same vendor-management fundamentals banks already use for cloud email and file storage. That means working with credible providers and signing enterprise agreements a legal team can actually review and redline, while steering clear of consumer or small-business AI tiers that lack real data protection. Refusing to offer any sanctioned AI tools at all creates its own risk, since employees will simply turn to personal tools with corporate data if nothing else is available.

 

The ROI Case

Marcos framed return on investment as starting with the client relationship. Catching a churn signal 60 to 90 days before a relationship walks out the door has a real dollar value, and so does the operational and regulatory efficiency that comes with better-governed data, an area that has already reshaped how larger banks manage everything from capital reserves and loss forecasting to PII exposure, and one that keeps moving down-market.

John’s version was concrete. Real-time visibility into a bank’s loan portfolio let one CFO catch and correct underpriced loans the same day they were booked, rather than discovering the pattern at month end. Kim shared a related result from a KlariVis client that achieved a 50 basis point improvement in commercial loan yields through that kind of daily visibility and in-the-moment coaching, the kind of gain that compounds meaningfully over a year of lending activity. Visibility changes behavior in other ways too. One CFO told Kim that everyone at her bank knew they had a top performer, but nobody grasped the scale of it until performance became visible to the whole organization, which in turn lifted the team around him.

 

What Becomes Possible When Data Is Connected Across Banks

Marcos closed with a story from his time at Bank of America, where the bank used its own credit and debit transaction data, categorized to match U.S. Census Bureau sector definitions, to produce an accurate picture of the national economy within a day of month-end, months ahead of the Bureau’s own published revisions. The lesson he carried into community banking is straightforward. A single institution’s data tells you what happened inside your own walls, while data compared across a network of similar institutions tells you what to do next.

That is the thinking behind the consortium approach KlariVis is building, where anonymized data from across the client base can surface benchmarks no single community bank could produce alone, such as what share of a bank’s customers are living paycheck to paycheck relative to peers of a similar size and profile. A raw number in isolation says little, but the same number set against the market becomes something a bank can act on.

 

Takeaways for Every Community Bank Leader

Both panelists closed with practical advice for leadership to carry back to their teams.

Judge data maturity by the questions your organization can answer, since that says more than any technology on the balance sheet. Ask tomorrow morning who your top 50 relationships are, what products they hold, and which are growing or at risk of leaving, then pay attention to how much effort that answer took to produce.

Fix your data now so the bank is ready when AI arrives. Success comes down to readiness to act more than the cleverness of any single use case. Defining a use case is rarely the hard part, since most banks already know where they are inefficient. The hard part is being ready to act on it when the moment comes.

Start now, and don’t wait for the perfect architecture or a fully approved budget. A data foundation is a long, ongoing effort rather than a one-time purchase, and it never really finishes. And remember that your own data compared against the market can tell you something your own data alone never will.