Before Your AI Investment Pays Off, Your Data Has to Be Ready. 

Written by Akash Kandhari

The Pressure Is Real. So Is the Risk. 

Every credit union leader I work with right now is navigating the same tension: the board wants an AI strategy, the technology budget isn’t unlimited, and the team is already stretched keeping current systems running. Meanwhile, a fintech competitor just launched a personalized savings nudge product, and a member posted about it on LinkedIn. 

The pressure to move is real. But in my pre-sales conversations with credit unions across institutions of every size, the mistake I see most consistently is this: organizations try to solve that pressure by selecting an AI platform before they’ve identified a specific problem worth solving. And beneath that, they haven’t validated whether their data can support the solution they have in mind. 

The result is a proof of concept that impresses in a demo and disappoints in production, and a team that becomes skeptical of AI broadly, not just the specific tool. 

This piece is about what actually needs to be true about your data before AI delivers what the vendors are promising. It’s also about the sequencing question that most organizations get backward. 

The Real Blocker Isn’t the AI Tool 

Most credit unions aren’t short on data. They’re short on data they can actually use. 

Transaction histories, loan applications, call center interactions, digital banking behavior, and member demographics. It’s all there. What’s typically missing is a unified, governed layer where that data is clean enough, connected enough, and accessible enough to power anything more sophisticated than a monthly report. 

Here’s what that looks like in a real scoping conversation. A mid-size credit union wants to build a member attrition model. The data science vendor says they need twelve to eighteen months of transaction history, member tenure, product holdings, and digital engagement signals. The core banking system has most of the transactional data. The Salesforce org has member interactions and service history. Digital banking engagement lives in a third system. None of them shares a member ID schema. No one has documented which system the master is of record for member contact information. There are roughly 40,000 duplicate member records that the team has known about for two years, but hasn’t had the bandwidth to address. 

That project isn’t a data science project. It’s a data plumbing project, and the AI vendor didn’t scope for that. 

The five data readiness gaps that surface most consistently in pre-sales discovery across credit unions of every size: 

01	No master member identity Duplicate records across core, CRM, and digital channels with no reconciliation process. This is the single most common gap, and the one that breaks the most AI use cases before they start.
02	Unmapped schemas Core banking exports that don’t align with any standard data model require a custom transformation for every downstream use. Each new integration compounds the problem.
03	Missing data lineage No documented record of where a field came from, when it was last updated, or whether it can be trusted. Without this, AI outputs can’t be validated, and staff won’t trust them.
04	Governance gaps Sensitive member data is accessible without role-based controls or audit trails. This is a compliance exposure, not just a technical problem. NCUA examiners are increasingly asking about it.
05	Logic in the wrong layer Critical business rules embedded in Excel models, BI reports, or analyst scripts, rather than the data layer itself, are invisible to any AI system trying to reason about member behavior.

These are the problems that kill AI pilots. Not the model. Not the platform. The data underneath it. 

A Readiness Path That Reflects How This Work Actually Gets Done 

Most data maturity frameworks describe a destination without a path. What follows is how we actually sequence this work in practice, and what each stage requires before you move to the next one. 

Stage 1: Inventory & System Mapping 

Before any cleanup, you need an honest picture of your data landscape. What systems hold member data? What does each consider authoritative? How does data move between them today, and how often? This is unglamorous work. For many credit unions, it surfaces things that haven’t been looked at in years: a batch job written for a legacy system that was never updated, a field mapping that was accurate in 2018 and isn’t anymore. You need to see it before you can fix it. 

From the field:  For a credit union running Symitar with Salesforce FSC, we typically start by mapping the Symitar member and account object model to FSC’s Financial Account and Person Account hierarchy. The gaps in that mapping tell you exactly where data quality problems will surface downstream. 

Stage 2  Member Identity Resolution 

The single most important thing a credit union can do before any AI investment is to establish a canonical member record. One authoritative definition of who a member is, which system owns it, and how changes propagate. Credit unions that have grown through mergers often have members in two different numbering schemas. Digital banking platforms sometimes create net-new user records that don’t map cleanly to core member IDs. Name and address variations across systems quietly prevent record matching at scale. 

From the field:  Salesforce Data Cloud’s identity resolution capabilities are purpose-built for this problem, ingesting records from multiple systems and building a unified profile using configurable matching rules. For institutions not yet on Data Cloud, a well-governed golden record approach in FSC creates the foundation you need. 

Stage 3  Schema Standardization & FSC Alignment 

If your credit union is on Salesforce FSC, there’s a significant leverage point many implementations underutilize: FSC ships with a financial services data model designed for exactly the member, household, and account relationships credit unions need to represent. The challenge is that many credit unions go live on FSC without fully mapping their core banking data to the FSC schema. The result is a CRM that reflects what loan officers enter manually rather than what the core system knows, which means every AI feature built on top of it is working from an incomplete picture of the member. 

From the field:  We’ve seen institutions where Einstein Next Best Action recommendations were running but ignored by staff because they were obviously stale. The issue wasn’t the model. It was that product holding data in FSC that was ninety days behind the core. The fix was an integration layer, not an AI layer. 

Stage 4  Governance & Regulatory Alignment 

Data governance feels like a policy exercise until it’s an NCUA examination finding. For credit unions, governance at the data layer has to account for BSA/AML transaction monitoring, member data privacy requirements, and the audit trail expectations of a regulated institution. Practically, this means role-based access controls that reflect actual staff access needs, data classification that distinguishes operational from sensitive member financial information, and change tracking that lets you answer the examiner’s question: who had access to this record, and when was it last modified? 

Stage 5  Integration Architecture for AI Consumption 

The final readiness layer is ensuring that clean, governed, identity-resolved member data can flow to where AI needs it: in near real time, where latency matters, in batch, where it doesn’t. For credit unions on Salesforce, this typically means a real-time or near-real-time integration between the core banking system and Salesforce Data Cloud. Data Cloud then serves as the AI-ready data layer, unifying member records, calculating real-time segments, and feeding Einstein and Agentforce with current context. For smaller institutions not yet ready for Data Cloud, a well-architected direct integration between the core and FSC, even a nightly batch, is still meaningfully better than what most are running today. 

How to Start Without Starting Over 

The most common pushback I hear after a conversation like this is: “This sounds like a two-year program before we see anything.” It doesn’t have to be. 

The key is sequencing around a specific use case rather than treating data foundations as a prerequisite to complete in full before AI starts. Pick one high-value AI use case. Identify the minimum data requirements to make it work well. Execute the foundation work scoped to that use case only. You deliver something real, you learn something real, and the foundation you built supports the next use case. 

A credit union that wants to deploy Agentforce for member service triage doesn’t need a complete member identity resolution project. They need clean routing logic, a well-structured case object, and reliable service category data. That’s a six-to-eight-week effort. It’s deliverable. It produces measurable results: reduced handle time, faster resolution, and staff who actually use the tool because it works. 

The question to ask before your next AI budget discussion isn’t “which AI tool should we buy?” It’s “what would we need to believe about our data for this to actually work?” Answer that first. Everything else follows. 

Ready to Assess Your Starting Point? 

Cloud for Good’s Financial Services team works with credit unions at every stage of the AI journey, from institutions evaluating their first use case to those scaling what’s already working. A Data Readiness Assessment structured around a specific AI use case takes two to four weeks and gives you a prioritized gap list, a minimum viable data architecture for that use case, and an honest timeline.  

Take a look at how our Assessment Workshop is structured below. 

 Interested in booking a session? Contact us today.

About the Author

Akash Kandhari is the Director of Solution Engineers at Cloud for Good Financial Services, working with credit unions and community financial institutions on Salesforce FSC, Data Cloud, and Agentforce implementation. He works with organizations at the pre-sales stage, where the gap between what AI promises and what the data can support becomes visible, and focuses on helping institutions sequence the foundation work that makes AI delivery actual.