The question title and body ask two different questions, so I will attempt to answer both.
Should I be concerned?
No, not really. If the allowed characters are
[a-zA-Z0-9], that means you have
62^33-1/(62-1) different possible passwords. This gives you a strength of 191 bits, which is more than enough to be uncrackable on modern hardware.
If your password is generated randomly and only used for this service, then even if the password is stored in cleartext, you should be relatively safe. To my knowledge, the overwhelming majority of online banking requires a second factor to authorize transactions, so without that second factor, criminals would not be able to steal funds.
Does this mean passwords are stored in plain text? Or is there another possible reason for this restriction?
Legacy code and cargo cult programming.
It is possible that earlier systems did indeed store passwords in plain text in a
VARCHAR(32) field, and several components verified that the password is not longer than 32 characters. Even after the system was changed to use hashes and salts, the restriction is still in place, because most users don't pick good passwords. I am convinced at least some people have
November2020 as their password, and I am convinced at least one person reading this very answer has that as their password for something.
Most people just don't care about secure passwords, or think that this is a secure password, when it's obviously not. And since most users don't care, the bank never saw a reason to change.
The second reason is a form of "We've always done it this way", called "Cargo Cult Programming". Simply put, someone did something for a valid reason, and other people copied this behavior without understanding the underlying reason for it. After a while, this was just accepted as "how we do things", whithout understanding the underlying reasons, which may no longer even apply.
In summary, generate a random 32 character password, store it in a password manager and you will be safe.