Banks handle everyone's money and are high-profile targets for compromise over the network. As such, they should be obliged to keep current with best security practices as the technology evolves, not lag far behind these.

But that's the inherent problem; these companies are still setup for a bureaucracy that works fine in a particular area of business, but completely crumbles under the new rules of the technological age. We shouldn't be apologetic for their resisting of change, but rather pushing them to take a long hard look at what needs to be reorganized to fit into the new paradigm.

Banks, of all businesses, should be concerned about online security, for real protection and for appearance of caring for their customers' peace of mind. Mozilla telegraphs these browser changes months in advance.

Malicious crackers aren't going to wait.

After the CVE score for BEAST and RC4 got adjusted and the RFC 7465 was introduced I've seen some payment systems update their system quite quickly (in a matter of days), and if they didn't they'd probably fail their next PCI audit: https://news.ycombinator.com/item?id=9198889

Perhaps it helps if you write your payment site operator/bank private emails asking them to allow other ciphers beside RC4, mine looked like this (actual site name removed):

  According to Qualys SSL Labs the site **** [2] only supports the RC4 cipher, 
  and thus is not RFC 7465 compliant [3], and Google Chrome qualifies the site as 
  "Your connection to **** is encrypted with obsolete cryptography."

  The site **** is even worse [4], it uses only 768-bit DH key exchange in some 
  situations (instead of 2048).

  There is an online tool [5] that you can use to generate/compare 
  configuration for popular web-servers, using the intermediate level is 
  recommended [6].

  For your information I sent a similar email last year to **** and they have 
  fixed their problems, and get a nice 'A' grade from SSLLabs now.

  Apparently this use of RC4 all comes down due to a mistake in NIST's 
  classification of the severity of the BEAST vulnerability [7], but both Google 
  Chrome[7] and Mozilla Firefox[8] are trying to avoid the use of RC4 completely, 
  and mitigating the BEAST vulnerability is no excuse for not providing good 
  ciphers (in addition to RC4 if you must) when my browser supports TLS 1.2 with 
  AES-GCM which is NOT vulnerable to the BEAST attack.

  I suggest you to include the Qualys SSL Labs test when testing sites for 
  PCI-DSS compliance, they are usually quite good at reporting the latest TLS 
  vulnerabilities for a server.

  [1] http://www.visaeurope.com/media/images/pci%20dss%20validated%20web%20listing%20march%202015-73-18412.pdf
  [2] https://www.ssllabs.com/ssltest/analyze.html?d=****
 This server accepts the RC4 cipher, which is weak. Grade capped to B.
 Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2.
  [3] https://tools.ietf.org/html/rfc7465
  [4] https://www.ssllabs.com/ssltest/analyze.html?d=****
 This server supports insecure Diffie-Hellman (DH) key exchange parameters. Grade set to F.
 Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2.
 The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B.
 This server accepts the RC4 cipher, which is weak. Grade capped to B.
  [5] https://mozilla.github.io/server-side-tls/ssl-config-generator/
  [6] https://wiki.mozilla.org/Security/Server_Side_TLS
  [7] https://code.google.com/p/chromium/issues/detail?id=375342#c30
  [8] https://bugzilla.mozilla.org/show_bug.cgi?id=1088915
  [9] https://www.ssllabs.com/ssltest/analyze.html?d=****