RegTech: A Guide to Effective Procurement - Part I

As many know, I've spent the last few years working in RegTech. During that time, I must have sat in hundreds of meetings with IT and compliance managers, considering their options as they look to meet regulatory obligations, manage costs, and select partners from an ever-growing list. As that list has expanded, many have turned to third-party consultants, standardised RFPs, or rely heavily on word of mouth.

This ever-more competitive landscape has led to bold claims and sharp pencils, but if history is anything to go by, the lowest price is not always the most reliable partner.

I thought it might be helpful to share experiences and key themes to help folks avoid some classic pitfalls.

Build vs. Buy: Deciphering the Best Path

Let's start with the obvious. Do you need to buy a system? (I hear the awkward shuffle of salespeople's feet).

But in all seriousness, it will depend on your appetite for substantial IT projects. It is often assumed, usually by senior management, divorced from the day-to-day rigmarole, that RegTech can be built, calibrated, and left to run. However, regulations continually change, and so do the businesses they cover.

New 'flavours' of behavioural patterns, such as 'spoofing' or changes to margin methodology, constantly shift the goalposts. Furthermore, trading firms evolve, adding new desks, products, and asset classes, generating a perpetual need for system maintenance - that shouldn't be underestimated (see J.P. Morgan's 2024 e-Trading Survey).

Let's take a practical example: if a traditional equities or futures trading firm decides to enter crypto, new connectivity may need to be built, additional contextual market data included, and parameters set. 'Insider dealing' in equities may simply relate to trading ahead of sensitive stock news, but in crypto, this may be buying a large number of tokens before a public exchange listing. The system must be seeded with that information to generate relevant feedback. Furthermore, the architect of the original system may leave the company. Despite this, regulators will require detailed paperwork explaining how the system works and a well-documented paper trail of changes for audit purposes. Internal builds can be good for firms with significant resources to meet these requirements (as well as the capital!) or for much smaller firms with vanilla trading and limited regulatory exposure. However, on the whole, they are few and far between.

There is plenty of material on this subject available online. I will admit that much is written from a vendor perspective, but the bottom line is simple: building may be suitable for some, but it shouldn't be underestimated. RegTech is complex and continually evolving, so any build should not be considered a one-time capital expenditure, and strong, relevant expertise is critical.

As a large U.S. proprietary trading firm once suggested to me: "Our quants should be building alpha-generating strategies, not surveillance tools".

Do:

• Consider how much resource the firm is prepared to commit for the long term and capital for an internal build.
• Align IT/Compliance to ensure both teams have the correct skills and can commit these individuals (% of over hours annually should be weighed up).

Don't:

• Decide without weighing and reviewing third-party options. These can often be more cost-effective in the long run.
• Forget to document any/all internal work. Regulators will expect this on hand.

News Team Assemble: Defining Your Project Team

In many initial conversations, a compliance manager is tasked with quickly reaching out to a few vendors, perhaps due to a call from a regulator or a peer receiving a wrap on the knuckles. Meetings are set up and details exchanged, but the inevitable outcome is a need for further discussion and gathering responses from stakeholders who weren't in that initial meeting.

The most successful processes include critical stakeholders from the outset. Compliance may be the end-user, but IT, legal and risk are often heavily involved. Understanding the organisation's IT infrastructure, access to trade/market data and relevant third-party licenses immediately cuts down time and helps vendors scope the required platform. Preparing a document outlining the market coverage needs (ideally by MIC code - see here) and volumes (total messages, i.e. orders, trades, cancellations and amendments) is also valuable information to have on hand. This helps understand server capacity/throughput as well as the viable risks given geographical needs and regulatory exposure. Furthermore it quickly ascertains whether certain vendors are capable of meeting the coverage needs, removing wasted effort if they can't.

Do:

• Decide who needs to be involved early on (IT, legal, compliance etc.).
• Agree on what the sign-off process looks like and in what order.
• Prepare key documents in advance (volumes, market coverage expectations, etc.)

Don't:

• Set up vendor meetings before properly mapping out requirements.
• Base your selection process on 1-2 peer discussions. Their needs/setup may differ; however similar you may think they are.

Scope Definition: Beyond the Obvious

I often got a quizzical look when I asked about the project's scope—as if perhaps it was obvious. Answers have ranged from "Equities" to "We trade a bit of ICE and some CME" (sic). One firm insisted they only traded Asian bonds only to send a sample file containing a vast array of U.S. equity product codes.

Start with a broad scope but then narrow it down:

1. What asset classes? (e.g., U.S. equities, options (e.g., OPRA), listed fixed income, listed/non-listed FX, crypto, energy futures or spot/wholesale/physical, etc.)
2. What markets? If listed, can you provide the operating or, even better, the segment MIC to ensure the vendor has experience and/or access to any contextual data?
3. Where do you require instances? For example, do your teams require access to EMEA, the US, or APAC instances? Do they need to segregate trading onto the same markets (i.e., US teams trading EMEA markets and vice versa)?
4. What privacy/data security requirements are there for each region? Do they differ, or should a single, more consistent policy be used for all global instances?
5. What is the firm's appetite for cloud? Is there a preference for 'own' vs. vendor? Is on-prem a requirement, and if so, what governs that thinking? Fewer firms are selecting on-prem, but it is still often considered, with many exchanges and regulators still utilising it. Deployments can differ considerably in price and complexity depending on the answers to these questions (and availability will depend on the vendor). How do you want your firm to interact with the system, and who is responsible for logging/maintaining parameters/governance?
6. If monitoring more niche markets such as physical/spot energy, does the firm have access to additional data sources (capacity, outage, positions etc)? If this requires access to a third party has it already been discussed?

Do:

• Map out the physical needs of the system, considering personnel and local requirements/expertise.
• Align with infrastructure/IT teams to understand what is possible and what security measures are expected.
• Consider whether you have all the data or you need to procure some/ask the vendor to provide

Don't:

• Assume scope is just what you trade. Consider where and how.
• Try to boil the ocean. Consider a phased approach and scope each phase accordingly. Consider this as part of a broader timeline based on internal and external expectations.

Risk Assessment: The Core of RegTech Deployment

The nub of most RegTech deployments is interpreting and meeting the risk assessment. Whilst not mandated by all major financial jurisdictions, firms should consider preparing an assessment that addresses what risks the firm is exposed to should its employees decide to 'go rogue'. For example, if a trader has direct access to a market, then it is feasible that they may be able to enter false impressions of price. Thus, knowing how to monitor activities such as layering/spoofing would be advisable! This exercise should be considered across all key risks depending on the regulations of the relevant markets/jurisdictions the firm is exposed to. Having this document to hand when exploring with technology providers will help assess whether the vendor meets all requirements. It will also help rule out certain requirements - for instance, should the firm route orders to a third party (who executes on the firm's behalf). It is unlikely (if not impossible) that activities such as layering are feasible, but insider dealing may still be a risk.

J.P. Morgan's recent $348.2m fine from the OCC and Fed for lack of surveillance may be eye-popping (suggesting 30+ venues were not adequately monitored between 2014-23), but what is interesting is the response from the regulators. In both cases, the OCC and Fed demanded well-documented policies and procedures covering (i) controls, (ii) effective automated data reconciliation processes, (iii) parameters & calibration, (iv) measures to ensure routine and annual monitoring and (v) testing. The importance of good governance should never be underestimated.

Do:

• Prepare a risk assessment before engaging vendors. If possible, provide this to the vendor under NDA to align requirements.
• Consider both internal and third parties to assist with this process.

Don't:

• Rush the process. Regulators require a well-written risk assessment, which should be considered thoroughly. This will also provide an excellent template for vendor selection.
• Rely solely on historical data. While past data is valuable, relying exclusively on it can lead to outdated assessments. Financial markets and risks are dynamic; assessments should consider current trends, future projections, and potential market changes.
• Don’t Set It and Forget It. Risk management is an ongoing process. A common mistake is treating risk assessments as one-time activities. Regular updates and reviews are necessary to account for new risks and changes in the business environment.

To RFP or Not to RFP: A 'Painful' Question

I've seen my fair share of RFPs. They typically fall into three categories: (i) ill-conceived, (ii) ill-structured, and/or (iii) unnecessarily complex. It's fair to say I'm not a fan, but here's why:

• Standardising Complex Problems: firms often look to RFPs to create standards across vendors. The thinking goes that if all things are equal, then buyers can make more straightforward decisions. However, vendors have evolved, often approaching regulatory compliance differently, given that regulation is often open for interpretation, making like-for-like comparisons hard. Equally, pricing models frequently differ as vendors try to align with how specific markets operate (i.e., by volume, number of venues, hosting, market data inclusion, etc.) or out-manoeuvre each other to provide more attractive, cost-effective models. RFPs that give little/no opportunity to explain how solutions differ often doom certain providers to an early exit when they may offer a more than valid solution
• Third-party Consultants: I tread carefully here as my network contains many highly professional and well-informed consultants. However, some more 'generalist' firms have produced RFPs with almost non-sensical questions that don't relate to the systems their clients are looking to purchase. In some cases, I've seen the same template used multiple times with minimal adaptation to the client's needs. Consultants can provide fantastic independent advice; however, they can also overcomplicate or oversimplify the process, leading to more difficulty in deciding on a solution. It's essential to do reasonable due diligence, review past work and get references.

Do:

• Consider how many vendors you wish to include. If you deem a limited number appropriate, consider a more direct approach.
• Don't be surprised if a vendor asks for a short call prior to agreeing to respond to an RFP. These documents are often significant undertakings, and it's an understandable request.
• Always give vendors a window to submit questions. This will help avoid misunderstanding and ensure responses are well-considered.
• Allow free-text areas in the RFP to give vendors space to explain answers.
• If using a point scoring system, ensure you weigh responses according to their priority. For instance, data security measures no doubt feature more highly than certain functional 'nice to haves'

Don't:

• Use standard RFP templates without seriously considering their applicability to your project.
• Be surprised if some vendors decline the invitation to tender. As mentioned, RFPs are substantial undertakings, and vendors may tackle more than one at any time. Some vendors are starting to turn down unsolicited RFPs, opting only to participate where a relationship has already been established.
• Underestimate complexity. For firms requiring highly complex integrations with existing systems, a collaborative partnership established without a formal RFP might lead to a better understanding and custom solutions tailored to specific infrastructural needs.

In Part II, we'll examine some options to help reduce the selection headache. We'll also discuss the pros and cons of POCs/Trials and why it's important to define a project plan early with your selected vendor.