The business of operating a bank has long since expanded beyond serving customers and managing a balance sheet. These days, bank management spends considerable time overseeing and negotiating with key vendors – a dance that has only become more complicated in recent years. In this upcoming article series, we will provide insights regarding third-party risk management throughout the lifecycle of a bank’s relationships with its critical vendors.
Our first installment concerns operational considerations to keep in mind when negotiating vendor agreements. It is all too easy to get wrapped up in the pricing and forget to address some of the items crucial to the day-to-day implementation of critical vendor relationships.
1. How does the agreement fit within your overall relationship with this vendor?
If this agreement represents an additional product purchased from a current vendor or an add-on to an existing agreement, how does everything connect? Can products be consolidated under a single master agreement? Consider making all agreements in the relationship coterminous, and review to ensure key terms negotiated for one product are carried over to any other applicable agreements.
2. How does the agreement fit with other third-party vendors and other external factors?
If the software or services provided will integrate with or depend on products provided by another third party, confirm the products (and the vendors) will be compatible. Be sure to hammer out any issues regarding confidentiality, technical support, and liability with both vendors in advance.
Conversely, if your bank will be converting services from one vendor to another, start the conversation with both vendors early to confirm any timing and logistical considerations. Is there a meeting of the minds regarding test files and data formats (and have these expenses been pre-negotiated)? And remember, vendors often require confidentiality agreements be signed in advance of releasing any information, which can take additional time to negotiate.
3. How does the license work?
If purchasing a product that will be used by multiple legal entities, such as a bank and its holding company or multiple affiliate banks, review the contract and discuss any enterprise-wide usage needs with the vendor. The fine print in many contracts specifies that any licenses cannot be transferred or used beyond the named contracting entity, so banks should be careful to avoid any accidental violations by reviewing and negotiating these provisions in advance.
Similarly, if multiple employees will need access or unique logins to use the product, ensure the contract (and the pricing) allows for the appropriate number of authorized users.
4. Is sufficient training provided?
Some software products are complex and require thorough training of bank staff prior to implementation. Not all contracts clearly address the vendor’s training obligations on their face, so bankers should discuss this with vendors early on and ensure training resources are properly allocated and memorialized in the agreement. In addition, training expenses are sometimes hidden in lengthy contracts, so it is important to confirm which party will be responsible for which costs.
5. When are payments due and how will they be made?
Payment terms and timing often vary by product. Will anything be owed up front? If any significant implementation or development must be undertaken before the product will be usable, consider negotiating for any large payments to be due upon completion of such implementation rather than upon execution of the contract.
Similarly, how will ongoing payments be made? Many contracts include a (sometimes buried) requirement that monthly payments be made automatically via ACH. If the bank prefers to receive and review an invoice prior to paying, this should be discussed with the vendor.
6. What are the timeframes for implementation?
Most agreements for significant software and services require some lead time between signing and the go-live date to allow for implementation and customization. If your bank has expectations or deadlines regarding when the services will be available for live use, this must be discussed in advance.
In addition, the agreement should provide for at least a basic timeline for development and implementation. Banks must remember to approach timelines realistically and be sure to memorialize implementation milestones for the vendor in the agreement.
7. Does the agreement require exclusivity?
Contracts for certain types of services often contain exclusivity provisions that prohibit the bank from contracting for similar services with other vendors. In such cases, bankers should take careful stock of other contracts to confirm there are no conflicts. For example, if a contract covers the entire enterprise, will any subsidiaries use a different vendor to provide the same services (for whatever reason)? Similarly, does the bank have any needs this particular product cannot meet, thus necessitating a supplemental product from another vendor? Vendors are often willing to accommodate such situations if they are negotiated up front.
8. Were any key terms discussed that are not reflected in the agreement?
Too often, parties decide certain terms of the relationship via phone or email and walk away assuming those decisions have been put to bed, only to find out down the road that those agreements have not been honored. It is critical to remember that anything not written within the four corners of the contract may not be enforceable.
Vendor Contracts 101 Series
Featured Professionals
Professionals
612.492.7218
