I have found this to be true over and over again. Maybe it’s just my line of work.
Part of my regular practice is being called in by the transactional lawyers (paper pushers) as they paper up a new loan or re-fi. My job in those situations is to give my thoughts on what will happen should the worst occur (eg, default, receivership, bankruptcy, lawsuit, etc.) and how to minimize the risks to the lender.
Often times, identifying potential fraudulent transfer exposure on the front end is of concern when the lender creates some type of relationship with a non-borrower affiliate or insider of the borrower. The usual situation is a guarantor, but other situations exist such as payment from a non-borrower affiliate. A recent 5th Circuit case discusses such a situation.
The Background – Skip this if you are Familiar with Fraudulent Transfers
There are a few types of “fraudulent transfers” under both federal and state law. Generally speaking, however, a fraudulent transfer occurs in two ways:
- When bad guy transfers something of value to the other guy in exchange for something that is less than reasonably equivalent value. Think, cow for the beans. Or,
- When the bad guy transfers something to 2nd bad guy in an out-and-out fraudulent scheme.
I have oversimplified it to fit into a minimal of bullet points. The gist is to recover value when the transferor (sender) transfers value to another party when the transfer would reduce the overall value of the transferor. The underlying idea being that other creditors need protection from a transferor sending all its assets to his buddy in exchange for minimal or no value in order to defeat collection by other creditors.
Many of you have already had to deal with this issue in lending. For the un-litigated, this arises for lenders in situations where the bank is receiving payments from a non-borrower on account of an existing loan. In that situation, the bank may be receiving money (the value) but not giving anything back to the non-borrower in exchange. (In a normal repayment, the funds paid by a borrower credit the debt, thus equivalent value exchange).
The Recent Ruling – The Netting Effect
In the case of a lender who is taking funds from a non-borrower in good faith, there is some protection when sued for fraudulent transfer under the bankruptcy code. This was the issue recently discussed in Williams v. FDIC in the Fifth Circuit.
At issue was what happens when a unknowing lender has received a fraudulent transfer from a non-borrower because of actual fraud, but the non-borrower transferor actually received some (but not full) indirect benefit. Specifically, the non-borrower affiliate company directly paid the mortgage payment to the lender on commercial property as “rent” thereby staving off foreclosure on behalf of the building owner (who was the borrower).
In this case, the Fifth Circuit said that the good faith lender is liable for fraudulent transfer, but the lender was only liable for the net amount received greater than the benefit obtained by the transferor.
- Ex: Lender was paid $100. Non-Borrower transferor obtained $70 in value. Bank is liable for $30.
Why is this important? The lender need not be a party to a fraudulent scheme to get tagged with a fraudulent transfer lawsuit. In that situation, even if the lender can show that it exchanged reasonably equivalent value (the normal bank defense), if the payment was part of an actual fraudulent scheme the bank had no idea existed – the bank will still be liable for the “net” positive it received over the transferor’s “net” negative.
This type of risk is, of course, inherently difficult to quantify. A valuation of the unknown benefit is obviously a difficult proposition on the front end. This remains true at the time the lender determines to accept payment from the non-borrower. Additionally, the retrospective value determined may not always be the prospective value anticipated.
Just something to think about when you are assessing the risk of accepting funds from non-borrowers and looping in insiders and affiliates to the obligation stack.