Home -> Law Blog Directory -> Federal Judiciary Blogs -> California Appellate Report

Federal Judiciary

: California Appellate Report

Stevens v. Tri Counties Bank (Cal. Ct. App. - Sept. 1, 2009)

By Shaun Martin

I've got plenty of joint accounts, not surprisingly. I've never really thought about them, which is also neither surprising or unusual, I imagine. I always thought the rule was -- as indeed it is -- that anyone who's listed on the joint account can withdraw whatever amounts they want. That's why you've got to trust 'em. Apparently there's also legal recourse if they withdraw more than their "share" -- which is good to know -- in order to stop, say, a departing spouse from taking all the money. In that case, the one owner would have a claim against the other owner for pimping anything beyond his or her "share" of the community property. But that's a fight for the respective owners to duke out. As far as the bank's concerned, everyone listed on the account is entitled to withdraw whatever they want. Makes sense.

But with that background in mind, let's get one level deeper. Imagine that X and Y have a joint bank account. Can Y add Z to this account without X's consent? Would the bank be liable to X if it permitted Y to do so and Z then took all the money out of the account?

This is a tough one for me. On the one hand, the nature of joint accounts is that you've got to trust your co-account owner. If you open a bank account with Y, you're taking the risk that Y will withdraw all the money, spend it on crack, and leave you with nothing. So if you've got to trust Y, then don't you also implicitly trust Y not to add Z to the account as well? What's the difference between Y adding Z to the account, who then takes all the money, versus Y taking all the money and giving it to Z? Why should the bank be liable to X in the first set of facts but not in the second?

On the other hand, trusting Y not to take the money does seem a little bit different than trusting Z. It might make sense to say that the bank can only let Y take the money -- which would leave Y liable for withdrawals in excess of Y's share -- but can't let Y add Z to the account and then have Z take the money, which may perhaps (if allowed) leave only Z (rather than Y) liable for any excess withdrawals. You trust Y, in other words, not to take the money, but you don't want to let 'em add an unknown Z without your consent.

Or at least that's perhaps the right default rule: the one that makes the most sense, but is one that the parties can contract around. Though I might even go farther and say that's the right rule, and one that can't be waived (though on that point I'm far from sure). What's the point -- the purpose -- of allowing Y to add Z without X's consent? What benefit does that create, especially since, as we already know, Y could already withdraw the funds to which s/he's entitled and give 'em to Z. Why let another potential tortfeasor into the account without the express consent of all holders? Seems to me that, as a protective measure, you might want to make that rule unwaivable, especially since we all know that if Rule X is waiveable, and potentially creates liability for the bank (here, for allowing Y to add Z), banks will probably insist upon waiver in a contract of adhesion, thus defeating the value of a default rule.

Those are my initial thoughts on the subject, anyway. Which are far more than are necessary to resolve this case, which simply holds that the actual law is that the bank can indeed be liable for allowing Y to add Z (who then withdraws all the money) at least when such conduct isn't permitted by the bank's rules.

Though, as I said at the outset, this isn't -- and wasn't -- a foregone conclusion, either as a matter of policy or (perhaps even more confusingly) as a matter of statutory interpretation in California. But it's nonetheless the law.

So think about that joint account. For at least a second, and for slightly more than the facile inquiry regarding how much is therein.

Full post as published by California Appellate Report on September 01, 2009 (boomark / email).