By Bryan Bruns, Howard Jaffe and Trey Maust
There are many issues that you as a bank leader should incorporate into your decision-making process when your bank’s core platform contract is up for renewal and reconsideration. While there are many common themes, we encourage you to make your bank’s long-term strategic focus the primary lens you use in prioritizing and tailoring these considerations. For example: Are you planning to merge, acquire or sell? What kinds of products and services are on your road map? Where can you find greater efficiencies? What is your innovation strategy? What is your internal culture regarding change and tolerance for migrating to a new core provider?
Think of it like building a house: Some will simply hire a general contractor and have the house built to specification, while others will choose to act as their own general contractor. We recommend you review your bank’s capabilities—and desire—to manage all the technology products you need, both for today and beyond, before you decide which choice is right for you and your bank.
All these strategic questions require review, internal discussion and clear answers prior to entering negotiations with any core platform provider. Over the past year, our work with ABA’s Core Platforms Committee has helped us identify 10 critical considerations for contract negotiations to help you address those strategic questions.
- Length and term of the contract
Banks should consider all likely strategic initiatives that may be undertaken, including plans for any mergers or acquisitions, when agreeing to a core contract term. Remember to look for any auto–renew provisions.
The default term should match a bank’s strategic plan. While there is a trend toward shorter contract terms (as short as three years), each bank is unique in its strategic plan. The cost/benefit equation of longer versus shorter contract terms should align with strategic initiatives the bank is likely to undertake.
- Performance standards and service-level agreements
While there appear to be significant differences between the various cores, bankers consistently report difficulty in understanding, monitoring and tracking SLAs. As the technology ecosystem continues to change by incorporating more third-party interfaces, SLAs become more important. Banks should focus on clearer lines of authority with overlapping products, such as bill pay or remote deposit capture and online banking. Banks should also understand who has responsibility for meeting these service levels: the core or the provider of ancillary products and services.
SLAs should also be reexamined to address non-performance clauses and speed of implementation for new technologies. Clearly defined penalties should be delineated for nonperformance, missing new product or feature implementation deadlines and other key deliverables. Banks should insist that reporting for SLAs be standardized and provided to client banks routinely. As a point of reference, the Federal Financial Institutions Examination Council has guidance on SLAs with technology service providers.
- Exclusivity clauses
Given the marketplace expectation to provide new and ever-evolving technologies on a 24/7 basis, such innovation will require interfacing with more third parties. Banks should avoid or seriously consider the ramifications of executing contracts with exclusivity clauses or punitive provisions for accessing third-party solutions that compete with a core’s product offerings. The ability to independently select a best-in-class solution should not be constrained due to punitive interface fees or exclusivity clauses. Look for cores that guarantee:
- No or heavily curtailed interface fees to third-party providers.
- Ability to select best–in–class, whether that is with the core or a third party.
- Non-disclosure agreement language that allows for engagement of third parties or allows banks to discuss solutions with each other.
- Coterminous contracts
Many banks reported having various products, modules, or ancillary services with a single core that do not have consistent maturity dates. Admittedly this issue is being addressed by some cores better than others or is being addressed by savvy bank negotiators. The issue may ultimately resolve itself over time. However, non-coterminous contracts are still commonplace. Consequently, banks should take the default stance that all contracts be coterminous, unless a strong business case dictates otherwise. Be vigilant that all new contracts for ancillary services are coterminous with the master contract or do not extend the term of the master or other agreements—unless this is an intentional decision on behalf of the institution.
- Deconversion fees
Merger and acquisition plans—whether as a buyer or a seller—can be significantly shaped by deconversion fees. Consequently, banks should give careful consideration to these provisions and focus on cores that offer:
- Declining costs for follow-on deconversion file sets.
- Reduced or eliminated costs if an acquired institution is also with the same core platform.
- Clear articulation of and formula for all deconversion fees.
- Fee payable upon file delivery.
- Time and resource fees only.
- No cost to access the bank’s data.
- Open and accessible APIs
Application programming interfaces allow banks to build business applications with communication to the core; allow faster development on non-core primary applications; and provide a user functionality not unlike Apple’s App Store. Banks should focus on cores whose API offerings are clearly described in their contract and include, among other terms, the following:
- Complete, modern API layer across the entire solution relationship, not just the bank core.
- APIs that are well–documented, readily accessible and developed in such a way that modern development standards can easily consume.
- Access to APIs for internal development opportunities.
- Ability for third parties to register for access, develop to the specification, then test and promote development into a production environment
- Third-party partner engagements that are not impeded by core resource requirements.
- Clear description of costs, if any, to access data through the API.
- Delineation between internal (bank) and external (third-party) APIs.
- Data access
A community bank should discuss data ownership and access with its core. Depending on the contract terms, bank data may be the property of the core or the bank. Careful consideration should be given to executing any contract with a core that does not allow for ready access to data for the bank to use for reporting, mining, and analysis. Additional data-related considerations include:
- How the bank is able to access all customer-related and derivative data and whether there are any fees for such access, which is not uncommon with legacy architecture.
- Whether or not to execute a contract with a core that is unable to provide a complete customer profile, including transaction data and ancillary products. Often this results from account information and records being maintained in separate application files, which were never intended or cannot be readily accessed by the core or its reporting system.
- Requiring itemization of costs associated with reporting tools.
- Limitation of liability and indemnification
Provisions regarding limitation of liability vary significantly among the cores. Most contracts begin with one-sided limitations in the early stages of negotiations, with the success of negotiating reciprocal provisions varying significantly depending on the bank. Provisions that are often a point of contention relate to the limitation of liability regarding gross negligence and/or security breaches on the part of the core as well as subcontractors of the core and other third parties.
- Termination penalties
Termination provisions should be reviewed thoroughly prior to executing any core contract. Associated costs should be readily calculated, and triggers for such costs should be easily identifiable. Consideration should be given to clear itemization within the contract of deconversion fees, early termination fees, exit fees and length of notification so there are no surprises later.
- Software ownership/assignment
Banks should take care not to execute a core contract that triggers a termination, a fee, and/or does not readily permit the license to transfer to a successor upon change in control.
Bryan Bruns is president and CEO of Lake Central Bank, Annandale, Minnesota. Howard Jaffe is president and COO of Inland Bancorp, Oak Brook, Illinois. Trey Maust is executive vice chairman at Lewis and Clark Bank, Oregon City, Oregon, and CEO of Sheltered Harbor. The authors are members of ABA’s Core Platforms Committee, and all three are past or future chairmen of ABA’s Community Bankers Council.
