Citi’s orders put data lineage on the safety and soundness agenda

The week

On October 7, 2020, the Office of the Comptroller of the Currency, the federal agency that supervises national banks, assessed a $400 million civil money penalty against Citibank. A civil money penalty is a fine imposed by a regulator rather than a court. The OCC also issued a cease-and-desist order, a formal legal instruction to stop unsafe practices and fix them, enforceable in court if ignored.

The action came weeks after a mistake that people in banking still talk about. In August 2020, Citibank mistakenly sent roughly $900 million of its own funds to lenders of the cosmetics company Revlon. Money that should never have left the bank was suddenly in other firms’ accounts. The episode became shorthand for weak controls around manual processes: complex systems, human workarounds and checks that did not catch what they were supposed to catch. The regulators’ action made clear that the mistake was a symptom rather than the whole story.

The Revlon details explain why the episode stuck. Citi, acting as administrative agent on a Revlon term loan, meant to pass on an interest payment of about $7.8 million. Instead the system paid out the full principal, from Citi’s own funds. Some lenders returned their share. Others, holding roughly $500 million, declined, and Citi went to federal court in New York to recover it.

The OCC cited long-standing deficiencies in four areas: enterprise risk management, meaning the bank’s overall system for identifying and controlling risk; compliance risk management, its system for making sure it follows the law; data governance, the rules and responsibilities that keep its information accurate and trustworthy; and internal controls, the checks that stop mistakes and misconduct. The Federal Reserve, which supervises the parent company Citigroup, issued a parallel order requiring improvements in risk management, data governance and internal controls.

The Fed’s wording deserves attention. Its order said the firm had not taken prompt and effective action to correct practices the Board had previously identified, in compliance risk management, data quality management and internal controls. The complaint concerned slow remediation of known problems as much as the problems themselves.

The OCC grounded its findings partly in its heightened standards. These guidelines, in 12 CFR Part 30, Appendix D, describe how the largest national banks should govern risk. They expect a written framework, independent risk management and internal audit with real stature, and a board that holds management to account.

The OCC order was more specific than the headline penalty. Citibank agreed to it without admitting or denying the findings, and it ran to sixteen articles. Within 15 days the board had to appoint a compliance committee of at least five members, a majority of them independent directors. Within 120 days the bank had to produce a data governance gap analysis covering data quality, data aggregation, regulatory reporting and end-user computing. A full data governance plan was due 90 days after that, for the OCC’s written no-objection.

The required contents of that plan read like a syllabus for the whole discipline. They included a framework with roles, accountability and staffing; financial resources; consistent data policies; and a process to identify, escalate and fix data quality issues. They also covered board reporting of significant exceptions, training, enterprise data architecture and system modernization; liquidity data with board-approved tolerances; and a framework to reduce and control end-user computing tools.

Other articles called for staffing and technology resource assessments for control functions, root-cause analysis of internal control issues identified since 2017, and accurate identification and reporting of capital and risk-weighted assets. Internal audit had to validate progress. The orders required remediation plans, detailed programs of fixes that the regulators would review. In the OCC’s case they also required prior approval before certain significant new acquisitions. For a bank of Citi’s size, that was a pointed restriction: grow by buying, and you would first need permission. The OCC also reserved the right to require changes to senior management or the board if progress fell short.

Leadership was already in transition. On September 10, 2020, Citi had announced that its chief executive, Michael Corbat, would retire the following February and that Jane Fraser, then head of its global consumer bank, would succeed him.

For the rest of the industry, the notable thing was less the size of the fine than where “data governance” appeared: in a formal enforcement order, alongside risk management and controls. A topic often treated as back-office housekeeping had been named as a safety and soundness issue, the core test of whether a bank is being run in a way that protects depositors and the financial system.

The Capital One penalty two months earlier had been about sequencing a platform migration ahead of risk management. The Citi orders reached a different layer: the data that flows through every platform.

Supervisors had long raised data governance in examination letters and in reviews of regulatory reporting. In October 2020 they named it, alongside enterprise risk management and internal controls, in a cease-and-desist order with a $400 million penalty. For banks and credit unions of every size, the useful reading separates data governance into three parts that are often confused: lineage, controls on manual work, and accountability. Before those, a more basic question deserves an answer: why is data a safety matter for a bank at all?

A bank is a machine for producing numbers

A bank produces numbers that other people rely on. Depositors rely on their balances. Regulators rely on reports that say how much capital the bank holds as a cushion against losses, how much cash it could raise quickly in a crisis, and how much it expects to lose on loans that go bad. Management and the board rely on risk reports to decide how much to lend, to whom and on what terms.

Every one of those numbers starts life somewhere else. A loan balance is created in a loan system. An interest rate is set in a pricing tool. A customer’s industry is typed into an onboarding screen. Those raw facts travel through many other systems, are combined, adjusted and summarized, and eventually appear as a single line in a report to the board or a regulator.

If the raw facts are wrong, or something goes wrong along the way, the final number is wrong. And because the final number is used to make decisions, a data problem becomes a decision problem. A bank that understates its risky loans may hold too little capital. A bank that miscalculates its liquid assets may believe it can survive a run when it cannot. Supervisors therefore treat data governance as part of safety and soundness rather than as an IT preference.

A restaurant kitchen faces the same test. If a dish makes a diner ill, the health inspector will ask where each ingredient came from, who handled it and what checks were done, and a kitchen that cannot answer cannot be trusted, whatever the dish tastes like. A regulatory report is the dish.

Why supervisors escalated to an order

Supervisors have a ladder of tools, and the Citi orders stood near the top of it. At the bottom are examination findings. Both the OCC and the Federal Reserve use the label “matters requiring attention” for formal findings in examination reports, and the Fed adds “matters requiring immediate attention” for the most urgent. A bank is expected to fix them on an agreed timetable, and examiners track them from one exam to the next.

When findings stay open, supervisors can move to informal actions, such as a memorandum of understanding or a commitment adopted by the board. Formal actions come next: written agreements, cease-and-desist orders and consent orders, which are generally made public and can be enforced in court. Civil money penalties can be added along the way.

The Federal Reserve’s order said Citigroup had not acted promptly and effectively on practices the Board had previously identified. That sentence describes the escalation trigger. Supervisors did not discover Citi’s data problems in 2020. They concluded that years of findings had not produced fixes, and moved the issue from confidential letters to a public order with a penalty attached.

The standard itself was not new. In January 2013 the Basel Committee on Banking Supervision published its principles for effective risk data aggregation and risk reporting, known as BCBS 239, for globally systemically important banks. Banks designated in 2011 and 2012 were expected to comply by January 2016. The Committee’s March 2017 progress report found that only one of the banks subject to that deadline fully complied. Data governance at the largest banks was a known, unfinished problem across the industry.

For national banks with $50 billion or more in assets, the OCC’s heightened standards add a domestic anchor, and the OCC cited them in the Citi order. A community bank or credit union is not subject to the heightened standards. Examiners still apply the same safety and soundness logic through ordinary exams, scaled to the institution’s size and complexity.

Lineage: knowing where numbers come from

A large bank reports thousands of data elements to supervisors, management and the board. Each figure travels from source systems through transformations, reconciliations and manual adjustments before it appears in a report. When that path is undocumented, nobody can say with confidence whether a number is right, and errors spread unnoticed into capital, liquidity and risk reports.

Lineage is the discipline of documenting and controlling that path. For each critical data element, meaning each piece of data important enough that an error would matter, it answers three questions: where it originates, what happens to it along the way, and who is accountable at each step. Institutions with weak lineage tend to find problems through restatements or examiner findings rather than through their own controls.

Two technical terms are worth knowing. A transformation is any step that changes data: converting currencies, summing balances, mapping a product code to a reporting category. A reconciliation is a check that two sets of numbers that should agree actually do, for example that the total of all loans in the loan system matches the loan total in the general ledger. Strong lineage puts a reconciliation at every important handoff, so a break is caught where it happens rather than discovered months later.

Lineage work is expensive, so scoping matters. Few banks can trace every field. The practical approach starts with the elements that feed regulatory capital, liquidity, the allowance for credit losses (the reserve a bank sets aside for loans it expects to go bad) and board risk reports. That is a bounded list. Tracing those end to end, with automated reconciliation at each handoff, covers most of the supervisory exposure.

Smaller institutions face the same logic at smaller scale. A credit union calculating its allowance, or a community bank preparing call report data (the quarterly financial report every U.S. bank files with its regulators), depends on a chain from core system to final figure. The core system is the bank’s main ledger, where accounts, deposits and loans live. Often the chain from core system to report passes through one person’s spreadsheet. If that person is on leave during an exam, or leaves the institution, the lineage leaves with them. Writing it down is cheap insurance against both.

What a critical data element record holds

A useful inventory entry for a critical data element is short. It records the business definition in plain words, the authoritative source system, the owner, the reports the element feeds and the quality rules that apply. It lists the transformations and reconciliations on its path, the thresholds that trigger escalation, and the date someone last confirmed the lineage was still accurate.

The definition is the part most often skipped and most often wrong. Two departments can use one label for different things. “Past due” may mean one day late in a collections system and thirty days late in a regulatory schedule. “Commercial real estate” may or may not include owner-occupied property, depending on who built the report. Until the definition is fixed and written down, lineage only traces a confusion more precisely.

Definitions also shift with accounting change. Most large public banks adopted the current expected credit loss standard, known as CECL, in 2020. From then on, the allowance began to depend on economic forecasts and loan-level history as well as on losses already incurred. Most community banks and credit unions adopted it from 2023. Each adoption added data elements to the path that ends in the allowance figure, and new places for errors to enter.

Which numbers matter depends on the charter

The short list of critical numbers differs by type of firm, because each answers to different reports and different examiners.

• Large bank holding companies file detailed capital and stress testing data with the Federal Reserve. The largest also file resolution plans, which depend on reliable data about legal entities, funding and contracts.
• Community banks file the quarterly call report, and their critical list usually centers on capital, the allowance, loan concentrations and liquidity.
• Credit unions file NCUA’s own quarterly call report, Form 5300. Their critical list tends to center on net worth, the allowance and concentrations in their main lending lines.
• Broker-dealers answer to the SEC and FINRA. Their critical numbers include the net capital computation under SEC Rule 15c3-1 and the customer reserve computation under Rule 15c3-3, reported on FOCUS filings. Recordkeeping under Rule 17a-4 is a separate obligation, though both depend on knowing where records live.
• Wealth managers registered as investment advisers are outside bank capital rules. Their critical numbers tend to be client assets, fees billed and performance figures shown to clients, all of which draw SEC examination attention.

The governance discipline is the same across all of them. The scope, and the examiner who will test it, differ.

Tracing a number, one step at a time

“Document the lineage” can sound abstract to an executive. In practice it is a fairly concrete piece of work, done one critical number at a time.

A small team, usually combining someone from the business that owns the number, someone from technology who knows the systems and someone from finance or risk who uses it, works the path backward. They start from the line in the report and ask, at each step, where it came from. They list every system, every feed between systems, every calculation and every manual touch. They note who is responsible for each step and what check, if any, confirms it worked.

The result is often a simple diagram and a short table rather than a vast technical document. It shows the journey from the source system to the final figure, with the controls marked along the way. The gaps usually jump out: a feed nobody monitors, a calculation nobody can explain, a spreadsheet that one person updates by hand every month.

Specialist software can help at scale, by reading system code and database structures to map data flows automatically. It is useful for large banks with thousands of feeds. But the tool shows only how data moves. It cannot say whether the business definition is right, whether the manual adjustment is still justified, or who should answer when something breaks. Those remain human judgments, which is why the business has to be in the room.

Once the path is documented, the work shifts to keeping it true. Systems change, products launch and people move. Well-run programs tie lineage updates to change management, so that a new feed or a new product cannot go live without someone updating the map for any critical number it touches.

The evidence an examiner will ask for

A lineage program is judged on evidence, and the evidence has a predictable shape. Examiners and internal auditors tend to ask for the inventory of critical data elements and how it was scoped. They ask for lineage documentation for a sample of elements, with the date each was last confirmed. They ask for reconciliation results over a period, including the breaks, how long each stayed open and who cleared it. And they ask for the issue log, with owners, due dates and evidence of closure.

They will also test whether the documents match reality. A common technique is to pick a figure from a filed report and ask the bank to walk it back to source while the examiner watches. If the walk-through stalls at a spreadsheet nobody can explain, the documentation counts for little.

Sequencing matters as much as scope. Programs that start with tooling can spend a year configuring software before anyone fixes a definition. Programs that start with a handful of critical numbers, traced by hand, tend to find the worst gaps quickly and can then decide what tooling would help. The Citi order put the gap analysis first, ahead of the full plan, on the same logic: find out where you stand before committing to a design.

Controls on manual work

In August 2020 Citibank mistakenly sent roughly $900 million of its own money to lenders of Revlon. The error was widely attributed to a manual step in a loan operations system, where an option did not behave as the people using it expected, and several reviewers approved the transaction. Whatever the precise mechanics, the pattern is common: complex legacy systems, human workarounds, and review steps that depend on screens few people fully understand.

How three approvals let a payment through

Testimony at the December 2020 trial over the payment, as reported in the trade press, described a three-step review. A worker at an outsourcing firm entered the payment in the loan operations software. A second contractor checked that entry. A Citi employee then approved it. Banks call this a maker-checker arrangement, and when three people are involved, “six eyes.”

According to the court record as reported, the software would send the principal out of the bank unless certain fields were also set to direct it to an internal account. All three people believed the settings were right. The screen did not make the economic result obvious, and nobody in the chain was asked to confirm it.

Three general points follow, whatever the exact mechanics. Adding reviewers adds cost without necessarily adding assurance, because each reviewer sees the same screen and can share the same misunderstanding. A reviewer who knows the previous person checked the entry is inclined to trust it. When the maker and checker work for an outsourcing firm, the bank’s control depends on another company’s training, turnover and procedures. That makes the arrangement a third-party risk question as well as an operations one.

Why manual steps fail

Manual processes are not inherently dangerous. They become dangerous when undocumented, when they depend on one person’s knowledge, and when the review checks that a step happened rather than that it happened correctly. A reviewer who confirms that a box was ticked is not controlling the outcome, and that gap separates a control that exists on paper from one that works.

End-user computing tools belong in the same category. The industry uses the phrase for spreadsheets, small databases and macros built by business staff rather than by the technology department, which feed financial or regulatory figures. They are flexible and fast, which is why they multiply. They are also rarely tested, versioned or backed up with the care given to formal systems.

The remedy is concrete. Keep an inventory of material manual processes and end-user tools. Rate each for impact and error likelihood. Design reviews around what can actually go wrong, for example by requiring the reviewer to confirm the economic result of a payment rather than the form fields. Set a funded plan to automate or retire the highest-risk items, with dates.

The third step deserves emphasis because it is cheap and powerful. A reviewer asked whether the fields are filled in correctly will check the fields. A reviewer asked how much money leaves the bank, to whom, and whether that is what the bank intends will check the outcome. The second question would catch a far larger range of mistakes, including ones nobody anticipated when the form was designed.

Designing a review that catches the unexpected

A few design choices change what a review can catch. The approval screen can state the outcome directly: the amount leaving the bank, the destination and whose funds are being used. Payments above a size threshold, or out of pattern for the account, can trigger a hard stop that needs an independent approval outside the original workflow. A system can compare a payment with what the loan schedule says is due, and flag one that is many times larger than the scheduled interest before it is released.

These controls cost money and slow some transactions, and operations teams will push back. A team handling thousands of items a day will resist friction on all of them. Friction on the small share of items that are large, unusual or out of pattern is usually acceptable, and those are the items where a single error can be very expensive. The design question is where to place the friction, not whether to have it.

Spreadsheets as systems

The Citi order named end-user computing explicitly: the data governance plan had to include a framework to reduce and control those tools. The order of the verbs is worth copying in smaller institutions. Reduce first, then control what remains.

Control, for a spreadsheet that feeds a regulatory figure, means the things a formal system gets, scaled down. A named owner. A stored, versioned master copy. Locked formulas and documented inputs. A second person who can run it. A review of its logic whenever anything upstream changes. Most institutions can apply that to their highest-rated tools without buying anything.

Reduction is harder, because a spreadsheet usually exists to fill a gap in a formal system. Retiring one means funding the system change it was compensating for. An inventory without a funded retirement plan therefore tends to grow rather than shrink, and examiners notice when the same tools appear on the list year after year.

Accountability: who owns the data

Data programs stall when data belongs to everyone and no one. Business lines create it, technology moves it, and finance and risk consume it. The Citi orders made clear that supervisors expect named accountability from the board down.

• Business data owners for critical elements, with authority to set quality standards and fix the processes that cause errors.
• Quality metrics with thresholds, such as completeness, timeliness and reconciliation breaks, reported to senior management, with breaches that trigger escalation.
• Remediation tracked as risk issues, with dates and owners, rather than as an open-ended technology backlog that competes with feature work.

Technology leaders are in an awkward spot. They run the platforms data moves through, and they are often asked to fix quality problems that start in business processes they do not control. A clear division helps. Business owners define what correct means and fix process causes. Technology supplies lineage tooling, automated controls and monitoring. Risk and audit test whether the arrangement works. Without that division, data programs turn into technology projects that deliver catalogs and dashboards while the errors continue upstream.

The division also clarifies budgets. When data quality is funded from the technology budget, it competes with every other project and loses to visible ones. When business owners carry quality metrics in their own scorecards, the cost of poor data shows up where it is created.

Roles that hold up under examination

Many large banks have appointed a chief data officer, a senior executive responsible for data strategy and governance. The title helps when it comes with authority over standards and escalation. It fails when the chief data officer becomes the person blamed for every error while having no say over the processes that cause them.

A working arrangement usually maps onto the three lines model banks already use for risk. The first line, the business and operations teams, owns the data it creates and the controls on it. The second line, independent risk management, sets standards, challenges the first line and reports on data risk. The third line, internal audit, tests whether the whole arrangement works. The Citi order gave internal audit that role explicitly, with an assessment of progress due within 120 days of the plan’s acceptance and annually after that.

Below the executives are data stewards: people in each business who know what the data means and spend part of their time maintaining definitions, investigating breaks and approving changes. The role is unglamorous and easy to under-resource. Where stewards are a line on an organization chart with no time allocated, quality metrics drift without anyone noticing.

Tying data to pay and to project approval

The order also reached incentives. Its board oversight article called for accountability and compensation tied to risk outcomes, and for root-cause reviews of missed project deadlines. Those provisions recognize a fact data programs often ignore: people respond to what they are measured and paid on. A business head whose bonus depends on revenue growth, and not at all on the quality of the data the business produces, will treat remediation as somebody else’s cost.

Project approval matters for the same reason. The order required formal governance and approval before new products or business realignments launched. A new product that creates data elements without an owner, a definition or a reconciliation is a future finding. Adding a data sign-off to the product approval process costs little and closes that gap at the point where it opens.

The case against heavy data governance

A fair counter-argument exists. Data governance programs can become bureaucracies that produce committees, catalogs and policies while the numbers stay wrong. Business leaders sometimes experience them as a tax on every change, with stewards and approvals adding weeks to simple projects. Smaller institutions point out that they lack Citi’s complexity, and that a team of a few people can know its data well without formal machinery.

Much of that criticism is accurate about badly run programs. It does not undercut the expectation, which is outcome-based: supervisors want to see that critical numbers are right and that someone answers for them. A small institution can meet that with a short list, a few diagrams and a monthly reconciliation pack. The machinery should scale with complexity. The accountability should not.

One board number, traced back to its source

Take a regional bank and one number on its board risk report: total exposure to commercial real estate loans. The board uses it to decide whether the bank is too concentrated in one sector.

The number has consequences outside the boardroom. Interagency guidance on commercial real estate concentrations, issued in 2006, uses ratios of such lending to capital as screening criteria for closer supervisory attention. A bank whose exposure figure is wrong may not know which side of those screens it falls on.

The number starts in the loan origination system, where a lender enters each new loan and chooses a property type from a drop-down list. Overnight, the loans flow into the core system. A monthly extract pulls balances into a data warehouse, a central database built for reporting. An analyst in the risk team downloads the warehouse figures into a spreadsheet, adds a manual adjustment for loans that were miscoded last year, and pastes the total into the board pack.

Now trace the risks. A lender picks the wrong property type because the drop-down is ambiguous. The overnight feed drops loans booked late on the last day of the month. The warehouse mapping puts a new product into the wrong category. The analyst’s adjustment, sensible two years ago, is now double-counting loans that were since fixed at source. The analyst moves to another job, and the replacement inherits the spreadsheet without the reasoning behind it.

Each of these is ordinary. Together they mean the board could be making a concentration decision on a number that is materially wrong, and nobody would know. Lineage documents this chain. Reconciliations at each handoff would catch the dropped loans and the mapping error. An owner for the property type field would fix the drop-down. A review of the end-user spreadsheet would retire the stale adjustment. Not one of these steps is glamorous, and all of them are the kind of work the Citi orders demanded.

Fixing the chain, in order

The repair is a sequence. First comes agreement on the definition of commercial real estate exposure, written down and signed by an owner in commercial lending. Then come reconciliations: origination system against core, core against warehouse, warehouse against the board figure. The stale adjustment is investigated and either documented with a current rationale or removed. The drop-down is rewritten with clearer categories and a validation rule. The spreadsheet is rebuilt with controls or replaced by a warehouse report.

Each step has an owner from a different part of the bank. Commercial lending owns the definition and the data entry. Technology owns the feeds and the warehouse mapping. Risk owns the board report. Internal audit later tests whether the reconciliations run and whether breaks are cleared. If any one of them drops out, the chain tends to break again, often at the point where the last reorganization moved someone.

The bill for poor data

The Citi orders concerned one very large, very complex bank, but their costs show why every institution should pay attention. A single manual error sent roughly $900 million out of the door. The regulators added $400 million in penalties and a restriction on acquisitions. Remediation of this kind takes years of effort and investment.

The less visible costs are just as real. Poor data slows every decision, because people spend time checking numbers rather than using them. It weakens confidence in management information, so executives fall back on instinct. And it undermines every attempt to modernize, because new platforms, analytics and automation all inherit whatever is wrong with the data they are fed.

Costs that compound

The acquisition restriction shows a cost that is easy to overlook. Under the OCC order, Citi needed a no-objection before completing significant acquisitions. Ordinary activity such as hedging, market making and securitization was excluded, but strategic growth by purchase now ran through a supervisor’s view of remediation progress. For any bank under a formal action, strategy becomes partly a function of examination results.

Management attention is the other compounding cost. A consent order brings quarterly progress reports to the board, regular submissions to the examiner-in-charge, internal audit validation, and plan changes that need prior no-objection. Senior people spend years inside that cycle. For a smaller bank under a formal action, the same cycle absorbs a larger share of a thinner executive team. The cheapest time to fix data governance is before an examiner writes it up.

Staffing is the third. The order required assessments of staffing and technology resources for control functions, including people holding dual roles. Data stewards, reconciliation analysts and control testers are hard to hire in a hurry, and a bank that must find many at once pays for it in salaries, consultants and time.

The standard, scaled to size

The standard the orders set applies at any size, scaled to complexity. The board and senior management should be able to explain how the institution knows its most important numbers are right, and produce the evidence on request.

A well-governed institution has a short list of critical data elements with named owners and documented lineage for each. It runs automated reconciliations at the handoffs and reports quality metrics to management, with thresholds that trigger action. It keeps a rated inventory of manual steps and spreadsheets with dated plans for the riskiest. Its reviewers check outcomes rather than forms.

The programs that go wrong tend to fail in familiar ways. Some try to trace every field and run out of money before reaching the numbers that matter. Some buy a data catalog and call it governance, though a catalog does nothing to fix the process that creates bad data. Some leave it all to technology, even though business lines create most data errors and must own the fixes. Some keep approvals that confirm a step happened rather than that the result was right. And some treat remediation as a project with no end date, when supervisors measure progress by milestones met rather than plans written.

A first year, by type of institution

For a community bank or credit union, a sensible first year is modest. Pick ten to twenty critical numbers. Document the lineage of each on a page. Put a monthly reconciliation at the main handoffs, usually core system to general ledger and general ledger to call report. Inventory the spreadsheets that touch those numbers, rate them and fix the top few. Report progress to the board’s audit or risk committee at least twice a year.

A regional bank adds scale and formality. Its list runs longer, it needs tooling to monitor feeds, and liquidity or stress testing work may add data elements with tight deadlines. A dedicated data governance function in the second line becomes realistic, along with quality metrics in business scorecards.

A broker-dealer or wealth manager faces a different trap. Much of its data may flow through systems run by a clearing firm, a custodian or an affiliate. Lineage then crosses legal entities and contracts, and the firm has to make sure it can obtain the data and evidence it needs from those parties. Contract terms on data access and audit matter as much as internal controls, and should be settled before an examiner asks.

At every size, the measure of success is fewer surprises. Restatements, examiner findings about data and late corrections to board reports should decline over time. If they do not, the program is producing documents rather than better numbers.

Where the board’s numbers come from

A board or audit committee can test this area without technical depth. Each of the following should have a short, specific answer backed by evidence.

• What are the twenty or so numbers our board and regulators rely on most, who owns each one, and can we show on paper every step each passes through?
• Where are the reconciliations along those paths, and how often do they break?
• When someone reviews a large manual payment, are they checking the form or confirming how much money goes where?
• If a key analyst left tomorrow, which reports would nobody else know how to produce?
• Before we build analytics or AI on a dataset, how do we confirm we know where its data came from?

With hindsight

Remediation proved slow. In July 2024 the OCC and the Federal Reserve again penalized Citi, a combined $135.6 million, for insufficient progress on the data management problems identified in 2020. The OCC amended its 2020 order, citing missed milestones, to make the bank prioritize the work and devote enough resources to it. Its announcement singled out data, citing persistent weaknesses and a lack of processes to monitor how data quality problems affected regulatory reporting.

That second round of penalties carries its own message. Data governance programs at this scale take years, and supervisors measure them by outcomes rather than plans. A remediation plan accepted by a regulator marks the start of the scrutiny, and missing the milestones in it is treated as a fresh failure.

Progress did come, slowly. In December 2025 the OCC removed the 2024 amendment, which had required Citi to submit a resource review process. The 2020 orders themselves stayed in force, and Citi’s 2026 filings still described remediating them as a multiyear effort. More than five years after the orders, the work was advanced but not finished.

Data weaknesses also surfaced through a different supervisory channel. The Federal Reserve and the FDIC had found a shortcoming in Citigroup’s 2021 resolution plan related to data quality and data management. The agencies announced their review of the 2023 plans in June 2024. They disagreed on how serious a new weakness in Citi’s plan was: the FDIC called it a deficiency, the Fed a shortcoming. The 2021 data shortcoming remained outstanding. A resolution plan, or living will, describes how a large bank could fail without wider harm, and it is only as credible as the data behind it.

Manual payment risk persisted too. In February 2025 the Financial Times reported that in April 2024 Citi had credited a client account with $81 trillion instead of $280. Two employees missed the error and a third caught it; the entry was reversed within hours, no money left the bank, and Citi reported the near miss to the Fed and the OCC. The review chain failed at its first two steps, and a later control worked.

The Revlon payment had a long legal tail of its own. In February 2021 a federal judge in New York ruled that the lenders could keep roughly $500 million of it. The Second Circuit reversed that decision in September 2022. In the meantime, many syndicated loan agreements added clauses obliging lenders to return payments made in error, so one agent bank’s mistake changed standard documentation across the loan market.

The topic has grown in importance since 2020, for a reason few people were discussing at the time. Banks now want to apply AI and advanced analytics to the same data that feeds regulatory reports. When the banking agencies asked for comment on AI in 2021, they listed their existing model risk management guidance among the expectations that apply and stressed data quality. Model risk management is the discipline of checking that the mathematical models a bank uses to make decisions are sound, well understood and used appropriately.

The connection is direct. An institution that cannot trace its data lineage will struggle to validate a model built on that data. An AI tool trained on badly governed data will learn the errors along with everything else, and do so at a speed and scale no spreadsheet could match.

The Citi orders read today as an early statement of a principle that now underpins both regulatory reporting and responsible use of AI: an institution has to know where its data came from. Data governance is less a cost to be minimized before the interesting work begins than the foundation that makes the interesting work possible, and safe.