By Adam Atlas
Attorney at Law
Let's imagine an ISO that has done no wrong but whose processor simply stops paying or goes out of business. This is the worst-case scenario for every well-meaning ISO. They fret about this possibility before, during and after the term of their contracts – so long as residuals are payable.
If ISOs had no recourse for non-payment by processors, processors would probably stop paying more often than they do. Luckily, ISOs can take certain precautions, before and after execution of their ISO agreements, that can decrease the chances of a bad outcome from a processor that is either working in bad faith or simply going out of business. The purpose of this article is to provide recommendations that might reduce your chances, as ISO owners and merchant level salespeople, of losing everything due to a dishonest or failed processor.
Make no mistake, processors go bankrupt, so this kind of scenario has been seen in recent years and, sadly, could happen again. Today's stable of processors has been built on incredibly cheap investment capital from Wall Street and elsewhere; when Wall Street comes looking for its dividend, or when interest rates start going back up, investors in our industry will be looking for their dividends. When processors come up short, they lose their shirts, and ISOs sometimes pay the price.
Consider the following ideas when trying to reduce your exposure to risk of non-payment by your processor. These ideas will not be appropriate for all ISOs, and each should be combined with advice from your payments industry legal counsel and your own business common sense.
In 13 years of advising ISOs, I have concluded that the most efficient and reliable basis for ensuring long-term payment of ISO residuals (even with a distressed processor) is the honor and integrity of the individuals managing the processor.
Contracts are vital and necessary, but the integrity of the parties to contracts is a more valuable asset than the contract itself. For example, in a recent New York case, a distressed processor sold a portfolio of merchants without consent of the ISO that depended on that portfolio for income.
Setting aside the legality of the action, the processor did not extend to the ISO the courtesy of an opportunity to follow the portfolio and collect residuals from the new owner. Choose your processors carefully.
On a plain reading of an ISO agreement, a judge should be able to see that there is an unambiguous obligation on the part of the processor to pay the ISO an objectively defined quantity of money each month. Regardless of the type of ISO agreement you have, this is one of the primary obligations of the processor. When a processor stops paying or can't pay, the ISO's recourse will depend almost entirely on the contractual obligation to pay spelled out in the ISO agreement.
Let's distinguish between the right of a processor to terminate an ISO agreement and the right of the processor to also terminate residual payments to the ISO. These are two radically different outcomes and should be treated as such in the ISO agreement.
In short, the list of reasons why residuals can stop getting paid should be a lot shorter than the list of reasons why the agreement can be terminated. To the extent an ISO is successful in shortening both of these lists, the ISO will be better served under its ISO agreement – in particular when the processor is distressed.
The processor's obligation to pay being contingent on its own revenue is common sense; however, it is less so when you consider that wrongdoing on the part of a processor can put an end to its payments. One way to tackle some of this risk is to oblige the processor to pay the ISO, even if the processor is not paid, provided that the ISO isn't in breach of the agreement itself.
Processors have a difficult time imagining earning no revenue (even if the halt is caused by their own wrongdoing) but nonetheless having to keep paying the ISO. On rare occasions, this undertaking can be achieved in an ISO deal negotiation, but the ISO should reflect on how truly useful a clause would be that makes a processor pay out on something for which it has no revenue.
Lacking in most assignment clauses is an undertaking on the part of the processor to require the assignee of its rights under the ISO agreement to honor its obligations to the ISO. One option is to add the following to your ISO agreement: "In the event that Processor assigns any or all of its rights or obligations hereunder, or in respect of Merchants, it shall require its successor in interest to assume Processor's corresponding obligations to ISO hereunder."
In plain English, this means that if the processor sells its business, the buyer should be made to pay the ISO.
You might ask what this has to do with processors that stop paying or go out of business. The connection with our topic is that a financially distressed processor is susceptible to having to sell the business. When the processor sells its business, that's a moment when the ISO wants to tag along and ensure it continues to receive payments by the new owner (also known as successor, in legalese).
An ISO lien on processor assets is both the best protection for the ISO and the hardest right for the ISO to obtain. When there is a lot riding on the ISO agreement and the ISO has strong bargaining power, the processor will occasionally grant the ISO a lien on its own revenue.
Bravo to any ISO that achieves this, as it is the very strongest protection against processor non-payment or collapse. The weakness in such liens is that courts are not always able to figure out who really owns a given residual. No surprises there.
In publishing The Green Sheet, neither the author nor the publisher is engaged in rendering legal, accounting or other professional services. If you require legal advice or other expert assistance, seek the services of a competent professional. For further information on this article, email Adam Atlas, Attorney at Law, at email@example.com or call him at 514-842-0886.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next