Your Operations Don't Have a Staffing Problem. They Have a Data Problem.

In 2020, the OCC fined Citibank $400 million for data governance failures: inadequate internal controls, poor data quality practices, and risk management deficiencies that had persisted across multiple regulatory cycles. Citibank is not a community bank. But the underlying problem it was fined for is not unique to large institutions. Data that is produced by one system, stored in another, and relied upon for decisions without any systematic validation between those two points is a structural issue that appears at every asset size. The consequences scale with the institution, but the problem does not.

US regulators issued $4.3 billion in financial penalties in 2024, with banks accounting for 82 percent of all fines. Behind most of those enforcement actions (across transaction monitoring failures, KYC gaps, and sanctions screening deficiencies) was a data quality problem that was visible in the institution's systems long before it was visible to the regulator. The fine is the last event in a chain that started with unvalidated data.

For community banks and credit unions, the risk rarely reaches that scale. But the operational cost of unvalidated data is real and present every day, distributed invisibly across the hours of every person on the operations team. It does not show up as a line item on any report. It shows up as the reason the team never has enough capacity.

The Problem Nobody Has Named

Here is the pattern that runs through most community bank and credit union operations, regardless of the specific workflow being described.

A system produces a record. A second system stores a document. Neither system verifies that the record and the document agree with each other. So a person does it. They pull up both, compare them field by field, note any discrepancy, and move to the next one. When the discrepancy requires a correction, they log it somewhere and add it to the queue of things that need to be fixed.

That pattern repeats across deposit account QC, loan review, reconciliation, KYC onboarding, vendor monitoring, and regulatory reporting. In each case, the institution has data. What it does not have is data it can trust without checking. And checking is labor. Labor has a ceiling. The ceiling is why 90 percent of accounts never get reviewed and why the same errors appear in the same sample year after year without triggering a review of the rest of the population.

The institutions that recognize this pattern as a data integrity problem, rather than a staffing problem, are the ones that can actually solve it. Hiring more people to do the same manual validation is not a solution. It is an investment in overhead. The answer is in validating the data automatically, so the people are available for the work that requires judgment rather than patience.

Where Unvalidated Data Shows Up in Operations

The following four areas illustrate how the same root problem manifests differently depending on the workflow. Most community banks will recognize more than four. But these four carry the most concentrated combination of reputational, regulatory, and operational cost when the validation gap is left open.

1. Deposit account documentation

A core system holds a record of what an account contains: the owner, the beneficiary designation, the ID verification data, the product type, the associated disclosures. A document management system holds scanned images of the physical documents: the signature card, the account agreement, the ID, the beneficiary form.

The core and the document storage system do not talk to each other about content. The core knows a document exists in storage. It does not know whether the document is signed, whether the name matches, whether the date of birth on the ID corresponds to what the core shows, or whether the beneficiary designation reflects the member's current intent. A rules engine can check whether a document was filed. It cannot check whether the document is accurate.

So a reviewer does it. They pull up the ID image. They look at the date of birth. They look at the date of birth in the core. They look at the name. They look at the address. Three fields per document. Hundreds of accounts per cycle. For 10 percent of the portfolio, at 15 to 45 minutes per account, with known errors sitting in the unreviewed 90 percent. The labor cost is the price of the validation gap. For a deeper look at how this plays out and what the automated alternative looks like, the deposit account QC posts earlier in this series cover it in detail.

2. Loan file review

A loan origination system holds a structured record of loan terms: the interest rate, the borrower's name, the collateral value, the loan amount, the disbursement date. Loan documents in storage hold the paper trail: the note, the mortgage, the appraisal, the income verification, the signature pages.

The LOS record and the documents do not validate each other. A reviewer starts at the beginning of the application and works through every field: does the rate on the note match the rate in the LOS, does the name match, does the collateral description correspond to the appraisal on file, are all required signature blocks executed. For each loan. From scratch.

Unlike deposit account QC, where many institutions have at least built a rules layer for core data validation, loan QC is frequently fully manual from the first field. The reviewer is the only validation layer between the loan document and the institution's records. When the reviewer is busy, errors accumulate. When the portfolio grows, the review gets further behind. The gap between loan volume and review capacity is a direct function of the labor cost per loan, and that cost is not going down as long as the validation is manual.

3. Daily transaction reconciliation

Two transaction datasets that should agree: ACH files against the general ledger, wire records against the core, card processor settlements against what the bank booked. They almost always agree on most items. The problem is the exceptions.

In a manual reconciliation process, a staff member downloads both files, opens a spreadsheet, runs a comparison, and investigates the rows that don't match. For a small credit union with manageable daily volume, this takes one person a few hours. For a larger institution with higher volume and more complex settlement flows, it can consume most of a day. The exceptions require research: pulling up transaction detail, cross-referencing source records, determining whether the discrepancy is a timing issue, a processing error, or something that needs escalation.

The breaks that don't get resolved accumulate. At month-end close, the reconciliation team is working through current discrepancies while also trying to close out items that have been open for weeks. The accumulated backlog is a direct product of the gap between how many exceptions are generated daily and how many the team has capacity to resolve.

4. Member and customer onboarding verification

A new account application generates a set of submitted documents: an ID, a Social Security verification, a beneficial ownership form for business accounts. Those documents need to be compared against third-party records: state registries for business entity status, sanctions screening databases, watchlist checks for beneficial owners. In many institutions, that comparison is done manually, with a staff member pulling up each source and checking each field against the submitted documentation.

The manual process is slow enough that onboarding timelines stretch beyond what members expect. It creates a pattern of errors: an application where the beneficial ownership form doesn't match what the state registry shows, an ID where the address submitted doesn't correspond to public records, a name that appears on a watchlist without being caught because the screening step was missed in a high-volume period. Each of these is a known KYC gap. The gap persists not because the institution doesn't know it should check. It persists because checking takes time the team doesn't have.

Where Unvalidated Data Hides and What It Costs

What This Costs in Numbers

McKinsey estimates that poor data quality increases operational costs by 15 to 25 percent across financial services organizations. For a community bank or credit union with an annual operating expense base of $20 million, that range represents $3 to $5 million in costs attributable to data quality failures: the labor hours spent on manual validation, the rework required when errors surface, the remediation effort when backlogs are discovered, and the compliance costs when validation gaps generate regulatory findings.

The more specific number comes from Datachecks research: organizations incur an average of $20,000 annually in staff time specifically for audit demands caused by poor data quality. That figure covers only the staff time consumed responding to audit requests when the underlying data was not sufficiently clean to answer questions without manual investigation. It does not include the cost of building and maintaining the manual validation processes that preceded the audit, the cost of remediating the errors the audit found, or the cost of the errors that went undetected.

These numbers describe the operational cost. They do not describe the regulatory cost. US regulators issued $4.3 billion in financial penalties in 2024, with banks accounting for 82 percent of all fines. The enforcement actions behind those fines consistently cite data governance failures: transaction monitoring systems fed by inaccurate data, KYC records that don't reflect the institution's actual due diligence process, reconciliation breaks that persisted long enough to indicate a systemic control failure rather than an isolated error.

For most community banks and credit unions, the regulatory outcome of a data integrity problem is not a nine-figure fine. It's an examination finding, a memorandum of understanding, a required remediation plan, and the staff time required to respond. That is a materially different scale. But the source is the same: data that was produced by a system, relied upon for decisions, and never validated between those two points.

Why More People Is Not the Answer

The operational response to a capacity problem in most financial institutions is to consider adding headcount. When the reconciliation team can't keep up with daily breaks, the conversation turns to whether there's budget for another analyst. When the QC team can't cover more than 10 percent of accounts, the question becomes whether an additional reviewer would help.

The answer is sometimes yes, in the short term. But adding people to a manual validation process does not change the underlying ratio of labor required per item validated. If each account review takes 20 minutes and the team needs to cover 35,000 accounts annually, the math requires approximately 11,667 staff hours per year at full coverage. Adding one reviewer might add 2,000 usable hours. Coverage goes from 10 percent to roughly 26 percent. The 74 percent that remains unreviewed still carries unknown errors. The capacity problem is smaller. It is not solved.

What changes the ratio is automating the work that does not require judgment. Document comparison against structured core data does not require a trained professional's judgment. It requires accurate pattern matching at scale. Routine transaction matching does not require investigative analysis. It requires consistent rule application across large datasets. When those tasks are handled automatically, the same people who were covering 10 percent of accounts can cover 100 percent, because they are no longer doing the extraction and comparison work that was consuming most of their available time.

What a Data Validation Layer Actually Does

The operational answer to the data integrity problem is not a data governance program in the abstract sense. It is a validation layer: a process that sits between the data your systems produce and the data your teams act on, and that systematically checks whether those two things agree.

For deposit account documentation, that layer extracts core data, retrieves documents from storage in batch, and runs the reconciliation logic against a defined checklist. Fields that match are cleared automatically. Fields that don't match generate an exception routed to the appropriate reviewer with the specific discrepancy identified. The reviewer acts on the exception. They do not do the comparison.

For loan review, the layer reads the LOS record and the loan documents in parallel, applies the validation rules for that loan type, and flags the items that require human judgment. The reviewer gets a structured exception report rather than a raw document stack. They confirm the judgment calls. They do not reconstruct the data from scratch.

For reconciliation, the layer ingests both transaction files, applies matching logic, automatically clears routine matches, and routes true exceptions with source documentation attached. The team investigates real discrepancies rather than spending the morning on manual matching.

For onboarding verification, the layer cross-references submitted documents against third-party sources, runs watchlist checks, flags discrepancies, and routes the items that need human review. The reviewer confirms the edge cases. They do not conduct the initial screening manually for every applicant.

The result in each case is the same: the team's time shifts from validation mechanics to validation judgment. The automated QC workflow posts earlier in this series cover the deposit application of this model in detail. The loan review and reconciliation applications follow the same architecture. The institution's systems stay in place. What changes is the layer between them and the people who act on their outputs.

Shore's free CORE Assessment evaluates operational readiness across five categories including data quality, process coverage, and regulatory compliance posture. For institutions that want to understand where their data validation gaps are concentrated and what closing them would require, it provides a structured starting point.