How safe is the 256-bit encryption used in bank transactions?
You can pretty much ignore the statements about 128 and 256 bits. It is a marketing statement intended to sound impressive, but really it just means that they are using SSL in a not-totally-stupid way.
(It means the symmetric-key cipher is using a 128-bit or 256-bit key. This ensures that the symmetric cipher is not the weakest link in the chain. However since the symmetric cipher is not the weakest link in the chain, the risks will be primarily elsewhere, so you shouldn't get too caught up in the meaning of 128- or 256-bit strength. This just means that they haven't chosen a stupid configuration that makes the symmetric key readily breakable. It does not mean that the RSA key is 128 bits or 256 bits; as you say, a 128-bit or 256-bit RSA key would be totally insecure.)
There is a lot written about this topic on this site. I suggest you read Is visiting HTTPS websites on a public hotspot secure?. Also see the blog entry QotW #3: Does an established SSL connection mean a line is really secure?. And read Is accessing bank account on the internet really secure? and Does an established ssl connection mean a line is really secure. Doing a search on this site will find lots of information -- give it a try!
Asymmetric key length (like in RSA) and cipher key length (like in AES, RC4) are quite different. RSA keys used in public-private asymmetric cryptography should be 1024-bits or greater. AES, RC4 and other cipher keys should be 128 bits or greater. What's the difference? RSA widely let's everyone know the public key N and e, where N is the product of two large prime numbers. If you can factor the composite number N you can derive the private key and decrypt any message encrypted with the public key.
Factoring is a hard problem that cannot be done in polynomial time on a non-quantum computer, but there are tricks from number theory to factor numbers better than naive brute force. Trivially when looking for factors of N, rather than trying every integer between 1 and N, you could skip all the even numbers except 2, or try dividing by only prime factors or stop when you reach sqrt(N), rather than trying to divide by every factor between 1 and N. In the real world techniques like elliptic curve method can factor ~260-bit composite numbers in a couple minutes on one cpu.
AES and RC4 on the other hand are symmetric ciphers. They just need some random number key to decrypt a message. So to brute-force a 128 bit cipher key you have to try most of the 2128 ~ 1038 different keys until you found the one that worked. So if you can check a trillion (10^12) keys per second it would take ~10^19 years before you've checked most of the keys. Note a 256-bit key would be 2^128 times harder to brute-force (take 10^57 years).
So when I log into a banking site and click on the https information in google-chrome I see:
Your connection to home.ingdirect.com is encrypted with 128-bit encryption.
The connection uses TLS 1.0.
The connection is encrypted using RC4_128, with MD5 for message authentication and RSA as the key exchange mechanism.
If I then click on the detailed certificate information, and go to the certificate field "Subject's Public Key" I see that they use a 2048-bit modulus (N the modulus of two large prime numbers).
It is not just the security of the encryption you should be concerned about but also its implementation. There are some attacks out there that circumvent ssl security altogether.
Blackhat Presentation on defeating SSL
SSLStrip software