RegTech: A Guide to Effective Procurement - Part II

Previously, I looked at the early stages of RegTech procurement: defining the project, assembling the correct team, and preparing documentation to aid the process.

Assuming you've whittled your list to a handful of vendors, there are a few options to consider:

Draft Project Plan

At some point, you'll need to make a decision. Almost all vendors will suggest a delivery time frame of 6-8 weeks (call me a stickler, but that seems to be the industry standard term), but how realistic is that? It depends, of course, on your requirements, the complexity of architecture, and the ability to deliver data (either in a given format or for the vendor to write to you), but getting a better definition to manage internal expectations (particularly resources) is important.

At this point, I suggest requesting a draft project plan. This helps both teams align on rough timelines for each stage, as well as the workloads and time commitments and highlights any nuanced requirements that may trip up the delivery. It also helps to understand if agreed timelines are realistic and/or to factor in slippage time around holiday periods or to understand key-person risk. Understanding, for instance, how long each party considers setting up a drop copy or calibrating a module will go a long way in aligning expectations going forward.

Ensure that the team focused on delivery is actively involved in this process. It may sound obvious, but over the years, I've certainly witnessed overly zealous project managers and compliance leaders take the lead only to find that IT doesn't align with expectations.

The draft doesn't need to be perfect. At this stage, you're ensuring you're on the same page. It also gives an opportunity to air any key deadlines. Remember that deadlines can be internal as well as external — e.g., a product/market launch or a date when an individual or team will have availability or be out of the office on vacation. These should all be factored in and discussed.

Do:

• Ask for a draft plan that both parties can discuss to ensure timelines are reasonable and meet expectations.
• Discuss key deadlines and key-man risks/periods of absence.
• Ensure IT and any folks involved in the final delivery have time to interrogate the plan and ask questions.

Don't:

• Skip this stage - being clear/realistic will significantly help manage expectations.

POC/Trial

Trials are often requested with an air of flippancy, i.e. "We'll test the system for a month, and if we're happy, we'll sign", but there is a lot more to this process and commitment needed on both sides to maximise the benefit:

1. Any POC/Trial should involve your data. As such, the T&Cs of an MSA (Master Service Agreement) should be applied. Data security, IP, risk, liabilities, termination rights, etc., are all relevant, as are legal governance in the event of a dispute.
2. Ask if the vendor can offer some form of demo using your data — thus ring-fencing the ask but perhaps mitigating the need for a full system deployment. Perhaps provide data that you know should trigger the solution and provide 'interesting' analytics to see if the vendor captures it and how they display it back.
3. Both parties should align on success criteria, ringfence timelines, and staffing/support. Preparing a pre-POC/Trial document that outlines all of these and is signed by both parties goes a long way to improving outcomes and building trust. Vendors would do well to prepare such a template for future use. It shows organisation and a structured way of thinking, and it also shows that this isn't your first rodeo!
4. Agree on a regular cadence of meetings with a set agenda to track performance vs. the document - use definable metrics. Consider setting up parallel meetings for technical/IT teams and functional user support. Ensure these meetings are documented or recorded, and the vendor provides a summary alongside any actions agreed upon by both sides. Remember to ensure any actions are assigned to an individual, recorded as such, and a timeline is given. Whilst some timelines will be more important than others, accountability is a key factor in a working relationship and something that shouldn't be ignored during a trial.

Do:

• If a POC/Trial is a deal-breaker, consider signing an MSA with a short-term agreement (say one month), which rolls into a longer-term agreement upon the vendor meeting the defined criteria.
• Ensure success criteria are defined and, ideally, metrics that can be measured. 'Look and feel' are important but hard to quantify - consider what aspects of the service are most important and why.
• Plan to resource and keep regular check-point meetings in the diary. Document these and ensure accountability

Don't:

• Request a POC/Trial just to 'get a feel' for the system and consider precisely what defines success.
• Underestimate the effort. Both parties should be fully engaged. Try not to run concurrent POCs/Trials with more than one vendor. Demonstrating commitment to make a final selection will go a long way in building trust between all parties.
• Expect the system to light up each day - hopefully, conditions are such that your RegTech platform won't need to. Ask the vendor to set artificially sensitive thresholds to trigger data within the analytics tools.

Negotiation

It would be hard not to include a section on negotiation. Whilst there is a tremendous amount of material available (and a lifetime of learning), there are a few critical considerations for both parties:

1. Ask yourself what a 'good outcome' looks like: While many focus on 'price', few consider 'cost' (i.e. the total overhead of the project, including time, effort, resources, etc.) Be prepared for various outcomes, including walking away if the terms do not meet your minimum requirements. Knowing your alternatives ('BATNA' - Best Alternative To a Negotiated Agreement) can give you more confidence and clarity during negotiations.
2. The negotiation 'trap': Vendors would do well to ensure they're the 'vendor of choice' before entering a negotiation or risk a clandestine negotiation with their nearest competitor. Equally, if you're procuring technology, then showing a willingness to progress with this 'final option' will add goodwill to the negotiating table. Knowing that they're in the final throws of the selection process may open the doors to better terms that a vendor may have been keeping back
3. Consider the variables: These are the other negotiables outside of simple price: (i) subscription/renewal terms, (ii) termination clauses, (iii) payment terms, (iv) service level agreements (SLAs), (v) data provision and licensing, (vi) time of delivery/commitment. Depending on the contract term, value and services, these may or may not be more flexible. Typically, these are negotiated with your legal team present; however, airing some of these upfront will help the vendor suggest alternative strategies if needed
4. Understand the vendor's pricing model: including any hidden costs like implementation fees or charges for additional users. Discuss the expected return on investment (ROI) and how the vendor’s solutions will save money, reduce risks, or increase efficiency in the long term. This will be enormously valuable when presenting to a board
5. Articulating value: a good negotiation will involve the vendor being able to articulate 'value'. If both parties have shared sufficient information throughout the process, then it will be apparent what the core issues are that this solution is looking to solve, as well as the internal and external factors that stakeholders value more than others. By being able to articulate this, ideally through metrics, the vendor will help not only their own case but those internally who may need to seek further budget or approvals
6. Consider sharing internal documents: some firms standardise internal procurement processes, and stakeholders may need to complete documents before moving to a final stage. If you're negotiating on behalf of a committee, then consider sharing the template with the vendor. No doubt the vendor has been through this process many times and may have suggestions on how to position the solution vs. peers, internal builds or other outcomes. It also gives both sides a final review of the offer, commercial terms and any concerns before it goes to sign-off.

Do:

• Prepare for a number of possible outcomes, including a 'best alternative.'
• Consider informing the vendor they have been selected pending successful negotiations - this may open more flexibility.
• Reiterate and align on the true value - where possible, use metrics. This will help with any further internal justification(s) i.e. by utilising X tool we can reduce operational time by Y hours. This will allow us to save Z cost - potentially assisting in other projects
• If comfortable, work with the vendor to prepare any further internal pitches. Hopefully, committee members and decision-makers have been involved thus far, but external stakeholders can always de-rail processes at the last minute. Consider what objections may remain and work together to prepare for these.

Don't:

• Be unrealistic. While getting the best product and service at the lowest price seems attractive, ask whether it represents fair value, allows for continued investment in the product and sets the tone for a good, long-term partnership.
• Hold a gun. If both parties understand the reasons for certain non-negotiables, then compromises can be made where feasible. Negotiation is often a combination of corporate (company line) and personal (individual ego). Understanding the factors affecting this will go a long way to reaching a mutually beneficial outcome.

Summary

• Understand Your Compliance Needs: Understand your regulatory requirements and ensure the providers you're talking to meet those needs. Be specific about the jurisdictions and regulations you need to comply with.
• Prioritise Data Security and Privacy: Given the sensitive nature of compliance data, ensure that data security and privacy are top priorities.
• Plan for Scalability: Ensure that any agreement allows for flexibility and scalability. Your needs may evolve as your business grows or as regulations change.
• Be Thorough and Structured: From the initial stage of assembling a project team to defining requirements, architecture and success criteria, it's essential to take a structured approach.
• Consider Integration Capabilities: Ensure your trading footprint can integrate seamlessly with the proposed solution. Map out your infrastructure and discuss any gaps or custom integration needs, ensuring these are covered in the agreement.
• Don't Rush the Process: Take the time to thoroughly review and understand all aspects of the service/platform and agreement.
• Be Clear On The Sign-Off Process: Understanding who needs to be involved, at what stage and what the process is will save much trouble later in the project. Having an exec travelling or out for a lengthy holiday with no alternative process can seriously delay projects
• Product Knowledge is Key: Every trading firm, asset class, market, and jurisdiction differs. Experience is vital. Spend time getting to know the vendor team(s). Ensure they're aligned with your expectations and have experts on call