Using READ UNCOMMITED as a transaction isolation level is equal to using WITH (NOLOCK). As a result, you run the risk of reading an uncommitted row that is later rolled back, i.e. data that was never entered into the database. As a result, while it can avoid reads from being slowed down by other activities, it also poses a danger. It's probably not going to be the proper solution to whatever problem you're attempting to address with it in a banking application with high transaction rates, IMHO.
The question is whether a stalemate or an incorrect value is worse.
Deadlocks are significantly worse than incorrect values in financial databases. That may sound backwards, but bear with me. DB transactions are often used to update two rows by removing from one and adding to the other.
Business transactions are used in a financial database. That implies each account will have one row added to it. It's critical that these transactions finish and that the rows are correctly written.
It's not a major concern if the account balance is momentarily incorrect; that's what the end of day reconciliation is for. And an overdraft from an account is significantly more likely to occur as a result of two ATMs being used at the same time than as a result of an uncommitted database read.
However, SQL Server 2005 solved the majority of the problems that necessitated the use of NOLOCK. You shouldn't require it unless you're using SQL Server 2000 or older.
