As previous answers have already stated, there is no known technique to carry out a partial hash of a password and verify the string. The nature of unidirectional hash functions makes it impossible to verify if a password is similar to another, only that the passwords are identical. Therefore, it would imply that the bank has stored the passwords either using two-way encryption, by hashing the substrings, or (the horror!) as plaintext.
This technique actually has a number of benefits and drawbacks, contrary to the current opinions that this technique has no redeeming factors.
Compromise of bank passwords can take place in two ways, via hacking of the bank servers resulting in a hash leak, or via password compromise on the user's end (keyloggers, trojans, simple shoulder surfing, MITM attacks on SSH) etc.
Storing the passwords in a way that allows substrings to be retrieved allows a hacker who has gained access to the bank's database to easily obtain the plaintext passwords, even if they are extremely strong. If the bank used two-way encryption, a hacker who has gained access to the encrypted database would almost certainly be able to obtain the keys. If they hashed a selection of substrings instead, it would result in a case similar to the NTLM weak hashes which would make it easy to retrieve the plaintext passwords. The very small hash space of 3-5 characters (assuming a hash was used) would make reversal attempts trivial, even if a salt was used.
However, this must be balanced against alternative risks. A potential bank hacker who has gained access to only the victim's computer (and potentially also their 2-factor authentication token) would not be able to access the victim's bank account, since a different subset of characters from the password would be required.
Since the latter case of bank account security compromises are far more likely, it makes sense to a limited degree for banks to implement such hashing systems.