The Exam Packet Should Trace One Number Back to the System

A practical weekly article for community bank and credit union boards and senior leaders on treating board and exam reporting as a data-lineage governance issue, focused on trac...

The most dangerous number in a board packet is not the bad one.

Sometimes it is the clean one.

A fraud loss total. A suspicious activity backlog count. A digital account-opening exception rate. A vendor incident tally. A past-due access review. A call-center complaint trend.

The number looks precise. It fits neatly in the packet. It has a label and a date.

Then the examiner, auditor, regulator, or board member asks the only question that matters.

Where did this number come from?

That is where things get awkward.

Not because the team is careless. Most of the time, they are working hard. The awkward part is that a lot of community banks and credit unions still treat board reporting as a presentation exercise instead of a data lineage exercise. The report gets polished at the end, but nobody can quickly trace the number back through the system, the export, the spreadsheet, the manual adjustment, the owner, and the control that says it should be trusted.

That is not a reporting problem. It is technology governance wearing a tie.

The exam-prep meeting is the right moment

Every institution has a version of this meeting.

The exam is coming. Internal audit is asking for evidence. Compliance wants cleaner documentation. Risk wants the board packet to show progress. IT wants fewer last-minute data pulls. Operations wants everyone to remember that the same three people cannot manually reconcile the universe forever.

This is the moment to stop asking, “Is the report ready?”

A better question is, “Can we trace one important number from board packet back to source system without a scavenger hunt?”

Pick one number. Not twenty. One.

Trace it from the packet to the management report, from the report to the query or export, from the export to the source system, and from there to the control owner who can defend it.

If that sounds painfully basic, good. Basic is where governance usually breaks.

The board does not need directors writing SQL queries or arguing about field mappings. Please do not do that to your board. Nobody wins.

But the board should expect management to know which numbers are source-system generated, which are manually adjusted, which are vendor provided, which are spreadsheet stitched, and which ones depend on institutional knowledge living inside one employee’s head.

That last category should make everyone sit up a little straighter.

Citi showed that data governance is not back-office housekeeping

In 2020, the Office of the Comptroller of the Currency assessed a $400 million civil money penalty against Citibank, N.A. The OCC said the penalty related to deficiencies in enterprise-wide risk management, compliance risk management, data governance, and internal controls. The agency also cited the bank’s long-standing failure to establish effective risk management and data governance programs and internal controls.

That is a large-bank case, and community institutions should not pretend the fact pattern maps perfectly. It does not.

But the governance lesson travels well.

Data governance stops being theoretical when leadership has to rely on a number to make a risk decision, defend a compliance posture, approve a remediation plan, or explain control progress. At that point, the issue is not whether the database diagram is beautiful. The issue is whether the institution can trust the number under pressure.

Community banks and credit unions often have an advantage here. They are smaller. The people who understand the process are usually closer to the people who own the decision. That should make traceability easier.

Unless the institution lets years of workaround reporting, vendor extracts, custom fields, and manual reconciliations pile up without ownership.

Then small does not mean simple. It just means fewer people know where the bodies are buried.

Source: OCC, “OCC Assesses $400 Million Civil Money Penalty Against Citibank,” October 7, 2020, https://www.occ.gov/news-issuances/news-releases/2020/nr-occ-2020-132.html

Evolve showed why recordkeeping becomes a trust issue

In June 2024, the Federal Reserve announced an enforcement action against Evolve Bancorp, Inc. and Evolve Bank & Trust for deficiencies in anti-money laundering, risk management, and consumer compliance programs. The release also referenced enhanced procedures related to recordkeeping and consumer compliance programs. The Federal Reserve noted that its action was independent of the bankruptcy proceedings regarding Synapse Financial Technologies, Inc.

This is not a cue to oversimplify someone else’s situation. Fintech partnerships, middleware, banking as a service, ledger responsibility, and consumer communications can get messy fast.

That is exactly the point.

When accounts, transactions, complaints, disputes, balances, or exceptions move through multiple systems and partners, “the report says so” is not enough. The board needs confidence that management knows which system is authoritative for which fact, who reconciles differences, how exceptions are escalated, and what happens when a vendor record and the bank’s record do not agree.

That matters for partner banking.

It also matters for ordinary community institution life.

A digital account-opening platform feeds the core. A fraud system feeds case management. A call-center platform tags complaints. A vendor portal produces incident metrics. A spreadsheet cleans up what the systems do not quite agree on.

Individually, each handoff feels manageable. Collectively, they become the reporting supply chain. Reporting supply chains need controls.

Source: Federal Reserve Board, “Federal Reserve Board issues an enforcement action against Evolve Bancorp, Inc. and Evolve Bank & Trust,” June 14, 2024, https://www.federalreserve.gov/newsevents/pressreleases/enforcement20240614a.htm

The board packet should separate three kinds of numbers

A practical packet does not need a giant data-governance manifesto. That would lose the room before the second committee update.

Start with three categories.

First, source-system numbers. These come directly from a system of record or a system management has clearly designated as authoritative for that measure. The key board question is whether the source is the right source and whether access, configuration, and change controls protect it.

Second, adjusted numbers. These start somewhere credible, then get changed, filtered, normalized, or corrected before they reach the board. That is not automatically bad. Almost every useful report has logic behind it. The key board question is whether the adjustment rule is documented, repeatable, reviewed, and owned.

Third, assembled numbers. These are stitched together from multiple systems, vendor files, ticket queues, case notes, spreadsheets, and judgment calls. These are often the most useful numbers in the packet because they describe the real operating picture. They are also the easiest to make look cleaner than they are.

The governance issue is not that assembled numbers exist.

The governance issue is pretending they are as mechanically reliable as source-system numbers.

A board can govern this without becoming technical by asking management to label the category for key risk metrics. Source-system, adjusted, or assembled. Simple labels. Big discipline.

What I would want before the next exam-prep review

Before the next exam-prep, audit committee, risk committee, or board reporting discussion, I would ask management for a short traceability review of one high-value number.

Not the entire packet. One number that matters.

The review should answer seven plain-English questions:

1. What decision does this number support? 2. Which system or vendor file is the original source? 3. What transformations, exclusions, or manual adjustments happen before it reaches the board? 4. Who owns the definition? 5. Who reviews the logic after system changes, vendor releases, workflow changes, or policy updates? 6. What evidence would we provide if an examiner asked us to defend it? 7. What would break if the primary report owner were unavailable for two weeks?

This is not about prettier reports

Boards do not need more dashboards. Most institutions already have enough dashboards.

The job is not to make the packet prettier. The job is to make the packet more defensible.

A defensible packet does three things. It tells leadership what is happening. It shows why the number can be trusted. And it makes the ownership clear enough that the institution can fix the number when the underlying process changes.

Systems change. Vendor releases change fields. Workflows change definitions. Staff create workarounds. Compliance changes thresholds. A metric that was reliable last quarter can become misleading this quarter without anyone trying to mislead anybody.

That is why traceability belongs in governance.

Not because the board needs to inspect every pipe behind the wall. Because when water starts dripping through the ceiling, someone should know which valve matters.

Questions for the next board or committee discussion

1. Which board-level technology, risk, or compliance metric would be hardest for management to trace back to its source system today? 2. Which key metric depends on a manual adjustment, spreadsheet, vendor export, or one-person process that has not been tested recently? 3. Before the next exam or audit review, what is one number we should require management to defend from packet to source?