In order to support "partial passwords", the bank must necessarily store either the plaintext password, or at least some values that would allow fast reconstruction of the complete password. It is easily seen in the following way: when the bank asks for, say, the 3rd, 4th and 8th letters of the password, then there are less than one million possibilities (assuming that the "letters" are printable characters). Yet the bank can somehow decide whether the three provided letters are the right ones or not. Therefore, whatever the bank stores is sufficient to run a brute force attack on the 3rd, 4th and 8th letters, and that attack will succeed in less than a million tries.
The bank may add layers of encryption and hashing and whatsnot, this won't change that raw fact. Whenever there is support for "partial passwords", then there is very sensitive storage on the server side. In that sense, support for partial passwords decreases security, instead of increasing it. (It can be argued that partial passwords increase security on the client side: shoulder surfers gain only a partial view of the password. Yet you must be aware that this is a trade-off: more client-side security for less server-side security.)
To support full-password authentication, the bank must store something which is sufficient to verify a full password. The same reasoning as above applies, but for a brute force attack on the complete password, not on a partial password. If a bank supports both "partial passwords" and "full password" authentications, then it probably stores one of the following:
The full password in a "recoverable" format (plaintext, or encrypted with a key that the server knows -- that encryption being protection mostly against casual attackers on the bank side, e.g. underpaid interns).
A hash of the full password and hashes for all password subsets that the bank may ask to the connecting user.
The second possibility requires a lot more storage and implementation complexity on the bank side, so I deem it improbable. Developers of bank applications are no less lazy than their fellow humans.
Take note that your password is not your most sensitive asset entrusted to the bank. The bank holds your money. And the money is what the attackers are after. If an attacker completely hijacks the authentication server, he won't limit himself to grabbing encrypted or hashed passwords; he will immediately fake some successful authentication and trigger transfers. Who needs a key for a door when he is already inside ?
Discussions about encrypted or hashed passwords are relevant for partial breaches, e.g. when the attacker finds a backup tape for a database, or obtains a read-only view through some SQL injection attack. In that sort of scenario, what can be done by an attacker depends a lot on the subtle details of how things are implemented in the server, so it is hard to talk in all generality.
