Iran's Banks Went Down Twice in 9 Days. One System Links Them All.

Two cyber incidents in nine days disrupted major Iranian banks; the individual institutions reveal less than the payment infrastructure connecting them. Three separate banks, one shared substrate beneath them; a single fault in the lower layer reaches all three at once.

On June 23, Iran temporarily suspended card-based services at three of its largest banks, after customers of Bank Melli, Bank Saderat and Bank Tejarat lost access to card-linked mobile applications, point-of-sale terminals and ATM services. The country's state-owned banking technology provider said the suspension was meant to prevent further unauthorized access while cybersecurity teams worked to restore operations. That would have counted as a significant disruption on its own, had it been the first of its kind, yet it was the second such event in little more than a week.

On June 14, the same three banks, joined by the Export Development Bank of Iran, experienced outages after a cyberattack struck communications infrastructure shared by the institutions, so that within nine days the same lenders, sitting inside the same interconnected financial environment, went dark twice.

Public reporting does not establish that a single actor carried out both events, because Iran has not published technical indicators, named a suspected group or explained which components were compromised. That uncertainty deserves to stay in view, though it should not obscure the larger lesson sitting underneath. What happened was less a story about several banks being attacked at roughly the same moment than a story about the layer connecting them.

The Difference Between a Bank Attack and a System Attack

A conventional account would treat Bank Melli, Bank Saderat and Bank Tejarat as three separate victims, though that framing may be technically inaccurate, since banks can operate as distinct legal and commercial institutions while leaning on the same communications systems, payment switches, identity services, clearing networks and technology vendors. A failure inside one of those shared layers can surface publicly as several unrelated bank outages, which is to say the institutions are different while the dependency underneath them is not.

Iranian officials acknowledged as much after the June 14 incident, when they said the attack had targeted shared communications infrastructure used by the affected banks, whereas the June 23 disclosure was vaguer, describing a suspension of card-based operations across three banks without identifying the exact compromised system. The overlap is hard to ignore, because the same lenders lost service again and the second event knocked out multiple card channels at once, including ATMs, mobile applications and merchant terminals, which points to a problem sitting above any individual branch or app and toward the payment plumbing beneath all of them.

None of this proves the national payment switch itself was breached, since a centralized defensive shutdown could produce the same outward shape, as could a shared vendor, an authentication service, a network gateway or a card-processing dependency. The line between compromise and containment stays unresolved even though the operational result was identical: a shared dependency producing a shared disruption.

The Company Between the Banks

The public announcement came from Iran's Informatics Services Corporation, which is no ordinary software contractor. Affiliated with the Central Bank of Iran and functioning as a central technology provider for the country's banking system, ISC oversees Shetab, the national electronic banking clearance network, while also connecting to Shaparak, the electronic card-payment network, which makes it an infrastructural hinge. With banks on one side and the consumer-facing machinery of ATMs, card terminals, payment processors and mobile applications on the other, ISC sits in the middle and helps operate the layer that joins them.

That position changes how the incident should be read, because the relevant question is no longer only whether three banks were breached but whether someone found a way to reach the common systems those banks depend upon, which is a far more consequential possibility, since breaching one bank creates an institutional crisis while reaching a shared payment layer creates correlated failure across many.

What the Routing Table Shows

The contour of the dependency is visible from the outside, since the public routing table records which organizations advertise their own address space and which vanish into someone else's. Iran carries roughly 882 autonomous systems, of which only sixteen wear a bank's name; the way that handful maps onto the four lenders caught in the June outages is itself revealing. Two of them run their own networks, Bank Saderat on AS42990 advertising the /22 at 185.192.8.0/22 and the Export Development Bank on AS205894 announcing the /22 at 185.232.176.0/22, each a block of about a thousand addresses. The other two, Bank Melli and Bank Tejarat, do not appear in the table as networks of their own at all, which means their public reach is folded into infrastructure operated by someone else rather than carried on space they hold themselves.

The layer that does appear under its own name is the one ISC operates. Shetab, the interbank clearing network, sits behind a single autonomous system, AS50177, publishing exactly one /24 at 88.135.32.0/24, so the clearing fabric that every domestic card transaction crosses is visible to the outside world as 256 addresses. Shaparak, the card-payment switch, runs on AS49796 with seven small prefixes, among them 5.160.241.0/24, 185.129.189.0/24 and the contiguous 185.167.72.0/23. None of these networks, the two payment rails or the banks beside them, keeps any presence at a neutral internet exchange, so reaching them runs through private upstream relationships that can be cut at a single hop.

Read together, the records describe the concentration the outages exposed. A settlement layer that publishes a couple of hundred addresses, carries no exchange peering and sits in front of institutions that hold little or no routable space of their own is a system with very few places where everything can be reached at once, which is the underlying condition that lets one disruption travel across several banks on the same day.

Routing snapshot · public BGP and PeeringDB, mid-June 2026

Centralization Is Efficient Until It Becomes the Blast Radius

National payment networks exist for good reasons, since they let a card issued by one bank work at another bank's ATM, provide common transaction routing, standardize the messaging between banks, merchants and processors, reduce duplication and hold the financial system to a single uniform shape. Without that shared layer, ordinary electronic payments would run slower, cost more and fail more often.

The same architecture also concentrates risk, because a national switch becomes a high-value target the moment it offers access to more than one institution; a shared communications provider becomes strategically important once several banks lean on it; a central technology operator accumulates operational reach that no single bank could ever hold alone. This is not uniquely Iranian, since modern economies run on centralized infrastructure throughout their financial systems, where payment networks, cloud providers, telecommunications carriers, identity platforms, certificate authorities and managed service providers all create efficiency by folding common functions into a smaller number of systems. The resulting exposure is structural: the more institutions that depend on the same layer, the wider the potential blast radius when that layer fails.

Cybersecurity programmes still tend to measure risk institution by institution, yet attackers face no obligation to respect that boundary and can simply look for the provider sitting behind the institutions.

Sanctions Made the Infrastructure More Important

ISC also occupies an unusual geopolitical position, because the United States sanctioned the company in 2024, describing it as a subsidiary and technology arm of the Central Bank of Iran. The Treasury Department noted that ISC oversaw the Shetab clearing network, was affiliated with Shaparak and had built infrastructure for Iran's central bank digital currency programme.

That history means the organization responding to the June attacks is not merely a domestic technology provider; it is also woven into the international sanctions architecture surrounding Iran's financial system, which produces a complicated operating environment. Iran has been pushed to build out domestic financial infrastructure in part because its access to international payment networks and Western technology is restricted. While domestic control buys a measure of autonomy, it can also deepen the reliance, since a country assembling parallel payment systems to reduce outside dependency tends to route more of its national financial activity through a smaller set of domestic operators.

The infrastructure grows harder for foreign governments to reach through conventional financial pressure at the same time as it becomes a more valuable cyber target, which is the gap between sanctions resilience and cyber resilience: a system can be insulated from foreign financial control while staying wide open to technical disruption.

What Iran Has Not Disclosed

The available information remains thin. Iran has not:

• identified the initial access method
• said whether attackers reached banking applications, network infrastructure, authentication systems or payment-switch components
• published indicators of compromise
• disclosed whether data was encrypted, altered or extracted

Officials said no customer information was compromised during the June 14 incident, though that claim has not been independently verified. The June 23 suspension was framed as a preventative response to unauthorized access, wording loose enough to leave several readings open:

• the attackers may have entered a shared environment
• defenders may have spotted suspicious activity before core systems fell
• the shutdown may have been an aggressive containment move
• or a handful of unrelated problems may have been read publicly as one national event

Without technical evidence, attribution would be guesswork. Although Iran has previously blamed Israel or foreign adversaries for attacks on its infrastructure, that history establishes nothing about responsibility here, so the absence of attribution belongs in the story, as does the absence of architectural detail. Governments routinely name the affected institutions while withholding the identity of the shared provider, network segment or software component that let the disruption spread, which protects sensitive systems and, at the same time, prevents outsiders from judging whether the vulnerability has actually been closed, since restoring service is not the same as eliminating the access path.

The Recurrence Is the Warning

The June 14 disruption reportedly took several days to resolve. Services were interrupted again on June 23, so even if the two events were unrelated, the recurrence shows Iran's banking environment operating under sustained pressure; if they were related, the implications grow heavier.

A repeated incident points in several directions at once: the original foothold may never have been fully removed, attackers may have held onto credentials, persistence mechanisms or access to a shared provider, defenders may have restored public-facing services before finishing the deeper remediation. Each reading is common in complex infrastructure incidents, where organizations face enormous pressure to bring systems back quickly. Customers need access to their money, merchants need working terminals, banks need transactions to move and governments need to demonstrate control, so recovery becomes the visible objective while eradication stays slower and far less obvious, which means a system can look healthy while the underlying investigation remains unfinished. The decisive date, then, may not be June 23 at all but the date of the next disruption.

The Real Target Is the Dependency Map

Cybersecurity analysis often opens with the victim list: which banks were affected, how many customers lost access, how long services stayed offline. Those questions are worth asking, though they describe consequences rather than structure. The more useful inquiry begins with the dependency map:

• Which organizations carry communications between the banks?
• Which entity operates transaction routing?
• Where are authentication decisions made?
• Which payment switches connect ATMs and merchants?
• Which vendors hold privileged access across several institutions?
• Which components can be disabled centrally?

Those are the systems that decide whether an incident stays local or turns national. The June attacks exposed at least one fact cleanly: Iran's major banks are not operational islands; they share infrastructure, so disruption inside it can travel across institutional boundaries. That is the story beneath the outage. The banks were the part everyone could see while the shared layer carried the weight, so until Iran explains which piece of that layer failed, the most important element of the incident stays hidden.