IRS Sharing Taxpayer Info With ICE Is a Data Governance Issue

A report on the IRS sharing address information with Immigration and Customs Enforcement suggests that failing to prioritize taxpayer confidentiality is the real scandal, not interagency data sharing. This comes as tax administration is becoming more automated, data dependent, and attractive to every enforcement agency in Washington.

The IRS appears to have moved sensitive taxpayer data through a process vulnerable to bad inputs, crude matching logic, and unresolved safeguard issues. If tax data is going to move between agencies at all, it should travel only through the most narrow, validated, and auditable processes that treat taxpayer confidentiality as a real obligation.

The Treasury Inspector General for Tax Administration report found that the IRS provided last-known address information for nearly 47,000 people after ICE requested information tied to 1.2 million records. In Washington, there will likely be a split between those who see such disclosure as a necessary law-enforcement tool and those who see a betrayal of vulnerable taxpayers.

But that fight risks obscuring a more durable tax-administration issue that might garner bipartisan concern.

Section 6103 of the tax code doesn’t make IRS information impossible to share between agencies; it just makes confidentiality the default and disclosure the exception. Those exceptions exist for reasons that could have been salient, including for non-tax criminal investigations.

But a narrow exception to taxpayer confidentiality shouldn’t operate like a bulk data-transfer permission slip. The IRS receives some of the most sensitive information people and businesses are legally required to provide to the federal government. That makes weak disclosure procedures a danger to every taxpayer.

Another agency that wants IRS data should have to prove necessity, precision, security, and auditability before a single record moves—and for each record specifically and individually.

Photographer: Michael M. Santiago/Getty Images

As the TIGTA report noted, before releasing address information, the IRS built an automated process to pair ICE data and IRS records. But it was vulnerable to malformed ICE inputs, inconsistent name and address formatting, and ineffective matching rules.

TIGTA also found that ICE had open safeguard findings from its most recent security review and missed multiple corrective action plan deadlines before the data transfer. This means there were unresolved security questions on the back end.

As much as any enforcement agency might like access to IRS data—which is comprehensive, current, and compulsory—the government rammed a poorly tailored script through a statutory exception and left precision, security, and auditability behind.

TIGTA found that the matching criteria built by the IRS were unable to identify and match records “accurately and consistently.” Compounding the issue, the data ICE submitted wasn’t clean, standardized, or consistently formatted.
Anyone who has ever tried to reconcile two government data sets will recognize the genre—it’s unsurprising the data was messy. It is surprising, however, that the taxpayer information was moved between agencies so haphazardly.

When the IRS discloses taxpayer information based on another agency’s input file, the quality of that file becomes part of the taxpayer privacy question. Bad inputs aren’t mere inconveniences to programmers. They increase the risk that protected tax information will be linked to the wrong information, disclosed based on an incomplete or inaccurate record, or sent where the legal predicate for disclosure is nonexistent.

The IRS can’t treat data matching as a back-office implementation detail to be cobbled together in response to the latest political wind. If the matching rules are allowed to be crude, the privacy protections are crude. If the input standards are loose, the statutory exception functionally expands.

And if malformed records can pass through the pipeline, taxpayer confidentiality depends less on Section 6103 and more on whether someone in the IT department remembered to code a validation for ZIP codes.

A better system would start before the IRS ever runs a match against an external database. Any agency requesting tax information should have to submit clean, structured, validated data in standardized fields. No free-form address blobs, placeholder entries, or random ZIP-like strings.

Records that fail validation (“close enough” formatting doesn’t count) should be rejected automatically, and ambiguous cases should require manual review. The IRS should be made to document why each disclosed record met the legal, factual, and technical threshold for release.

Perfection is impossible, and data matching will always involve some degree of uncertainty. That is why the threshold for disclosing protected tax information should be held to a higher standard than ordinary administrative convenience. When a private company botches a match, someone may get the wrong advertisement in their mailbox—when the IRS gets something wrong, the consequences can be far more serious.

That isn’t to say IRS data should never be shared between agencies. Section 6103 contains exceptions for a reason. But those exceptions should operate like locked doors, not loading docks. Another agency that wants IRS data should have to prove necessity, precision, security, and auditability before a single record moves—and for each record specifically and individually.

That requires clean and structured inputs, individualized legal certifications, match-confidence thresholds, manual review for edge cases, and strict use and retention limits with audit rights for both the IRS and TIGTA. None of this is exotic. It’s the bare minimum one should expect before the agency turns tax records into an identity database for another agency’s mission.

Andrew Leahey is an assistant professor of law at Drexel Kline School of Law, where he teaches classes on tax, technology, and regulation. Follow him on Mastodon at @andrew@esq.social.

Read More Technically Speaking