You might consider using a config file of some sort to store the username/password information. Then if, for whatever reason, you decide to put the module on CPAN, make sure that:

1. Your own personal config file does not go into the distro
2. There are clear instructions in the installation docs for the module that make it explicitly obvious to the people who install it that they must provide their own username/password info in the config file in order to run tests.

But then, I think there's still a dilemma. Supposing I wanted to install your module in order to access my own personal bank account (assuming the unlikely possibility that I have an account at the same bank as you, so that everything should work as expected), I don't know how willing I would be to run tests to make sure the module works as intended, using my own bank account as the test bed.

Somehow, that would seem like a bad idea, quite apart from the notion that my account information might be different enough from yours that it might be hard to anticipate what sorts of values and results should be expected.

An ideal solution, similar to what DBI does, would be if the bank would support a "test user" account with stable and reliable data that would always return the same values for the test conditions (unless the tests were failing, of course). But I assume the likelihood of any bank doing that for the sake of a CPAN contributer is nil. So much for the ideal solution.

All things considered, I don't think you can arrive at the appropriate "level of abstraction" to make this sort of thing viable as a CPAN package. You'll have enough to worry about just making sure it continues to work as intended for your own personal needs (as the bank "improves" its presentation strategies), so let that be sufficient.

(You asked for opinions; that's mine.)