Over the last N years, I've often been the (Asynchronous Transfer Mode) ATM specialist for the group I'm in, as well as occasionally doing network designs and proposals for banks. While some banks use ATM to connect the networks that support their ATMs, few if any come close to 1000 Asynchronous Transfer Mode connections, much less 13000, and I haven't seen any equipment from Cisco, Lucent, Nortel, or Newbridge that could dispense cash (though all of them made equipment that needed to burn lots of cash on occasion.) NCR once tried to get people to use their PCs are routers, but I don't think any of them had ATM interfaces, though they make automated teller machines as well as cash registers. I've been frustrated by this whole "Oh, no, the bank must have done something terribly wrong" discussion. Banks really _are_ careful about potential problems that could let people siphon off money wholesale, and this doesn't sound at all like that. I don't know their current network, but the most likely causes for some generic banks' problems with teller machines during an event like this are - Using internet VPNs to connect ATMs to their servers, either dedicated 56kbps, DSL, ISDN D channel, or maybe dialup, which got stomped on by ISP traffic loads, which doesn't require that they accept any of the UDP1434 packets, just that random machines send enough of them. Remember that ATMs are very low traffic devices, so if they're using internet connections, they're small, and the flooding picks random IP addresses which isn't size-dependent. - If there actually had been an Asynchronous Transport Mode problem here, it would have been something weird like the bank using an ATM pipe from a network provider (probably a telco) to deliver internet connections on one PVC and Teller Machine and Bank Branch traffic on some or many other PVCs, and getting stomped on by the traffic load. - Another variation on that theme is that some carriers carry their internet traffic on their ATM backbones along with customer frame and ATM traffic, so even if a bank's network was entirely frame relay or frame/ATM interworking, the carrier could have trunk congestion if all their internet users started bursting heavily. - Possibly they're using some teller machine network providers that deliver to them over an internet VPN as opposed to private line or frame, and that got flooded, but that's less likely. - It's possible that a bank that uses VPNs for their ATMs and also has a publicly-visible internet banking service might share the same internet access line and firewall, and be susceptible to flooding cause either by inbound traffic or (much much less likely) outbound traffic from infected servers, while still not affecting the VPNs. It's much more likely they'd be on separate internet pipes for security and reliability, but they might be doing something like separate firewalls for separate servers sharing a pair of access lines. Besides the normal security concerns, those two kinds of operations are usually run by different organizations in any large bank, and BofA is definitely large.