Nobody publishes a customer list for PL/I. There's no analyst report ranking mainframe languages by institutional install base, no vendor logo wall, no annual survey with a PL/I line item broken out the way COBOL sometimes gets. What exists instead, when you actually go looking, is stranger and more useful: a public support-forum thread on IBM's own community site, where the people who'd actually know answered a straightforward question with straightforward names.
The question that shouldn't have needed asking
In December 2023, someone named Raul Alonso Sanchez posted to IBM's Z and LinuxONE Languages community with a specific, practical problem. His client was CaixaBank, Spain's largest bank by market share, and it was exploring generative AI to help modernize its core systems. He knew COBOL was the dominant mainframe language. What he didn't have, and what nobody else in the thread seemed to have either, was a clear picture of how common PL/I actually was in banking specifically, so he asked the forum directly.
“My client, CaixaBank, bank #1 in Spain, is eagerly exploring the possibilities that Generative AI offers to modernize their core system. It is evident that COBOL remains the most widely used language, but we lack a clear understanding of the prevalence of PL/I within the banking sector.”
Raul Alonso Sanchez, IBM Z and LinuxONE Languages community, December 4, 2023
That's worth pausing on. This wasn't a student or an outsider trying to understand mainframe computing from a distance. This was someone working with one of the largest banks in Spain, evaluating a modernization strategy, who had to ask a public forum a question that, for almost any other enterprise technology, would already be answered by a market-research report, a vendor case-study page, or a plain web search. For PL/I, none of that existed. The forum thread was the market research.
The answers, one institution at a time
Two days later, three separate replies filled in more of the picture than any published survey has, between them, ever put in one place. Robert Prins named four institutions directly: KBC, the Belgian bancassurance group; Allied Irish Banks, one of Ireland's largest retail banks; KLM Royal Dutch Airlines; and Belgium's Socialist Mutual Health Insurance fund. His phrasing carried its own honest hedge, he wasn't certain the arrangement was still current, which is itself a fair summary of how little visibility even people inside this world have into each other's present-day systems.
- KBC (Belgium): a major bancassurance group combining retail banking and insurance, named as running solely on PL/I for its systems, per Robert Prins's reply.
- Allied Irish Banks (Ireland): one of Ireland's largest retail and commercial banks, named alongside KBC in the same reply.
- KLM Royal Dutch Airlines: named as a PL/I user, with no further operational detail offered in the thread itself.
- Socialist Mutual Health Insurance (Belgium): a Belgian health-insurance fund, the one entry in the list with no obvious connection to banking or airlines at all.
Why this skews so heavily toward Europe
Every name in that thread shares something in common: not one of them is a US company. That's not a coincidence specific to this one forum thread, it's the actual shape of PL/I's surviving install base, and it's also a big part of why PL/I gets covered so much less than COBOL in English-language technology press. COBOL's heaviest concentration was always the American commercial mainframe base, the same base that produces the bulk of English-language trade press, analyst coverage, and industry-conference speakers. PL/I's heaviest concentration landed in a specific set of European banks and airlines instead, institutions that don't feed the same media pipeline and don't get covered by outlets whose sourcing runs primarily through domestic-market relationships. A language can be genuinely load-bearing at a specific set of institutions and still be nearly invisible in general coverage, if those institutions all happen to sit outside wherever the coverage is actually being written from.
The other named institutions, from Austria
Johann Wöckinger's reply added Austria to the map, and the way he phrased it says as much as the names themselves do.
“Several austrian banks, eg. Raiffeisen, 3BEG, .. given on job offers and insider knowledge ;-) stil use PL/I in their core banking apps.”
Johann Wöckinger, IBM Z and LinuxONE Languages community, December 6, 2023
That parenthetical, "given on job offers and insider knowledge," is the whole story of how information about PL/I's real footprint actually circulates. It doesn't come from press releases or annual reports. It comes from job postings that mention the language by name because a bank genuinely needs someone who knows it, and from people who happen to work in or near the institution and say so on a forum, half-joking about the fact that this is where the information actually lives.
The third reply, from Volker Birk, named the institution whose story has since gotten more complicated than anyone in that thread could have anticipated.
“On your concrete question the Credit Suisse (now UBS) have a core banking implementation based on PL/1.”
Volker Birk, IBM Z and LinuxONE Languages community, December 6, 2023
What happens to a PL/I system when the bank that owns it stops existing
Credit Suisse doesn't exist as an independent bank anymore. UBS acquired it in a deal announced in March 2023 and completed that June, a forced rescue engineered by Swiss regulators after a spiral of losses and withdrawals, not a leisurely, planned technology consolidation. UBS's chairman, Colm Kelleher, was public about how long the broader integration would take.
What's genuinely striking, if you go looking for it, is how little of the extensive public reporting on that acquisition ever touches the technology underneath the bank at all. Coverage of the deal focuses overwhelmingly on the CHF 3 billion purchase price, the wiped-out AT1 bondholders, and the job losses, which is exactly the coverage a deal of that size should generate. What it doesn't cover, anywhere in the public record this piece could find, is what specifically happens to a core banking platform built on PL/I when the institution that owns it gets absorbed into a much larger one running its own, presumably different, technology stack. That silence isn't proof of neglect. It's just more evidence of the same underlying pattern: this is a part of the story nobody outside the institution is tracking, on a system that a forum thread from a stranger's client turns out to be a better public source for than anything in UBS's own investor communications.
Somebody at UBS inherited that decision, whatever it turned out to be, whether that meant keeping the PL/I core running as-is behind a new corporate name, migrating it onto UBS's existing platform over that multi-year integration window, or something in between. None of that is public. What is public, from the forum thread alone, is that as of late 2023, months after the acquisition closed, the system Volker Birk described was still being described in the present tense.
The modernization path that doesn't ask anyone to rewrite the business logic
For an institution in that position, weighing what to do with decades of PL/I logic it may not have written and can't easily throw away, the industry has actually built a real alternative to a full rewrite. Raincode, a compiler vendor better known for its COBOL work, also ships a PL/I compiler aimed specifically at getting mainframe applications off the mainframe without touching the business logic itself: it recompiles existing PL/I source into managed .NET code that can run on Azure, rather than requiring anyone to reimplement the application in a new language from scratch.
That distinction matters more than it might sound like it does. A rewrite means re-deriving decades of business rules that, in a core banking system, are frequently undocumented anywhere except the code itself, then testing the new implementation against every edge case the old one silently handled correctly for thirty or forty years. A recompile-and-rehost approach treats the PL/I source as the actual specification, worth preserving exactly as written, and changes the infrastructure underneath it instead. For a bank whose core PL/I system has been accumulating undocumented business logic since before most of its current engineering staff were hired, that's not a minor implementation detail. It's the difference between a modernization project with a knowable scope and one that's really an open-ended, multi-year archaeology exercise with a banking license attached.
Raincode's PL/I compiler also doesn't operate in isolation, which matters for a core banking system that was never just PL/I in the first place. The same vendor offers separate compilers for JCL, CICS, and VSAM/SQL, the job-control, transaction-processing, and data-access layers that PL/I programs on a real mainframe are typically wired into. A bank's core system is rarely a clean, self-contained PL/I codebase; it's PL/I procedures invoked from CICS transactions, driven by JCL job streams, reading and writing through VSAM or SQL access paths with their own decades of accumulated behavior. A modernization approach that only handled the PL/I language itself, and ignored everything wired around it, wouldn't actually solve the problem an institution like this has.
It also explains something about why the institutions named in that forum thread haven't shown up in a wave of "bank completes COBOL-style migration" press releases the way some larger American mainframe shops have. A rewrite makes a good press release. A recompile that changes nothing a customer, a regulator, or an auditor would ever notice doesn't, even when it's the more defensible engineering decision for a system where getting a single interest calculation wrong is a regulatory problem, not just a bug ticket.
The fingerprint PL/I left somewhere nobody's looking for it
The institutions above are places PL/I is still directly running the show. There's a second kind of real-world PL/I footprint, quieter and far larger in raw headcount, that has nothing to do with anyone still maintaining a PL/I program at all. SAS, the statistical software used across pharmaceutical research, banking risk modeling, and government statistics, was originally written in PL/I, and its data step language is still modeled on PL/I's syntax today. Every analyst writing a SAS data step is typing syntax shaped by decisions PL/I's designers made in the 1960s, almost certainly without knowing it, because SAS never had a reason to advertise its own implementation history to the people using it every day.
That's a different kind of persistence than a bank still running a core system built decades ago. Nobody has to keep a PL/I compiler running for SAS's syntax to keep echoing PL/I's design choices forward; the influence outlived the implementation that produced it. It's a reminder that a language's real-world footprint isn't measured only in production systems still executing its literal source code. Sometimes it's measured in syntax habits an entirely different, far more widely used tool never bothered to change.
Where this leaves you
- There is no published, authoritative list of who runs PL/I in production; the most complete public record found here is a forum thread of practitioners answering each other's questions.
- KBC, Allied Irish Banks, KLM, Belgium's Socialist Mutual Health Insurance, Raiffeisen and other Austrian banks, and Credit Suisse's core banking platform are all named, specifically, by people in a position to know, not by marketing material.
- Information about PL/I's real footprint circulates through job postings and informal insider knowledge, not through the channels that document most enterprise software.
- UBS's acquisition of Credit Suisse is a live, current example of a PL/I core banking system changing ownership with essentially no public reporting on the technology decision itself, only the financial one.
- Recompiling existing PL/I straight to .NET on Azure, rather than rewriting the business logic from scratch, is a real, available modernization path for institutions in exactly this position.