In a remediation war room, a wall of sticky notes tracks every system that touches the benchmark. Red means confirmed and ready to change. Yellow means known but inaccessible. Blue means someone thinks it exists. The blue notes take the longest. The transition away from LIBOR was billed as a regulatory mandate to swap one interest rate for another. In practice, it became the largest forced data lineage exercise in the history of enterprise architecture.
Ask a large institution how many contracts referenced LIBOR at the start of the transition, and you get three answers from three functions. All three are wrong. The legal team has a contract inventory. The technology team has an application inventory. The model risk team has a spreadsheet inventory. None of them reconcile. The transition was supposed to take two years. It took a decade. The extra eight years were spent finding things.
The benchmark was a survey. That was the design. Banks submitted estimates of their borrowing costs. An estimate has no receipt. A transaction leaves a trail: a trade, a timestamp, a counterparty, a price. Lineage is what you get when the input has a trail. When it does not, you get a number that looks authoritative and is not. The manipulation scandal that became public in 2012 was just the symptom. The disease was unverifiability. You could not go check.
Regulators eventually mandated a move to transaction-based risk-free rates like SONIA, SOFR, and €STR. The replacement rates are better because they are boring. A boring rate is one you can check. But fixing the upstream source did not fix the downstream consumption. The market replacement became an inventory exercise. The rate math was ten percent of the effort. Finding where the old rate lived was the other ninety. Any firm that treated this as a market data change rather than a records problem paid for the difference.
Lineage usually breaks at the boundaries. The first boundary is between IT and legal. Legal documents are data sources. They reference rates, but they live in document management systems, often scanned and rarely indexed by clause. The data catalog does not know they exist. When legal and IT sit in the same room to map a loan schedule, the conversation often stops at the second link because the vendor upstream is opaque.
The second boundary is between governed systems and end-user computing. An enterprise data architect sits with a quantitative analyst to map the inputs of a pricing model. The analyst opens a master spreadsheet. The discount rate cell references another workbook on a shared network drive. That workbook contains a macro that scrapes a daily rate from an internal web portal built by a contractor who left six years ago. End-user computing is shadow IT until a regulator asks for an audit. Then it is just IT.
The third boundary is between the present and the past. A migration team updates a core banking mainframe to accept a new overnight rate. They discover the field designed to hold the interest rate is strictly typed to accommodate the specific character length and decimal structure of the old term rate. In another system, a stored procedure written in 2004 contains a hardcoded rate and a comment that says “temp fix.” The comment is nineteen years old. The procedure is on the critical path for regulatory reporting.
IT departments initially tried to solve this with string matching. They ran global searches across code repositories for the word LIBOR. This surfaced millions of false positives in archived databases and missed the exposure hidden in compiled legacy binaries and implied calculations. Finding a string is not the same as finding business logic. Standard data lineage tools map governed environments. They read database schemas and ETL pipelines. They do not read the macros hidden in a local file. The catalog is not the lineage.
A global benchmark enters an enterprise through a single feed. It lands in a master database. Fifty downstream applications poll it. They cache the value. They pass it to reporting engines and risk calculators. A developer reuses an existing object because it is convenient, disconnecting the variable from its original context. The data propagates, shedding its metadata at every hop.
When the benchmark permanently ceased, systems with silent fallbacks defaulted to the last published rate. Variable-rate instruments became fixed-rate instruments overnight. Identifying which systems would trigger this required reverse-engineering exception-handling logic in thousands of disparate applications. Two systems would disagree, and the team would build a reconciliation. The reconciliation would become another system, and another lineage problem. The reconciliation is just the confession that you do not know.
The fines for the manipulation were a line item. The migration was years of contract review, system remediation, model revalidation, and client communication across every jurisdiction the firm operated in. The bill for not having lineage arrived later than the bill for the conduct.
For a few years, large institutions had teams whose only job was to answer where a number came from. They built a capability. Then the deadline passed, and most firms dismantled the teams. The next benchmark change, the next index redefinition, the next regulatory shift will require the exact same work.
An unfalsifiable input is a design flaw. If the input is a human judgment, the output is a judgment, no matter how many decimals you print. This pattern is not unique to interest rate benchmarks. It applies to internal cost allocations, risk weightings, transfer pricing assumptions, and KPIs computed from self-reported inputs. A metric whose source is described as the vendor or the model is just a metric where nobody knows the source.
Lineage is not a diagram you draw in an architecture review. It is the answer to where a number came from, and you have to be able to answer it under pressure. You do not discover lineage. You assemble it under deadline. The inventory you can produce in a week is not the inventory you need when the rate changes.