You can find pros and cons for everything. You mentioned wasting space in buffer cache with 32K block size. But at the same time we are talking about banking application where speed is of the primary concern. Well, I don't think any bank will have a problem investing few hundred or thousand $ in buying enough RAM if it realy wants fast responces from its database. And 32K blocks realy can improve performance compared to 8K because of much less I/O. Data is much more tightly packed in table blocks, and what is even more important - indexes will be much "flatter" with 32K, resulting in saving I/O with each and every query in OLTP system.

Bottom line: I don't find "wasting space in buffer cache" to be a realy valid argument against using larger block sizes. Simply invest few bucks and have larger buffer cache, and the problem is gone. But reducing I/O is a valid argument in favor of using larger block size. Larger blocks simply mean fewer I/O, particulary in OLTP where practicaly everything is accessed via indexes.