Whether you are an insurance company, a bank or a FinTech, and are about to launch a platform, offer your services or products white-labelled to other companies or perhaps you simply need to integrate a new module, you’ll have to work with third-party providers' solutions.
When developing new digital products during my time as a product manager, it’s one of these things I often struggled with. I noticed that there’s what I call a sense of “innocence” which I can only describe as a disconnection of the economic factors that vendor management teams need to take into consideration.
It’s an important topic, especially considering what’s at stake if you make the wrong choice. It affects the quality of the product, its user experience, your customers, your company’s reputation, competitors, partners, or even regulators (if you are a regulated entity).
Let's take the example of a FinTech company willing to offer a 100% remote solution for opening bank accounts (for example N26, Monzo or Revolut). The remote service proposed by the neobank could require an identity verification solution, a digital signature (from a Trust Service Provider), checks on sanctions' lists, etc.
Numerous solutions will be available:
Some deployed locally, others in the Cloud,
Some configurable, others not,
Some covering certain categories of customers, some not, etc…
Therefore, it’s imperative to be vigilant from the start (regardless of contracts and prices). Focus on the services offered and the Service Level Agreements ("SLA") in place.
I’ve compiled a list of topics that, in my opinion, are essential to check before you “get married” to a provider.
Make sure you are prepared. A divorce will have serious consequences.
Some of this might be common sense, but you’ll be surprised how often these are missed. So let’s start with the basics.
1- Don't waste time. Check the credentials from the start.
Make sure that you check that these solutions are not “fake” by cross-referencing them with commercial registers. This might sound basic, but can be costly and a huge waste of time if overlooked. Gather genuine feedback by contacting other companies who have integrated and/or are using their services. You can find a list of companies and people you can contact on their website. Pick up the phones and do your due diligence! If it’s a regulated provider, do not hesitate to check press releases and regulators' websites to verify whether or not these providers have anything to hide.
2- Be cautious and make sure you assess the providers with your technical teams.
At a minimum, your product team, legal team and your technical team should be involved in finding a solution you should integrate with.
Technical evaluation: API details, sandbox,
Purge of data: processing times, anonymisation,
IT security: ISO 27001, encryption,
Legal: negotiation of audit rights, conditions when changing sub-contractors,
Product: Change management procedures.
3- Read the contracts and SLA carefully before sending them to Legal.
The devil is always hidden in the details. Your first screening should look at articles related to the duration of the contract, change of subcontractor and data protection. When it comes to the SLA, you’ll need to check the levels of priority you’ll receive and find examples that can illustrate this practice.
4- Get the outsourcing chain under control.
The outsourcing chain means the cascade of sub-contractors from the integrated service provider. For example, for a signature solution, you may find a Cloud service provider, a certified signature provider (Trust service provider), a provider for identity verification solution, and a centre for the “manual” processing of identity-document verifications. All these solutions combined together means you’ll need to keep in mind the “LEGO” structure behind the product, otherwise you’ll end up with a few surprises.
5- Test, test and test before integrating.
Testing is an essential part of any new integration. Once in production, you’ll breathe a sigh of relief when you’ve identified the main bugs. Testing providers in production, if already integrated to another platform, is an easy way to be aware of failures/bugs. Whenever possible, anticipate and build a test phase into your contract so that you can save time in the long run.
6- Analyse the API documentation, internal procedures that are made available.
Go through all of it meticulously. Perform a gap analysis with your technical team and have all related impacts explained in relation to development and deployments. It’s important to assess the risks when things won’t align during the integration, which ultimately means delays that could impact release.
7- Start worrying about post-product support.
Once in production, what procedures are in place to report “bugs”?
What is the availability of the service in the SLA?
Is there an SLA on response times from the customer care team?
Does the provider have a Jira or StatusPage portal?
I would recommend requesting this as soon as possible so that you can access the post-production procedures.
8- Think Business Continuity Plan (“BCP”), it's your plan B.
You need to have one in place and so does your provider. What if the solution crashes or the API is no longer available?
9-Be reasonable, these are often not large IT Services companies.
These providers often NOT large companies, so always remain fair and reasonable in your negotiation. Don’t ask for low prices and unbearable SLAs.
10- Lastly, for regulated companies
Don't forget to notify or ask for the authorisation from the regulator before moving forward.