About the author

Dan is a specialist FinTech lawyer advising both fast-growth and enterprise clients in the financial technology sector on their commercial negotiations and regulatory obligations.

Dan is also our managing partner and oversees our enterprising client technology partnerships. He is committed to delivering faster, more accurate and better value legal services to all our clients.

This post is an extract from our comprehensive white paper, “FinTech PaaS & SaaS Cloud Deployment Checklist: 12 critical legal considerations for providers of PaaS and SaaS FinTech solutions deploying in the cloud”, which is available as a free PDF download here.

Service level agreements (SLAs) and related service credits have traditionally combined as the first line of remedies for customers in cloud-based as-a-service agreements.

This post considers SLAs in agreements for the provision of FinTech platforms-as-a-service (PaaS) or software-as-a-service (SaaS).

SLAs may be used alongside, or interchangeably with, key performance indicators (KPIs). In some agreements, failure to meet SLAs and KPIs will trigger different remedies, in some agreements only KPIs are mentioned and themselves trigger service credits. As with many elements of contract, the label is largely immaterial; it is the substance we are interested in.

In this post, we use the term “SLAs” as a general catch-all for capturing a level of performance expected by a customer; an objective way of monitoring key elements of a service.

Where SLAs are missed, a service credits regime typically provides a financial mechanism for compensation to a customer prior to resorting to formal dispute resolution procedures.

SLAs and service credits may stand alone but are typically adopted as a dual regime. For a discussion on service credits in FinTech cloud agreements, see our recent post, Service Credits for FinTech.

It is critically important for both parties that SLAs are carefully considered and suit the relevant use case and surrounding circumstances.

Typically, SLAs (and related service credits) should only be applied to core deliverables that a customer considers critical to successful service delivery.

A good rule of thumb, in well considered agreements, is to include between five and 15 SLAs, each with relevant KPIs sitting underneath them.

Increasingly, given some of the related downfalls of a penal service credit regime, there is a tendency to move away from simple service level and service credit regimes and instead to develop more creative mechanisms for overseeing the success of the arrangement as a whole.

General categories of SLAs

The nature of the service being measured should dictate the SLAs employed. SLAs may include the number of invoices issued or the average time for the processing of a successful trade or transfer in any given period. Typically SLAs are thought about in three categories.

  • Continuous SLAs measure a steady state over a given period, such as service availability, uptime or latency.
  • Event SLAs measure the extent to which a series of the same actions are performed over time, such as successful transfers or trades processed.
  • Sample SLAs measure whether a sample of items meets the intended standard, for example the accuracy of entries in an asset registry.

    It is critically important to ensure that the correct questions are considered when first drafting SLAs. Example questions should address: how to define each element of the SLA (for example, what does availability mean?); what the service window in which SLAs are measured looks like; what tools are used to measure performance and how those tools function.

    Setting the relevant standards may rely on existing performance levels (for outsourcing existing services), benchmarking market standards or by reference to initial performance for a novel service.

    It is also critical that SLAs can be accurately measured and providers will want to ensure they have control over outcomes and are not penalised for failures beyond their control, which may include anything from network transmission failures to KPI sample sizes being too small.

    Drilling down into SLAs typical in FinTech PaaS and SaaS agreements, there are typically also regulatory considerations, for example, under the Financial Conduct Authority’s FG16/5 Guidance for firms outsourcing to the cloud and, for those providers with operations across Europe, the European Banking Authority’s Guidelines on outsourcing arrangements and the incoming legislative proposal for a European regulation on digital operational resilience for the financial sector, the Digital Operational Resilience Act.

    The more careful thought that goes into crafting SLAs, the more benefit is gained for both parties, since SLAs tend to constitute the front lines of day-to-day contract management. An experienced commercial and financial services lawyer can make a big difference in helping both parties think through and craft their SLAs more carefully.

    Service availability SLAs

    A typical example of a continuous SLA is a measure of service availability. Service availability SLAs will typically be measured as a percentage of time a service is available for use, but some considerations are critical.

    • Point of measurement – When agreeing to availability SLAs, providers must consider where availability is measured (providers’ servers, cloud termination point, end users’ PCs). The parties may be limited by where measurements can feasibly be taken. Measurement at end users’ PCs, for example, may subject SLAs to transmission and network shortcomings that are not under the control of the provider. Where a customer insists that measurement is made at end users’ PCs or cloud termination points, a provider may insist, for example, on leased line linkages to ensure smooth transmission networks.
    • Latency – Where a customer insists on latency-based SLAs, providers are well advised to split SLAs across specific elements of the service applying suitable measurements to each element. For example, print processing or file saving via the cloud may take much longer to process than other tasks, depending on the location of servers.
    • Application availability – Where multiple applications are delivered, it may be helpful to make service availability SLAs application-specific.

    System and incident response SLAs

    An example of an event-based SLA typical in FinTech deployment is a system or incident response SLA, measuring how readily a provider responds to user requests or incidents. This type of SLA is heavily reliant on the type of activity measured.

    • Helpdesk responses – Providers must segregate commitments to response times for different types of communication and relating to different priority events. Often a scale is adopted to differentiate between priority levels for certain types of incidents, for example “Priority 1” (or P1) through “Priority 4” (or P4), with a series of email and telephone response times and resolution expectations mapped across priority levels and request types. The specific wording defining each priority level is critically important.
      • Service measurement – When framing system or incident response SLAs, the times of day and days of the year to be measured are critical. Commitments measuring responses 24-7 or during weekends and bank holidays will lead to unfairly skewed outcomes if the service is only under use from 8am to 6pm on business days. Of course the approach taken depends entirely on the customer’s intended use of the service.

      Infrastructure minimum requirements SLAs

      Minimum infrastructure requirements are frequently requested by more sophisticated customers and are typically required by regulated customers in the financial sector.

      Infrastructure SLAs relate to the capacity of a providers’ cloud infrastructure. Regulated customers will often require a FinTech cloud provider to procure new equipment and infrastructure where infrastructure capacity falls short of their requirements, particularly in relation to their regulatory obligations, for example to the FCA and/or under data protection regulations.

      Well-prepared customers may also seek due diligence information on a provider’s historical infrastructure performance statistics and seek warranties on minimum specifications.

      More progressive and advanced SLA models

      The current trend is toward service levels more carefully measuring the customer’s (or its end user’s) experience.

      More advanced SLAs might compound two or more performance standards or KPIs to create a multi-tiered SLA, for example requiring that 90% of trades are processed within 10 seconds (tier 1), but that 100% of trades are processed within 30 seconds (tier 2).

      Alternatively, two performance standards can trigger different outcomes. For example a “minimum” or “critical” performance standard might trigger service credits if missed whereas a target or stretch performance standard might trigger a bonus or incentive. This carrot and stick effect, where carefully directed, can have an excellent impact on service delivery whilst also managing risk for both provider and customer. Compounded SLAs can also be adopted with a sliding scale of service credits for increasingly egregious breaches.

      More broadly, it is important to understand and carefully balance the wider contractual regime including SLAs, service credits and bonuses, damages claims and termination rights for persistent breach. Each element of the contractual redress regime needs to be carefully balanced to produce the correct combination of remedies and incentives for each party. Experienced legal advisors can help contracting parties to evaluate and negotiate the correct options.

      About Clearlake

      At Clearlake, our commitment is to combine premium quality service and unrivalled value such that we give our clients a competitive advantage when entering into new arrangements with their customers and suppliers.

      Please feel free to reach out directly to the author of this post, Dan Stanton, on dan.stanton@clearlake.law or 0204 570 8741.

      This post is an extract from our comprehensive white paper, “FinTech PaaS & SaaS Cloud Deployment: 12 critical legal considerations for providers of FinTech PaaS and SaaS solutions deploying in the cloud”, which is available for download as a printable PDF here.