Around $5.4 trillion of payments are made every year through the U.S. government’s secure payment system, which is run by the Treasury Department’s Bureau of the Fiscal Service. It’s normally a sleepy office in the Treasury Department—but now, it’s at the center of the Trump administration’s sweeping agenda. Elon Musk’s Department of Government Efficiency has gained access to the payment system—a fact that has set off alarm bells in parts of the financial community.
What exactly does the U.S. government’s secure payments system do? Should it be considered political or technical? And how fragile is the system?
Those are just a few of the questions that came up in my recent conversation with FP economics columnist Adam Tooze on the podcast we co-host, Ones and Tooze. What follows is an excerpt, edited for length and clarity. For the full conversation, look for Ones and Tooze wherever you get your podcasts. And check out Adam’s Substack newsletter.
Cameron Abadi: What is the scope of what this system does—and what does it do, exactly?
Adam Tooze: Basically, the system is just an organized, electronically based—and since the late 1950s, early 60s, a programmable-software-based—system for organizing the regular payments to everyone who receives checks or deposits from the United States government.
So that does include the full gamut, from grant funding to states and local governments, which goes through a thing called the Automated Standard Application for Payments, or ASAP, or the Payment Automation Manager, which is used to make payments for Social Security, for instance. And the whole thing is organized under the remit of the Bureau of the Fiscal Service.
The volumes here are gigantic—$5.4 trillion in fiscal year 2023. Nearly 1.3 billion payments. The volume on any given day can easily touch a couple hundred billion dollars. It’s a gigantic part of the metabolism of American economy, of American society, of American government.
The BFS itself, the Bureau of Fiscal Services, administers a system that it doesn’t—in any really very meaningful sense—control, right? So the system operates and is triggered by a thing called the payment file. The payment file is sent to the BFS by whichever government agency is employing its services. And that payment file will include the recipient’s banking information and the Social Security number to identify that person. And then BFS processes the payment as per the instruction, and under normal circumstances that’s all it ever does, and the only thing it’s set up to do systematically is to check that payment against a short list of lists.
So there are a small number of lists that that payment has to be checked against automatically. They’re basically “do not pay” lists, and they include things like the Death Master File, which is the list of Social Security numbers that may still be circulating around—this is the Social Security number that every individual in the United States has that actually belongs to a deceased person, so you prevent the embarrassment of having somebody who’s dead.
But it could also include something much more highbrow and high-political, such as a foreign national flagged by the Office of Foreign Assets Control—these are people that run sanctions. Or it could be just somebody who owes a lot of money to the federal government in the form of debt. And obviously, you don’t want to be paying out to them.
The whole thing is processed electronically. Some people receive electronic deposits and other people receive paper checks. And that’s the way this system operates. It’s essentially an organic part of any large, complex organization, not that different from the corporate world. Just very, very large in this case.
CA: Why is this system properly considered to be technical, rather than political? Should this be the choke point at which payments are evaluated as authorized and legitimate—and if not here, then where should that consideration be happening?
AT: So, I mean, it’s part of the Treasury bureaucracy and therefore part of the state. And therefore, you could say, inherently political. And if you are a libertarian, anarcho-libertarian, then you might believe that we shouldn’t have this at all. So just presuming its existence is, in and of itself, a political position.
Or, you could ask, why does the government do this, and why isn’t this outsourced to a private agency? So you could say at that level that it’s political, but of course it isn’t the people operating that system that make the choice—that’s a decision made somewhere else. It’s a constitutional decision that we think that certain functions ought to be performed by government bureaucracies.
And to a certain extent, the state exists. It’s large and it needs to make payments, so we need to have a payment system. Broadly speaking, I would defend the definition of this system as technical, because what does politics mean? If politics is about making complex choices, or it’s about fundamental questions of ideology, or the definition of friends and enemies, or the constitution of majorities so as to enable political action—this isn’t any of those things, and that isn’t what’s happening there.
There could be micropolitics in this organization. Do you employ women? Is it a segregated organization? How do you think about, you know, which computers you buy? Do you have a policy of protecting it against, I don’t know, Chinese influence, for instance? In that way, this technical apparatus could have a political aspect, but the machine itself, in its inherent purpose of just distributing grants or discouraging money, doesn’t seem to me to qualify.
And one of the fundamental misunderstandings of the Musk people, and perhaps also the Trump people, is that this applies to the payments themselves, right? The decisions about whether or not to make the payment are not made by the BFS. They’re made by the other federal agencies that send it the payee file. Once it’s got that file, it just cranks through. It doesn’t make any choices about those files other than asking if the payee is on a “don’t pay” list. And that’s a mechanical operation in its own right. From somewhere else, they get another list, and so they get an instruction to pay, and they get a list, then they check one against the other, and if you have a red flag on the “don’t pay” list, then the payment doesn’t go through.
What Musk and Co. appear to believe is that by taking charge of this plumbing, they can somehow directly intrude and at that point begin to make judgments about who gets paid and who doesn’t. And that’s a misunderstanding of the organization and the legal structure of this entity. It would be a corruption of this entity, and it’s not even obvious whether you can technically set it up to do this because you would then need to manipulate the “don’t pay” lists, presumably. And those may not be open to change by this agency. This would be above or below my pay grade in terms of figuring out what’s going on there.
And most fundamentally, what the Trump administration as a whole wants to test is this question of whether they have the right to stop paying funds that were approved and authorized by Congress. And this is this an issue of impoundment. And broadly speaking, I think the constitutional jurisprudence on this is absolutely clear, which is that they don’t.
Congressional payments are, broadly speaking, defined as a certain amount of money to be paid for a certain purpose to a certain group of people, and you—the executive—don’t have any discretion over whether you do that. So the idea that you can, just as an act of fiat by government, choose to stop paying because you disagree with the politics or some buzzwords trigger you or whatever—that’s very unlikely to stand up in law. They may want to, as it were, force the issue and see how far they can go.
But you wouldn’t need the BFS system. In fact, the BFS system’s kind of secondary to that, because that’s simply the mechanical mechanism through which you either would or wouldn’t pay.
CA: How complex is the structure of this payment system that we’re talking about—and relatedly, how fragile is it? Could it break—and what happens then?
AT: I think the crucial question with this system appears to be how old it is and what vintage of software it belongs to. It really is an early, early vintage. It’s either the very first generation of software languages or perhaps one step on from the very first generation. So it’s written in COBOL, which is a computer language that was developed at the behest of the Department of Defense (DOD), starting on a kind of crash program in 1959. At the time, the DOD had 225 computerstotal and 175 more on order, and they were a bit freaked out by the fact that they’d spent $200 million programing this couple of hundred computers. And so they turned to the emerging software computer programing community and said, ‘Can we make a language that would enable us, potentially, to get some degree of portability between the different systems?’
And what they appear to have hit on is the idea of modifying one of the very early programing language features—which was Flow-Matic, invented by Grace Hopper—and developing that into what then became one of the first widely used programing languages. And it was, from the very beginning, a programing language with a particular purpose.
This is one of the distinctive things about this early generation of programing languages. COBOL stands for Common Business-Orientated Language, and large applications continue to be written in this language all the way down to our era, including as late as 2006. What I gather from reading about COBOL is that on the one hand, it’s attractive because it uses quite a lot of conventional English terms. But on the other hand, it’s not well structured in the modern sense of a computer language.
So there’s an understanding now of computer languages as breaking down into a series of absolutely fundamental elements, which all well-formed computer languages should be structured around. And COBOL isn’t well-suited to the organization of very large software applications along these lines. And the consequence is, to paraphrase one commentary, is that its programs are monolithic. They’re hard to comprehend as a whole, despite their local readability.
So at any given stage, you’re reading along and you’re understanding because it’s using conventional English, what it’s instructing you to do. But because it’s not maybe in colloquial—or, one might say, modular—language, it’s quite difficult to get a feel for the overall arc of the project.
So it’s a bit like saying that you speak English and then being confronted with War and Peace in translation with no chapter headings. So you just have this sprawling, massive epic that you understand word by word, but you don’t really have a way of grasping the whole thing. There’s no table of contents. It’s not clear how one bit of the program attaches to other bits of the program. And when you build very, very large applications, very large pieces of code in this way, they then take on a kind of—people refer to the big COBOL systems in the Treasury Department as dialects. You know, one bit of the system will function in one way, another bit of the system will function in another way. And there are 30 separate large COBOL systems in the Treasury, or have been in the past, which the current crop of software engineers has tried to structure and organize within the Treasury.
So the payments application modernization, PAM, was an effort to sort of bring these organically grown COBOL systems, which go back decades, into the modern era and to unify them within a system that is more like modern software. And I think there are just very large open questions about whether anyone who isn’t from within that culture of progressively developing these massively complex, poorly structured systems can safely make what appear to be small changes and have any real reason for thinking that they know what will happen next.
And I think that’s the real anxiety here. These are large, complex, opaque, sprawling, antiquated systems that experts—and that means not just technical experts, but people who have history with this system—can be trusted to run and make work. And a bunch of newbies coming in and just thinking that they’re smart and that they can fix this are almost doomed to failure.
To answer your bigger counterfactual question: Theoretically, you could set up a new and better payment system for the U.S. government. That’s true of almost all the software systems that the U.S. government operates. But could you do that in the kind of time and pace that we need when people’s lives and their livelihoods depend on the continuity of payments, and those need to be absolutely regular?
No, the short answer is that you can’t. That would require a huge investment of software expertise. It’s not available. And no one who’s ever lived through a large-scale software upgrade in even a medium-sized organization will be under any illusions about how smoothly this would go when we’re dealing with one of the largest and most important systems in the world, dealing with more than $5 trillion. That’s 20 percent to 25 percent of the U.S. GDP flowing through the system. You do not want even a tiny delay in any of those payments.
The post Should We Worry About DOGE Controlling the U.S. Payment System? appeared first on Foreign Policy.
