How We Compute Chain Attribution

Methodology for the PAC chain attribution figures shown on entity profiles

What Chain Attribution Is

Money in federal elections often does not travel in a straight line. A donor gives to a PAC. That PAC transfers money to another PAC. The second PAC spends on behalf of a candidate. Each individual transaction is reported to the Federal Election Commission. But no filing connects the donor at the start of the chain to the candidate at the end. Chain attribution is our method for estimating those end-to-end connections from the individual reported transactions.

Every chain shown on the site is built entirely from transactions that committees themselves reported to the FEC. The chains are factual records of money movement between committees.

The Data

The inputs are the itemized donation rows in this database that fall inside the two-year cycle being built (dated January 1 of the odd year through December 31 of the even year, amount greater than zero; undated rows are left out). Each row becomes an edge in a graph and is classified into one of three roles, origin, transfer or terminal, by the rules described on this page.

Where a row carries an FEC transaction type code from the filing it came from (stored as fec_transaction_type), the code is checked against three sets first.

Origin: 11A, 11C, 15, 15E and 15F. Only 15 (contribution) and 15E (earmarked contribution) do any work: 11A and 11C are Schedule A line numbers (individual contributions; contributions from other committees), not transaction type codes, and no row carries them. These are the donors at the start of a chain.
Transfer: 22Y and 22Z. In the FEC's scheme those are contribution refunds, not committee-to-committee transfers (transfers in are 18G and 18K; transfers out are 24G and 24K), and one row in the database carries either code, so in practice no transfer edge is classified by code. This is a known defect in the builder. The transfer edges that drive the chains come from the fallback rule below.
Terminal: 24K (contribution made to a nonaffiliated committee, usually a candidate's), 24A (independent expenditure opposing a candidate), 24E (independent expenditure supporting one) and 24T (earmarked contribution passed through to the recipient). These are the ends of chains. Because 24K also covers PAC-to-PAC contributions, some committee-to-committee hops end a chain here rather than continuing it.

A row whose code is in none of the three sets (for example 10, 15J or 24I) falls through to the fallback rule, as does a row with no code.

Most rows do not carry a code. On 2026-10-23, about 1.55 million of the 1.66 million donation rows had no FEC transaction type recorded. The code was added to the ingest after most rows were loaded and has not been backfilled. Thus for about 94% of edges the builder infers the role from the row's donation type and the types of the two entities:

A row typed independent_expenditure is a terminal edge, whether it supported or opposed the candidate.
A row typed individual from a person or an organization is an origin edge.
Any row from a PAC to another PAC is a transfer edge; any row from a PAC to a person is a terminal edge.
Any row from a person or an organization to a PAC is an origin edge.
Anything else is left unclassified and takes no part in a chain.

Two consequences follow. First, a PAC's payment to a candidate's committee that is stored here as a committee (type PAC) rather than as the person is treated as a transfer, not a terminal. Thus chains can run through candidate committees. Second, support and oppose are not distinguished at classification time. An independent expenditure against a candidate is a terminal edge to that candidate exactly as one in support is. The entity pages label each terminal's direction from the filing; the chain builder does not.

The Algorithm

We start at each terminal transaction and walk backward. The PAC that made the terminal payment received money from many sources. We apportion the terminal amount across its inflows in proportion to each inflow's share of the total. If an inflow is itself a transfer from another PAC, we repeat the process one level up. We continue until we reach an origin contribution or hit the hop cap.

Date ordering. When apportioning a payment made on a given date, we only count inflows dated on or before that date, because money cannot be spent before it arrives. When dates are missing, or no recorded inflows precede the payment, we fall back to apportioning across all of the committee's inflows for the cycle. Chains built with that fallback are flagged on the site (“date order unverified”) and are always assigned low confidence.

Hop cap. Chains are capped at five hops. Beyond that depth, proportional apportionment dilutes amounts to the point where the estimate is no longer meaningful, so longer routes are not traced.

Bounds on the walk. A super PAC with tens of thousands of itemized donors and hundreds of expenditures would otherwise produce tens of millions of chains, almost all worth a few dollars. So an inflow whose share of a given payment would be under $25 is not traced as its own chain. Its dollars are pooled at that committee. Each terminal payment keeps at most its 2,000 largest chains. Chains with the same donor, route, recipient and support or oppose direction are summed across a committee's payments, and summed chains under $100 are not stored. None of this money is dropped. Every dollar not stored as a chain is recorded in a coverage table, by recipient and by the committee where it was pooled or stopped. The build is rejected unless the stored chains plus those remainders equal the terminal spending. For the 2024 cycle, built October 23, 2026: $2.26 billion of $2.92 billion is stored as chains; $233 million is pooled small-donor money; $314 million passed through committees that spent more than ten times the receipts we have ingested, so it cannot be apportioned; the rest is trimmed, below the minimum, or reached committees with no recorded inflows.

Cross-cycle flag. If a committee spent noticeably more in a cycle than it took in, some of its spending was likely funded by cash on hand from an earlier cycle. Chains through such committees carry a cross-cycle flag, because part of the money may predate the inflows we apportioned it across.

What the Numbers Mean

Each chain carries two numbers, and they mean different things.

The attributed amount, labeled “modeled estimate,” is the output of the proportional apportionment described above. It is an estimate of how much of the terminal spending traces back to a given origin donor. It is not a reported transaction, and no FEC filing contains that dollar figure. Dollars are fungible once they enter a committee's account. No method can determine which specific dollars funded which specific payment. Proportional apportionment is a standard, transparent convention for estimating it.
The smallest single documented leg is the smallest FEC-reported transaction among the legs of the chain (and, for a chain summed across several payments, among all of their legs). It shows that each step of the route is a real reported transaction of at least that size. It is not an amount of money documented as travelling the whole route, and it can be larger than the modeled estimate.

Attributed amounts are estimates of flow, not reported transactions. Where a precise reported figure matters, follow the source links to the underlying FEC filings.

Confidence Levels

High. Both the origin donor and the terminal recipient are matched to official FEC committee or candidate IDs, the chain is short, and date ordering was enforced at every hop. Entity identification is deterministic, not name-based.
Medium. The chain is sound but at least one endpoint was matched by name rather than by FEC ID, so there is some chance the entity resolution is wrong.
Low. One or more of the following: the chain is at or near the five-hop cap, the backward walk stopped at the cap before reaching a true origin contribution, or date ordering could not be enforced and the cycle-wide fallback was used.

Limits of the Method

Chain attribution covers only money movements itemized in FEC filings. It does not capture unitemized small-dollar contributions, spending by organizations that do not report to the FEC, or non-financial relationships. Chains describe where money moved, in what order, and in what reported amounts. They do not establish why a donor gave or whether a donor knew where the money would end up. They are not evidence of coordination, of any agreement between the parties involved, or of any quid pro quo.

Corrections are welcome. If you believe a chain misstates the underlying filings, contact us and we will review it against the FEC record.