“All That IT Gibberish” – Part 1: Frequently Overlooked Technology Provisions in Vendor Agreements and Why They Matter

"Can you please review this new contract the Bank is considering?” a bank CFO recently requested. “All that IT gibberish is over my head. Just make sure we’re not signing anything risky.”

The business of community banking has become increasingly reliant upon third-party resources, chief among them: software. Software is responsible for producing loan documents, balancing customer accounts and the general ledger, managing interest rate risk, monitoring for suspicious activity, and countless other critical daily activities. There is no doubt that partnerships with vendors make fast, customer-friendly banking possible, but they also expose banks to a whole new world of risk and liability. Banks need to ensure the products (and vendors!) in which they invest will operate reliably, compliantly, and safely – and that the bank’s rights and remedies are preserved in the event the products fail to do so.

Most bankers have no trouble identifying and negotiating the “big ticket” items when reviewing contracts: term, pricing, early termination fees, and the like. However, today’s contracts also include a host of information technology (IT) and intellectual property (IP) provisions, with unfamiliar jargon and complex phrasing that cause confusion, intimidation, and frustration even for experienced bank IT managers. As a result, these provisions are sometimes dismissed as “boilerplate,” “IT gibberish,” or less important than those big ticket items. Don’t be fooled – failing to appreciate and negotiate these provisions can bring a storm of problems, including financial liability, lost business, and regulatory criticism. Part 1 of this article highlights five of the most commonly overlooked IT/IP provisions and considerations for banks as they review and negotiate these items.

1. Understanding How the Vendor’s Contract Model Works Today and Tomorrow

There is no one-size-fits-all contracting model when it comes to software. Even when a vendor presents their standard terms as their one-size-fits-most, the pricing schemes are limited only by the imaginations on both sides of the transaction. Keep in mind that what fits operations today may not fit as comfortably tomorrow. Understanding the license model impacts not only the business terms of the deal (those big-ticket items banks are comfortable with!), but also the legal risks.

How is the use of the application limited? Is the license node-locked, tied to specific machines, or subject to user authentication for a limited number of total or concurrent users? Can the bank reassign user IDs? Is the software charged on a usage or consumption basis? Are all features included or are certain functions available only at higher pricing? How does the vendor audit for compliance?

Savvy bankers should consider how they anticipate using the software and seek to limit the vendor’s ability to suspend or terminate the license for exceeding usage limitations.

What is the vendor’s obligation for providing updates? Does the contract even mention updates or upgrades? Is the license perpetual for a specific version, with updates subject to additional fees? Is the license subscription-based with maintenance and support included? How long are outdated versions supported? Are all updates retro-compatible? Can the vendor stop offering any major function that the bank is relying upon? Will features be updated to comply with changes in the law or regulations?

Bankers should be wary of contracts that do not mention updates. Especially for perpetually licensed on-premises software, careful attention should be paid to the cost of maintenance. If the software will have functionality that needs to comply with current legal requirements (particularly where customer-facing), the vendor should be obligated to keep the functionality compliant, and the contract should define who is responsible for the associated expenses. At a minimum, banks should ensure the vendor is obligated to provide continuous updates to maintain the functions, features, and security of the application.

What level of customization or implementation effort is required? Will the application be heavily customized, white-labeled with the bank’s branding, or used as an “off-the-shelf” solution? If the application will be tailored to the bank, does the contract adequately describe the acceptance/testing procedures and how customizations that fail the acceptance process are addressed?

Unless an application is used on an “off-the-shelf” basis, contracts should appropriately address professional services warranties and remedies. Contracts involving substantial front-end development should give the bank appropriate “outs” for poor performance or repeated failures to meet established milestones, deadlines, or the bank’s specifications.

2. Tech Support – Who Are They Gonna Call?

Financial institutions should define what types of support are expected from the vendor, whether for internal end users or the bank’s customers. The vendor’s technical support team may be barred from speaking directly with or accessing customer accounts, putting bank customer service personnel in the middle of technical support issues. Additionally, banks should be particularly aware of how IT vendors and their support personnel may access or come into contact with customer data, and what procedures the vendor follows to ensure it has appropriately screened support personnel. (More on data privacy and security as a cost of doing business in our next article!)

Banks should clearly articulate expectations with regard to who may contact customers directly, and how. Vendors who access or come into contact with customer data should have obligations to vet personnel and take ownership of (and liability for) mishandling customer data.

As a part of setting tech support expectations, has the vendor provided standard service level agreements (SLAs)? Which party gets to set the severity level of an incident? How often will the vendor communicate status updates? What happens if there is (or isn’t) a feasible work-around?

Where vendors provide no SLA expectations, an experienced technology lawyer can easily provide a basic framework for classifying incident severity levels and target response and resolution times. In any event, technical issues affecting multiple or all users should be clearly prioritized over one-off requests and require affirmative commitments by the vendor to work continuously toward resolution.

3. Set Your Exit Strategy Before You Start

Changing core technology systems can be expensive and time-consuming and may require the cooperation and assistance of the prior vendor. Without a contractual obligation to provide assistance, other than the chance of reconverting the customer in the future, the outgoing vendor has little motivation to prioritize any technical assistance for a customer whose contract is ending. Additionally, if a new technology system has significant set-up costs, consider appropriate termination rights for delays and cost overruns.

No one likes to think about the worst-case-scenario or the eventual end of the relationship when negotiating a new contract. However, the transition out of a relationship can be as important as the initial negotiation. If a bank will need the vendor’s assistance in deconversion, make sure the contract provides for this type of assistance and expectations regarding costs.

4. Third-Party Plug-ins/Add-ons

Integrating multiple applications can help automate repetitive data entry and lookup procedures. Technology vendors may offer integrations by reselling third-party components as part of a packaged deal. Most vendors will attempt to disclaim liability for third-party components or hold the bank responsible for compliance with the third party’s terms and conditions. Do not allow vendors to pass the hot potato back and forth.

Banks should seek to limit the applicability of any unknown terms and conditions and require vendors to be liable for any third-party components distributed by the vendor.

5. IP Infringement – Reasonable Indemnification and Remedies

Software contracts should always include indemnification obligations against third-party claims of IP infringement. This one is that simple. The bank should in no circumstances be liable to a third party that claims the bank’s use of the vendor’s product violates the third party’s IP rights. A savvy vendor will offer this indemnification (with limitations and specific remedies) in its standard terms and conditions.

Practically speaking, the problems that can arise from inadequate IT/IP provisions can be significant and include:

Financial Losses. The most obvious risk to a bank regarding vendor contracts is financial. Operational problems or delays can be expensive, and no bank wants a surprise invoice for functionality or updates believed to be already included. A poorly-drafted contract can result in costly breakup fees to escape a poorly-performing vendor. Conversion to new systems is expensive and time-consuming, and, particularly when customers are impacted, operationally challenging.

Regulatory Issues. The FDIC, the OCC, the Federal Reserve, and the CFPB have all issued guidance concerning their expectations for banks’ oversight of third parties, including specifically third-party technology providers. Regulators expect to see certain protections for the bank and customers built into vendor contracts, including with respect to liability, vendor performance and expectations, regulatory requirements, and licensing of IP. Failure to properly negotiate these can result in regulatory criticism of management and risk oversight, or even larger compliance issues. And remember, regulators can (and will) hold banks fully liable for the actions of third parties. Trusting a third party with the bank’s compliance obligations means taking full responsibility in the event something goes wrong.

Reputation Issues and Loss of Customers. Convenience and experience are high priorities for many customers when choosing a bank. Bungled statements, frequent or confusing changes to financial tools, or difficulty accessing online and mobile banking applications can quickly drive customers away. Particularly in this age of prolific social media, an unsatisfying customer experience can cost a bank more than just a single unhappy customer.

These problems are not just hypothetical. Examples of IT/IP struggles we have seen are many, varied, and frequent. One bank struggled through recurring problems with printing, delivering, and uploading electronic versions of account statements that frustrated customers for months. Multiple clients have experienced difficulties integrating third-party applications into other programs or suffered costly delays in rolling out programs due to insufficient project timelines or testing procedures. In one case, disagreements over liability for early termination and deconversion fees resulted in the bank’s data temporarily being held hostage, significantly delaying conversion to a new system. These situations highlighted the contract provisions the bank could turn to for recourse, as well as those (or the lack thereof) that worked to the bank’s detriment.

Third-party vendors are integral to the community banking industry and can be fantastic partners in building your brand and making your bank more profitable. While not all problems can be predicted or avoided, taking the time to thoroughly review and negotiate IT/IP provisions in contracts on the front end could save your bank considerable time and money (not to mention headache) on the back end.

But wait, aren’t confidentiality and data security some of the biggest IT/IP concerns for banks? Watch for Part 2: Confidentiality and Data Security in our March 2020 newsletter!