For most of its history the federal payment system has run on what people inside it call “pay and chase.” Money goes out first. If something was wrong, the government then spends staff time trying to claw it back from a company that turns out to be dissolved, fabricated, or never eligible in the first place. That rarely works. Once the funds have moved, they tend to stay moved.

The Bureau of the Fiscal Service owns this problem, because the Fiscal Service disburses roughly 95 percent of all federal payments. At that volume, a small percentage of improper payments adds up to billions of dollars a year. The Payment Integrity Information Act of 2019 requires the Treasury to bring those numbers down, and Do Not Pay is the program built to do it.

The pandemic showed what the old approach costs. Programs pushed enormous sums out the door quickly, and a share of it went to businesses that did not qualify. A common pattern looked like this: a relief program set an eligibility date, say a company had to exist before mid-March 2020, and money still reached entities incorporated in the months after, when they could not have been eligible. Catching that three years later, in a report, is pay and chase. Catching it before the payment is the goal of the Do Not Pay program.

What Do Not Pay is, and who runs it

Do Not Pay is a centralized service. Federal agencies, and federally funded programs that states administer, can send it information about a payee or an award applicant and search across multiple databases for reasons a payment might be improper. Instead of every agency buying and wiring up its own data sources, the checks live in one place that many programs share.

What the program is allowed to do is also changing. Historically Do Not Pay could flag a questionable payment and ask an agency not to make it, but the agency still owned the final decision. As its legislative authority has expanded, the program moves toward stopping a payment directly when the evidence says it should not be made. That raises the stakes significantly on every data check it makes. A signal that used to inform a recommendation can now directly halt a disbursement, so it has to be clean enough to defend when someone challenges it.

Do Not Pay pulls on many signals. The one OpenCorporates provides is narrow, and surprisingly hard to answer well at the moment it matters: is this business a real, currently registered legal entity, and was it registered at the correct point in the payment lifecycle?

A business does not have to be fraudulent to fail that test. It can simply have dissolved. An inactive or missing registration is a risk indicator on its own, because it suggests the entity is no longer operating or was created to look real long enough to collect a payment. The June notice describes the use plainly. The dataset supports a client agency’s determination of whether a business is eligible for a federal payment or award, “including verifying whether the business holds an active registration with the relevant state’s secretary of state office at various points in the payment lifecycle.” The notice lists those points as:

• when the business applies for federal funding
• by a program-specific eligibility cutoff date
• at the time of payment

Comparing today’s data against payments already made is useful for a report, but what the program wanted was to run the check live, at the point of decision, so eligibility is verified in something close to real time rather than confirmed years later.

The old model needed different data than this new one. Pay and chase needed a historical snapshot, but prevention needs current registry status at the moment of payment.

The two tests the data had to pass

The Treasury’s data strategy leaders have to be able to explain, on Capitol Hill, how a fraud determination was reached. If a business is denied funds and challenges that decision, the government has to show every reason behind it. Scores and flags produced by models nobody outside the vendor can inspect make that difficult. One Treasury data strategy leader set the requirement during the evaluation: they need “100 percent transparency into how all their variables are calculated” before a source goes into their environment.

OpenCorporates collects directly from official registries and carries provenance and a last-updated date on each record, so an analyst can say where a fact came from and when it was checked. For the Treasury, that lineage is exactly what they needed.

The second test was financial. The going-in benchmark was roughly a tenfold return: the data had to help prevent something on the order of ten times its cost in improper payments. For a source whose main job is confirming that a company exists and is currently registered, the team believed that bar was reachable, and expect it to raise in the coming years.

What designation actually requires

Bringing a commercial data source into Do Not Pay is a formal process, and OpenCorporates went through all four steps of it.

• A business case describing what the data is, which elements it contains, and how each one helps identify or prevent improper payments. It goes to Treasury leadership and then to the Office of Management and Budget, whose Director has delegated authority under 31 U.S.C. 3354(b)(2) to the Secretary of the Treasury to designate additional databases for Do Not Pay when they substantially assist in preventing improper payments.
• A privacy impact assessment covering what information is collected, why, and how it will be used. Treasury determined that the OpenCorporates dataset pertains only to business entities and holds no information about individuals within the meaning of the Privacy Act, which is what you would expect from registry data about companies.
• A cybersecurity assessment covering the data’s confidentiality and integrity and how it connects to the system. Do Not Pay runs as a FISMA High system with role-based access, audit logging, encryption, and identity controls, so the bulk-file delivery method had to fit inside that.
• A Federal Register notice. The same statute requires the Treasury to give public notice and take comments before it designates anything, so the Treasury publishes a proposed designation, runs the comment period, answers whatever comes in, and then publishes a final notice.

For OpenCorporates, the proposed notice ran on June 25, 2026, with comments open to July 10. None were filed. The final notice followed on August 18 under Docket ID No. TREAS-DO-2026-0430, signed, like the first, by Gary Grippo, the Acting Fiscal Assistant Secretary, and it took effect on publication, with no phase-in period. Nothing in the proposal had to change along the way.

How the data is delivered and used

Weekly bulk files over SFTP

The delivery model is simple. OpenCorporates drops weekly bulk files of U.S. company data into an SFTP location for the program to collect. Weekly matters because registration status is a moving target. OpenCorporates collects new incorporations from many U.S. registries weekly or faster, harmonizes them quickly, and publishes freshness metrics per jurisdiction so the program can see how current each state’s data is. That keeps the picture close to what the registries themselves hold, which is what the “at the time of payment” check depends on.

What a check returns

Once the file is ingested, the working system uses the fields a program is most likely to have on a payee, the business name, business address, and where available the EIN, to verify against the OpenCorporates dataset. The June notice lists what comes back for a given entity:

• registration status, active or inactive
• registration date and incorporation date
• dissolution date, where it applies
• the name, position, and address of the entity’s officers

That is enough to answer the eligibility question at whichever point the program needs it.

Where this is heading

Confirming that a company exists and is registered is the starting point. Do Not Pay is building a wider fraud capability: a connected data environment where OpenCorporates is one signal among several and analysts can look at how those signals overlap. As payment data improves and the program can trace payments further through the system, that supports solutions to harder problems, such as:

• following the people and entities connected to a suspect payee
• spotting patterns in how companies are opened and closed
• tracking shell-company creation over time, in cooperation with inspectors general and other agencies

OpenCorporates helps answer the question of whether a business is real and eligible right now, but mapping the structures and relationships behind those entities is a larger problem, one that leans even harder on knowing exactly where each fact came from.

The gap this fills

Federal agencies tend to be rich in their own data and short on outside data vital for flagging issues before something goes wrong. Data-sharing laws also limit what the government can assemble about businesses on its own. That is why a commercial source of official public registry data is useful to them.

The Treasury’s designation on August 18, 2026 puts that data inside the federal payment system at scale. The records come from official state and territory registries, carry their own provenance, arrive weekly, and have been through the privacy, security, and public-comment steps a government program requires.