Traditionally, an organisation seeking to use software to address a complex or unique business requirement would have needed to commission the development of a bespoke, customised software solution (either in-house or through an external provider).

In recent years, however, smaller players have entered the market, bringing standardised proprietary platforms and products that go a long way to addressing such business needs, and which can be customised to address a broad range of requirements (‘out-of-the-box’ software).

This now means that an organisation seeking a new software solution has a key decision to make: does it commission a bespoke development (or heavy customisation of a ‘commercial-off-the-shelf’, or COTS, product), or does it select an existing ‘out-of-the-box’ option?

The use of proprietary software is of course nothing new. ‘Commercial-off-the-shelf’ or ‘COTS’ products have existed since the dawn of the software industry (the most commonly-cited example probably being the Microsoft Office word processing and productivity suite). A COTS product typically delivers a common set of functions, usually for a particular business domain.

Although not a term of art, by ‘out-of-the-box’ (or ‘OOTB’) we mean something different to COTS. An OOTB solution is typically more complex than COTS and fulfils a broader set of business needs. When installed, the software will be pre-configured to perform certain basic functionality but can be customised to perform specialist operations. The software will often be designed and configured with a specific purpose in mind. For example, Temenos provides OOTB platforms used in the financial services (FS) sector – FS institutions can use such platforms to perform core digital banking operations. Other examples include MuleSoft’s suite of OOTB API platforms which enable integration between multiple disparate sets of applications, data and devices.

IT service providers often partner with OOTB vendors in the provision of their services, playing a key role in configuring, integrating and implementing the OOTB solution within their customer’s environment.

This shift can have important implications for customers and the supplier appointed to configure, integrate and/or implement the OOTB solution, as the model involves different considerations than in traditional bespoke software arrangements. Some considerations that customers and integration suppliers might have are:

• Should the supplier take end-to-end responsibility (and liability)?

Often, customers will want to ensure that the integration supplier takes contractual responsibility for the OOTB product. This is especially the case where the supplier has selected or recommended the particular OOTB product to the customer.

From a supplier’s perspective, the customer would ideally contract directly with the OOTB vendor, and the customer-supplier contract will only cover the integration, configuration and possibly support and maintenance services. However, the customer may want to resist this, and ensure the supplier takes overall ownership of the project.

From the customer’s perspective, this means that if any part of the project goes wrong, it can go to a single entity for legal and commercial remedies. It can also encourage suppliers to develop a stronger overall solution, and save customers legal costs (as there will only be one contract instead of multiple contracts to review and negotiate).

In lower-value projects where the supplier is making a small margin, the supplier may not have the appetite to take on this risk. However, in competitive procurements the supplier may choose to accept wider responsibility. In this scenario, it is important for both the customer and the supplier to consider the extent to which the contractual terms that govern the integration can also feasibly govern the OOTB product.

Even if the customer agrees that the supplier’s responsibility for the OOTB product will be on a ‘pass-through’ basis (i.e. the supplier passes up to the customer the terms, liability and performance level it can enforce against the OOTB vendor), this can be notoriously difficult to address in practice (e.g. ensuring the terms reflect this delineation, and the practical issues of identifying where the cause of a failure arises (and therefore which terms will apply)) and the supplier should seek to adequately protect itself from these practical difficulties.

• Is there an element of cloud and how does this effect the contract?

It is common for OOTB products to be delivered “as a service” through the cloud. As the supplier’s integration and configuration work sometimes takes the form of software deliverables that are typically not cloud-based, this means that a single set of contract terms may not be appropriate for both these software deliverables and the cloud-based OOTB service.

Depending on the level of responsibility the customer is requiring and the supplier is accepting for the OOTB solution (see above), it may be difficult for the supplier to “cloud-wash” the terms – resulting in the risk that it over-commits to the customer in areas that cloud vendors usually push back on.

If the supplier has selected an OOTB product to deliver as part of the service, a customer may take the view that this should not enable the supplier to promise a lower level of service for that part of the solution. Suppliers will however almost invariably want to flow-up the terms of the OOTB product for that part of the solution, and it takes careful consideration to ensure the cloud-based terms are appropriately flowed up. It is not always achievable on competitive procurements, resulting in some not insignificant risk transfer to the integration supplier.

• Should the supplier guarantee regulatory compliance?

Several core OOTB products are designed to enable a customer organisation to comply with certain laws or regulations, e.g. Payment Services Directive 2 or GDPR. The OOTB vendor may even warrant that its product will ensure the customer’s compliance – or at least enable its compliance when operated correctly – with those laws or regulations.

Customers often expect the integration layers or configuration performed by the supplier to match the OOTB vendor’s compliance commitment. In large outsourcing transactions, a customer’s primary driver will often be to cut costs and transfer a significant proportion (if not all) responsibility of the solution to the supplier (including legal and regulatory compliance).

Often, that supplier may not be in a position to give that commitment, and will see its role as merely configuring or integrating the OOTB product within the customer’s IT environment. As well as being a particularly challenging issue in negotiations, in practical terms it can be difficult to delineate where the regulatory compliance of the OOTB product finishes and where the customer’s regulatory responsibility begins.

If a supplier does guarantee regulatory compliance, this gives rise to the risk that any failure that occurs within the wider ecosystem – and any of the various players and components within it – to enable regulatory compliance may be blamed on the integration supplier, who might be the first (or, in a prime contract model, only) entity in the chain for the customer to pursue.

If the supplier is not guaranteeing regulatory compliance, the customer must put a process in place to assess and action any legal and regulatory considerations to avoid falling foul of the law and potentially becoming subject to penalties. It is therefore important to be clear – both technically and in the contract – what level of regulatory compliance the integration supplier will (or will not) take responsibility for.

As the market moves toward smaller, shorter-term and more interconnected deals, driven by the need for standardised cloud services or OOTB platforms, customers and integration suppliers will need to consider carefully how it deals with the above considerations, and how they are ultimately contracted for in order to avoid some of the pitfalls that can arise.