Consumers set high standards for businesses, especially financial institutions. Money is a sensitive topic with little, if any, margin for error — people expect transfers, transactions, account management, or whatever other services to be timely and precise. 

In turn, you have to hold your core IT provider and fintech suppliers to an equally high standard. Otherwise, your business could be at risk. 

To do so, your vendor contracts’ Service Level Agreements (SLAs) must be tight, relevant, and enforceable. But there’s a common problem plaguing the financial services industry: most contracts don’t have real SLAs. Instead, they have Service Level Objectives (SLOs).

You might think you have SLAs in your contracts. In reality, you probably have loose-ended and unenforceable SLOs. Unfortunately, most community banks and credit unions don’t have the resources or know-how to counter the technical expertise of IT suppliers. We want to change that, so we’ve outlined these two contractual mechanisms to help you identify real SLAs and fake SLAs. 

First, we want to underline the significance of SLAs by sharing a real, worst-case example.  

What Happens When You Have SLOs Instead of SLAs?

The calendar year was coming to a close, so a bank sent annual account statements to its 20,000 customers. Unbeknownst to the bank, its processing supplier made a monumental printing mistake: the statements were sent not only sent to the wrong customers, but the back of each statement also included another customer’s statement. 

That’s a major Gramm-Leach-Bliley Act (GLBA) violation. 

The reputational damage was catastrophic. It took the bank hundreds of hours of customer support to repair the disastrous fallout. 

But here’s the kicker: although the supplier admitted it was at fault for this egregious error, the contract’s SLAs — which were written 10 years prior — didn’t outline a financial penalty for GLBA violations. When the bank went to the supplier for financial compensation, the supplier claimed it was simply a postage mistake and offered the bank $0.19 for every customer that received the wrong statement.

That’s chump change relative to the incalculable reputational damage suffered by the bank. 

Naturally, the bank didn’t accept this paltry remediation and threatened to sue the vendor. Fortunately, this got the vendor’s attention; they settled at $65,000. 

Well-structured SLAs would’ve entitled the bank to immediate financial compensation, instead of having to threaten the vendor with a lawsuit to accelerate the process. This is just one example of why SLAs are vital to your business.

What Are SLAs? 

In order to identify fake SLAs in your contracts with core IT providers or fintech vendors, you must first understand what SLAs are supposed to be. An SLA is a commitment from your supplier to perform an important service at a quantified level. In short, it’s a guaranteed standard of performance. 

SLAs must be thorough, capturing all aspects of the service in question. For instance, they should clearly define what’s being measured, how it’s measured, how often it’s measured, what the acceptable range of service quality is, and how you’re compensated in the event service quality falls short. If SLAs don’t do one or more of these things, then it’ll be nearly impossible to rectify issues when they arise. 

If the vendor misses the mark, your institution should receive a compensatory credit. The credit should be just large enough to get the attention of the vendor’s management so that they fix the issue immediately and improve the process going forward. 

If the vendor continues to fall short of the predetermined standard, you should gain additional rights — such as an even higher financial credit and, eventually, the right to terminate the service or the entire relationship without incurring a termination fee. This is the definition of holding your providers accountable — this is what an SLA is supposed to accomplish. 

What Are SLOs?

SLOs are subjective commitments to perform services, which may or may not be relevant to your bank. They’re guarantees of “best effort,” which isn’t really a guarantee of anything. Here are a few other identifiable aspects of SLOs:

• Processes or functions that aren’t necessarily critical or easily measured
• Undefined processes that are open to multiple interpretations
• Lack of compensatory credits in the event of performance misses
• Lack of additional rights in the event of performance misses

For instance, a common SLO is a commitment to 99.9% uptime. Who cares about that? How does that hold a vendor accountable? 

What if that 0.1% is at the wrong time of the month when your transactional activity is at its peak? It’s debilitating to your franchise and the vendor can point to the contract and say, “We don’t owe you anything,” because the commitment has vague performance parameters. 

When you have SLOs and a system goes down or a process gets disrupted, the onus falls on you to fix the problem because your SLO doesn’t hold the vendor accountable. You aren’t entitled to recourse — you’re just entitled to redial the vendor over and over again. They’ll escalate the problem eventually or they’ll organize a dedicated committee to help solve the issue, but it could take months to clear various bureaucratic (and intentional) hurdles. They aren’t incentivized to do anything but delay, delay, delay. Meanwhile, you aren’t compensated for the time-consuming burden and headache — not to mention the potential reputational damages incurred from business interruptions. 

SLOs force financial institutions to beg for compensation. Obviously, it shouldn’t be this way. You’re paying for a service, and your provider should fulfill that service according to the predetermined parameters in your contract. Or else you should receive financial compensation and additional rights. 

That’s why you need thorough SLAs. 

How to Develop SLAs That Have Teeth

SLOs don’t hold providers accountable because they don’t have any bite to them. SLAs protect your business from damaging interruptions because they have teeth. So, here are four steps for developing legitimate SLAs:

1. Determine your goals and set a standard. What are your strategic goals? You’re paying for this service, so your SLAs should be written from your perspective — not the vendors. 
2. Outline the activities required to reach these goals and maintain standards. What does your vendor need to do to ensure everything stays on track? A common cybersecurity example is periodic security assessments to ensure personal information is protected.  
3. Make these activities measurable. For instance, if you have critical systems that must remain online and functioning to meet your customer’s needs, you can quantify this goal with transactional volume activity. 
4. Hold your providers accountable. Remember, without financial ramifications, your vendor isn’t incentivized to fix the issue. 

SLAs need to be comprehensive because vendors will exploit any holes in your contract. If you want to avoid inadvertently agreeing to SLOs, we’re here to help.  

Call in the SLA Reinforcements

When you negotiate against these core IT providers and fintech suppliers, there’s no way to know the game better than them. It’s a technical, highly nuanced subject. This is their area of expertise. 

Consider Paladin fs to be your contract reinforcements. Collectively, the Paladin team has decades of experience negotiating SLAs for community banks and credit unions. We’ve helped hundreds of institutions avoid unfavorable contracts while saving them hundreds of millions of dollars in the process.

If you’d like to learn more about renegotiating your existing agreement or negotiating a new business arrangement, connect with us today.