Chapter 36: Vendor Selection, Due Diligence, and Implementation Management

"The contract you sign on the way in is the contract you live with on the way out. Most compliance teams only read it once — at the beginning. They should read it twice: once before they sign, and once when they realize they need to leave."

— Rafael Torres, Compliance Integration Consultant

The Contract That Changed Everything

Rafael Torres spread the pages of the contract across his hotel room desk in Manchester and began counting clauses. Or rather, he began counting the clauses that were missing.

No audit right. Not even a limited one.

No exit assistance obligation. When the contract ended — or when either party chose to end it — the vendor was obligated to provide data in whatever format it deemed "commercially reasonable." That phrase, Rafael had learned over two decades of compliance consulting, is legal language for "we'll give you whatever we feel like giving you, in whatever form is most convenient for us."

No meaningful SLA remedy. There was an uptime guarantee — 99.5%, which sounds impressive until you calculate that it permits 43.8 hours of downtime per year — but the remedy for failing it was a service credit capped at 10% of the monthly fee. Ten percent. For a platform that a mid-size UK asset manager was relying upon to run its market surveillance program, 43 hours of downtime in a year wasn't an operational inconvenience. It was a regulatory exposure.

And then there was the escalation clause: annual price increases of 8%, compounding, for five years. The original contract price had been £340,000 per year. By year five, the firm would be paying £499,712 — a 47% increase — for the same platform, the same support model, and the same mediocre uptime guarantee.

The contract had been signed in January 2022. Rafael was reviewing it in March 2024. The client — a £4.2 billion AUM asset manager with operations in London and Edinburgh — had first reached out to him three months earlier, when it became clear that the market surveillance platform was failing to detect certain cross-asset manipulation patterns that the FCA had specifically flagged in its 2023 Market Watch publication. The vendor had acknowledged the gap. The fix, they said, would require a module upgrade. The upgrade would cost £85,000. And it was not covered under the existing contract.

Rafael had seen this pattern before. Not once, not twice, but in enough engagements — a UK bank, two broker-dealers, a European asset manager, a fintech payments firm — that he had started calling it the Procurement Trap. Compliance teams, urgent to solve a regulatory problem, engaged vendors with energy and enthusiasm. They evaluated solutions. They ran demonstrations. They negotiated price. And then, in the final exhausted weeks of a procurement process that had already consumed eight months, they handed the contract to legal, who were under instruction to "get it signed," and signed it.

Eighteen months later, Rafael got the call.

This chapter is his attempt to ensure you never make that call.

Section 1: Why Vendor Selection Is a Compliance Activity

There is a persistent and damaging assumption in financial services that vendor selection is a procurement activity with a compliance sign-off at the end. Under this model, the technology team identifies candidates, the project team evaluates them, procurement negotiates the deal, legal reviews the contract, and compliance stamps its approval. The stamp is the end of compliance's involvement.

This model is wrong. It was wrong before DORA. It is dangerously wrong after it.

The Regulatory Context

The Digital Operational Resilience Act (DORA), which became applicable across EU financial entities in January 2025, contains one of the most detailed and demanding third-party ICT risk management frameworks ever imposed on regulated financial services firms. Articles 28 through 30 of DORA are not administrative guidance — they are legal requirements, backed by supervisory scrutiny and the full enforcement apparatus of European financial regulators.

Article 28 establishes the general framework: financial entities must manage third-party ICT risk as an integral part of their ICT risk management framework. Before entering a contractual arrangement with an ICT third-party service provider, the financial entity must conduct a risk assessment that considers whether the arrangement creates a concentration risk — whether the dependence on one vendor, or one category of vendor, creates systemic operational vulnerability.

Article 28(2) requires financial entities to assess whether the ICT service supports a critical or important function. This is a formal determination, not an informal judgment. The criteria are specified: substitutability (how easily could another vendor perform this function?), operational impact (what happens to the financial entity's operations if the service fails?), and systemic impact (could the failure affect the broader financial system?).

Article 29 governs what must be in the contractual arrangement with ICT third-party service providers. The list is extensive: - A clear description of the services to be provided - Service levels, including quantitative and qualitative metrics - Data locations and data processing locations - Data portability requirements - Notification and reporting requirements (including security incidents) - The right to audit — and the specific form that right must take - Termination rights and exit assistance obligations

Article 30 applies specifically to arrangements involving critical or important functions. These arrangements must include enhanced provisions: detailed performance targets, explicit governance requirements, mandatory oversight rights for supervisory authorities, and comprehensive business continuity provisions including testing obligations.

In the UK, the FCA's Operational Resilience Framework, codified in PS21/3 and effective from March 2022, establishes similar expectations for operational continuity. Important Business Services — the FCA's term for the functions that matter most — must be mapped through to their third-party dependencies. If a vendor supporting an Important Business Service fails, the financial entity must still be able to operate within its impact tolerance. That means knowing, in advance, whether vendor failure would breach the tolerance, and having a plan if it does.

The FCA's Critical Third Party (CTP) regime, introduced under the Financial Services and Markets Act 2023, goes further. Under this regime, certain technology and service providers deemed systemically critical to UK financial services are directly subject to FCA/PRA/Bank of England oversight. For financial entities using these designated critical third parties, due diligence obligations are heightened — regulators expect documented evidence that the firm understood what it was relying on before it relied on it.

The Shift in Mental Model

The implication of this regulatory architecture is clear: vendor selection for RegTech systems is not a procurement activity. It is a regulated entity risk management activity, with legal obligations attached to its process, its documentation, and its outcomes.

The mental model shift is this: when a compliance officer selects a RegTech vendor, they are not choosing a piece of software. They are deciding how a regulated function — trade surveillance, transaction monitoring, regulatory reporting, KYC — will be performed. They are making a decision that regulators will scrutinize when things go wrong. They are creating a contractual framework that will either protect or expose their institution for the duration of that contract.

That means the compliance function must own the vendor selection process — not just approve its outcome.

The Three-Tier Vendor Classification

Not all RegTech vendors warrant the same depth of due diligence. A useful framework classifies vendors into three tiers:

Tier 1 — Critical/DORA-Critical Vendors: Vendors supporting functions that are either legally designated as critical (under DORA Article 28 analysis) or that would, if they failed, breach the firm's impact tolerance for an Important Business Service. Examples: core AML/transaction monitoring platform, primary regulatory reporting engine, trade surveillance platform for a significant broker-dealer. These vendors require full due diligence, comprehensive contractual protection, and annual review.

Tier 2 — Important Vendors: Vendors supporting functions that are important to operations but where reasonable substitution is possible within impact tolerance windows, or where the function is not directly tied to a regulated activity. Examples: compliance workflow management, integrated KYC/CDD enrichment services, compliance training platforms. These vendors require substantive due diligence and solid contractual terms, but proportionately less intensive review than Tier 1.

Tier 3 — Supporting Vendors: Vendors providing tools that support compliance functions but are not direct providers of regulated services. Examples: compliance document management, regulatory news feeds, internal policy management tools. These vendors require standard vendor due diligence and appropriate contractual terms, but proportionate to lower risk.

The tier classification determines the depth of due diligence, the specificity of contractual requirements, and the intensity of ongoing monitoring. It must be formally documented and reviewed when a vendor's role or the firm's reliance on them changes.

Section 2: Requirements Definition — Before You Talk to Vendors

The most expensive mistake in RegTech procurement is beginning vendor conversations before requirements are complete. When you begin conversations without complete requirements, vendors define your requirements for you — in terms that favor their solutions.

Rafael's cardinal rule: requirements define evaluation criteria. Every element in your evaluation scorecard should trace back to a documented requirement. If you cannot point to a requirement that a vendor is being scored against, you are scoring on preference, not need.

The Five Categories of Requirements

Functional Requirements describe what the system must do. For a transaction monitoring system: which transaction types must be monitored, what typologies must be detected, what case management workflow is required, what output the system must produce for SAR filing, what integration with existing sanctions screening is needed. Functional requirements are the most obvious — and the most frequently underspecified. "Monitors transactions for suspicious activity" is not a functional requirement. "Detects layering typologies across correspondent banking flows in USD, EUR, and GBP, with configurable thresholds by customer segment, and generates draft SAR narratives in the format required by the NCA's SARs Online portal" is a functional requirement.

Non-Functional Requirements describe how the system must perform. Response time: alerts generated within X seconds of transaction ingestion. Throughput: system must process Y transactions per second at peak load. Availability: uptime of Z% excluding scheduled maintenance windows. Scalability: system must handle 3× current transaction volumes without architectural change. Security: system must achieve and maintain SOC 2 Type II certification. Disaster recovery: RTO of X hours, RPO of Y hours. These requirements are the ones most often underdefined, and they are the ones most often at the center of contract disputes.

Regulatory Requirements describe what the system must do to meet the firm's regulatory obligations. This category is specific to RegTech and often overlooked in general IT procurement frameworks. Examples: all alerts must produce an audit trail that is immutable and timestamped to the nearest second, retained for seven years, accessible via API for regulatory production requests. The system must be capable of producing output in XBRL format for regulatory submissions. All personal data processed by the system must be processed in accordance with GDPR Article 28 requirements, with the vendor acting as a data processor under a compliant Data Processing Agreement. These requirements should be drafted by compliance, not by IT.

Integration Requirements describe how the system must connect to existing technology infrastructure. What data feeds will supply transaction data? What API standards are supported? What is the existing case management system and how will cases be transferred? Does the firm use a SIEM (Security Information and Event Management) system that the new tool must feed? What identity management system governs user access? Integration requirements are frequently the source of implementation cost overruns — vendors demonstrate their system in isolation; the real work is the connection.

Operational Requirements describe how the system will be run on an ongoing basis. Who within the firm will be responsible for the system? How many users? What level of technical expertise do internal users have? Will the firm operate a dedicated surveillance team or rely on generalist compliance staff? What training investment is the firm prepared to make? What is the internal support model for tier-1 issues? Operational requirements shape the vendor evaluation for support quality, training provision, and the usability of the interface — factors that matter enormously after go-live and are barely discussed before it.

The Requirements Document

The requirements document is the foundation of the procurement process. It should be structured as a formal document with version control, stakeholder attribution (who specified which requirements), priority classification (mandatory, preferred, desirable), and sign-off from all relevant stakeholders: compliance, technology, operations, legal, data governance, and the business function that will use the system.

The sign-off process is not administrative theater. It ensures that compliance is not the only voice in the requirements — that technology has reviewed integration feasibility, that data governance has reviewed data handling requirements, that legal has reviewed regulatory and contractual requirements, and that the business has confirmed operational requirements reflect how people will actually use the system.

Once requirements are signed off, they become the evaluation framework. Any vendor who cannot demonstrate compliance with a mandatory requirement is eliminated. Any vendor who scores poorly against preferred requirements scores down. The evaluation scorecard is built directly from the requirements document.

Section 3: Market Assessment

The RegTech vendor landscape in 2025 is large, fragmented, dynamic, and difficult to navigate without preparation. There are over 1,000 self-identified RegTech vendors globally. Across sub-categories — AML/transaction monitoring, trade surveillance, regulatory reporting, KYC/identity verification, sanctions screening, conduct risk, compliance workflow — the number of credible providers in each space ranges from a handful of established incumbents to dozens of newer entrants.

The challenge is not finding vendors. The challenge is finding the right vendors for your specific context — your regulatory jurisdiction, your business model, your existing technology stack, your budget, and your operational capability.

Information Sources

Analyst Reports: Gartner's Magic Quadrant, Celent's Model Bank awards, Chartis Research's RiskTech100, and FinTech Global's RegTech100 are the most widely cited. These are useful for understanding the market shape and identifying established players, but they have limitations: they are typically based on vendor self-reporting, they lag the market by 12-18 months, and they tend to favor larger vendors with marketing budgets. Use them as a starting point, not a conclusion.

Peer Networks: The most reliable intelligence source. Conversations with compliance officers at comparable firms — similar regulatory profile, similar business model, similar geography — who have recently completed comparable procurement exercises are invaluable. Compliance networks, industry associations (CISI, ACAMS, GARP), and informal peer groups can surface vendor names, warnings, and candid assessments that no analyst report will provide.

Regulator Publications: Regulatory publications — FCA Market Watch, EBA guidelines, FSB reports — frequently reference technology approaches to compliance problems. These references are not endorsements, but they signal what regulators are seeing in the market and what they consider adequate.

Conference Presentations: Vendor presence and presentations at RegTech-focused conferences (RegTech Summit, ACAMS conferences, Money 20/20) provide a sense of vendor credibility and thought leadership, but require skeptical interpretation — these are marketing events.

Direct Referrals: Former colleagues, consultants, and advisors who have recently completed similar implementations.

Building the Long List

A rigorous market assessment produces a long list of 20 to 30 vendors. This sounds like a lot, but the purpose of the long list is to ensure you have not missed anyone relevant before you begin screening. The long list is assembled from information sources, not from evaluation. Every vendor that plausibly meets the high-level functional requirement enters the long list.

Screening to the Short List

The long list is reduced to a short list of 5 to 8 vendors through initial screening. The screening criteria should be documented and applied consistently. Typical screening criteria:

• Financial stability: Does the vendor have adequate financial resources to sustain operations over the contract period? For early-stage vendors, is there documented funding (Series B or beyond) with a credible runway? For public companies, is the financial profile stable?
• Regulatory track record: Has the vendor been subject to regulatory enforcement actions related to the quality of its compliance platform? Have its clients been sanctioned for failures traceable to the vendor's platform?
• Reference clients: Does the vendor have reference clients at comparable size and regulatory profile? "Comparable" means similar AUM, similar transaction volumes, similar regulatory jurisdiction, similar business model. A vendor with impressive references from global investment banks may be entirely unproven for a mid-size UK challenger bank.
• Geographic support: Does the vendor have operational support capacity in the firm's relevant jurisdictions? For UK firms post-Brexit, is UK regulatory coverage an explicit product investment or a derivative of EU coverage?
• Product maturity: How long has the specific product (not the vendor) been in market? What is the current version history? Is the product on a modern technology architecture or a legacy platform wrapped in modern interfaces?

Vendors who fail any screening criterion are eliminated from consideration. The rationale for elimination is documented. The short list proceeds to the RFP process.

Section 4: The RFP Process

The Request for Proposal (RFP) is the formal mechanism through which short-listed vendors provide structured responses to the firm's requirements. Not every procurement requires a formal RFP — for lower-value, lower-risk Tier 3 vendors, a more informal request for information and demonstration may be proportionate. For Tier 1 and significant Tier 2 vendors, a formal RFP is both best practice and, under DORA and FCA frameworks, the documented evidence of a structured selection process.

RFP Structure

A well-structured RFP contains the following sections:

1. Company Overview: Request vendor profile information — legal entity, parent company structure, number of employees, revenue (or funding stage), key leadership, geographic footprint. The purpose is to validate the information gathered during screening and to identify any material changes since the long-list assessment.

2. Solution Description and Demonstration: Require vendors to describe their solution in the context of the firm's stated requirements. This section asks vendors to map their product features to the firm's functional requirements, explicitly. "We have a feature for that" is not an acceptable response. "Our [specific module] addresses your requirement for [specific requirement] in the following way" is.

3. Technical Specifications: API documentation, data model, security architecture summary, hosting environment, database technology, integration patterns. The technical section surfaces integration complexity early and allows the firm's technology team to assess feasibility before investment.

4. Implementation Approach: How does the vendor implement its platform? What is the typical timeline? What resources are required from the client? What is the vendor's project management methodology? What is the typical go-live rate (percentage of implementations that meet the original timeline)?

5. Pricing: Request pricing at several defined scenarios — current transaction volumes, 2× current volumes, full-firm rollout. Request pricing for implementation services, training, annual support, and any additional modules or features required. Request the escalation mechanism — how does pricing change year-over-year?

6. References: Request three client references at comparable size and regulatory profile, with contact details. Make clear in the RFP that reference calls are a mandatory part of the evaluation process and that references must be available within the evaluation timeline.

7. Regulatory Compliance Responses: A section specific to RegTech procurement: ask vendors to describe their compliance with DORA Article 29-30 requirements (for EU-connected operations), GDPR Article 28, and any other directly relevant regulatory frameworks. Ask about their audit right provisions in standard contracts. Ask about their data portability provisions. These questions reveal, at the RFP stage, whether the vendor's standard contractual position is compatible with the firm's regulatory obligations.

Scoring the RFP

The RFP evaluation scorecard is built from the requirements document. Each section of the RFP is weighted according to the relative importance of the underlying requirements. A typical weighting for a Tier 1 RegTech vendor:

The 5% weight for contract terms is not an indication that contracts don't matter — it is an artifact of the RFP stage, where vendors are unlikely to commit to final contractual positions. The contract stage, covered in Section 6, is where the real negotiation happens.

Common RFP Mistakes

Too long: An RFP that takes a vendor more than 40 hours to complete will receive lower-quality responses, because the best vendors — who have options — will deprioritize it. A good RFP is focused, specific, and answerable.

Too generic: Sending the same RFP to every vendor in a category, regardless of their market positioning, signals that the firm has not done its homework. Vendors recognize generic RFPs and respond with generic answers.

Too feature-focused: "Does your platform have an anomaly detection capability?" is a feature question. "How does your platform's anomaly detection capability identify cross-asset manipulation patterns of the type flagged in the FCA's Market Watch 72 publication?" is a compliance outcomes question. Ask the latter.

Inconsistent scoring: If different evaluators score the same RFP responses independently without a calibration process, the scores will be inconsistent. Build in a calibration session before evaluation begins.

Section 5: Evaluation Methodology

The evaluation phase — between RFP submission and final vendor selection — is where the difference between a good procurement process and a Procurement Trap is made. This is the phase that is most commonly compressed under schedule pressure, and it is the phase where compression costs the most.

The Proof of Concept

For Tier 1 vendors and complex Tier 2 implementations, a proof of concept (PoC) is essential. A PoC is a structured, time-limited evaluation of the vendor's platform against the firm's specific data, use cases, and requirements. It is not a demonstration — the vendor does not control the data or the scenario. The firm controls both.

What to include in a PoC: - Real or realistic synthetic data, representative of the firm's actual transaction profiles - Specific test cases drawn from the firm's known compliance challenges — past cases that the current system missed, scenarios from regulatory enforcement actions, edge cases that matter - Integration with at least one existing system (even a test environment) to surface integration complexity - User testing by actual intended users — not just technology team members

How long: A minimum of four weeks for a Tier 1 implementation; six to eight weeks is better. Shorter PoCs produce superficial results. Vendors who resist a meaningful PoC duration are signaling that a longer evaluation may not favor them.

What success looks like: Define acceptance criteria before the PoC begins. "The system must flag at least 85% of the test cases in the predefined test set, with a false positive rate below 20%." Not "the system performs well in our evaluation." Subjective success criteria become disputed after the fact.

Reference Calls

Reference calls are one of the most valuable and most badly executed parts of the evaluation process. The typical failure mode is to accept vendor-curated references and ask generic questions. This produces universally positive responses that tell you nothing.

The right approach:

Do not accept only vendor-curated references. Ask for references at comparable size and regulatory profile, and ask the vendor to provide contacts. Then ask the references whether they know of other firms using the platform — and call those firms too, unmediated.

Ask specific questions. Not "how would you rate the implementation?" but "What was the original go-live date and what was the actual go-live date, and why?" Not "is the support team responsive?" but "Give me an example of the most significant incident you experienced since go-live and describe the vendor's response timeline and resolution."

Ask about the contract. "Did you negotiate audit rights?" "Were you able to export your data cleanly when you upgraded from the previous system?" "Have you exercised your SLA remedy provisions and if so what happened?"

Ask about regulatory scrutiny. "Has your regulator examined your use of this platform? What questions were asked? Were you satisfied with the vendor's ability to support you in responding?"

Technical Due Diligence

Technical due diligence for a Tier 1 RegTech vendor should include:

• Security certification: Current SOC 2 Type II report (not just attestation — the actual report, which a responsible vendor will share under NDA); ISO 27001 certification; Cloud Security Alliance STAR certification if relevant.
• Penetration testing: Vendor's most recent third-party penetration test report; how were findings remediated; what is the frequency of testing.
• Data security architecture: Where is data stored? Who has access? What encryption is used in transit and at rest? What is the vendor's approach to customer data segregation?
• Incident history: Has the vendor experienced a data breach or significant security incident? How was it handled? What regulatory notifications were made?
• Business continuity: What is the vendor's documented BCP/DRP? What are the tested RTO and RPO? When was the plan last tested?

Regulatory Due Diligence

This category is unique to RegTech and often omitted from standard vendor due diligence frameworks. The questions are:

• Has the vendor's platform been involved in a regulatory enforcement action against one of its clients, in a context where the platform's output or failure was cited as a contributing factor?
• Does the vendor's regulatory reporting output meet current regulatory standards (XBRL, MiFIR transaction reporting formats, etc.) — and does the vendor commit to maintaining that compliance at its own cost as standards change?
• Has the vendor been examined by any regulator in its own capacity — as an ICT provider under DORA's critical third party framework, or under the UK CTP regime?
• What is the vendor's policy for responding to regulatory change? When the EU adopted the 2023 MiCA regulation, how did the vendor respond for its affected clients, and over what timeline?

Financial Due Diligence

Financial due diligence determines whether the vendor will exist in recognizable form for the duration of the proposed contract. Key questions:

• For privately held vendors: most recent funding round; investor identity; stated runway; revenue trajectory (ask for revenue growth rate if not public).
• For publicly held vendors: revenue concentration (what percentage of revenue comes from the top 10 clients?); churn rate; R&D investment as a percentage of revenue.
• Regardless of structure: what is the vendor's concentration risk profile — are there key personnel whose departure would materially affect the product?

A vendor who is acquired during a contract term may represent either an improvement (a better-resourced parent) or a risk (new owner with different priorities, platform deprecation, price increases). Document your understanding of this risk and reflect it in the contract's change of control provisions.

The Evaluation Scorecard

The evaluation scorecard is the formal record of the evaluation. All evaluators use the same scorecard. Scores are recorded before discussion, then discussed and reconciled. The final weighted scores produce a ranked list of vendors. The rationale for deviations from the score-implied ranking — and there will sometimes be legitimate deviations based on qualitative factors — must be documented.

Section 6: Contract Negotiation — The Non-Negotiables

This is the section Rafael writes with the most conviction and the most frustration. Contract negotiation is where Procurement Traps are set. It is also where they can be avoided — if the compliance function is present, engaged, and prepared to delay signing until the contract is right.

The following provisions are not nice-to-haves. They are requirements. For a Tier 1 RegTech vendor, every one of these provisions must be in the contract. For Tier 2 vendors, the list may be slightly reduced, but the core protections remain.

Service Level Agreements

The SLA is the contractual expression of the vendor's non-functional commitments. It must be specific, measurable, and meaningful in its remedies.

Uptime guarantee: 99.5% availability sounds impressive. It permits 43.8 hours of annual downtime. 99.9% permits 8.76 hours. 99.99% permits 52 minutes. For a transaction monitoring system processing real-time payments, 99.9% is the minimum acceptable. For a surveillance platform running overnight batch processing, 99.5% may be tolerable. Know your requirement before you accept the vendor's standard.

Incident response timelines: The SLA must specify response and resolution times for different incident severity levels. Severity 1 (complete service unavailability): response within 15 minutes, update every 30 minutes, target resolution within 4 hours. Severity 2 (significant degradation of service): response within 1 hour, resolution within 8 hours. These are examples — the specific timelines must reflect the firm's operational and regulatory context.

SLA remedies: This is the provision most commonly inadequate in standard vendor contracts. A service credit of 10-15% of the monthly fee for an SLA breach is not a meaningful remedy. It does not reflect the cost to the firm of a compliance failure, a regulatory breach, or the operational disruption of a major outage. The remedy for serious or repeated SLA failures must include the right to terminate the contract for cause, without penalty, with the vendor's cooperation in the transition. This provision — termination for persistent SLA failure — is the one vendors resist most strongly and the one the compliance team must insist on most firmly.

Data Ownership and Portability

Who owns the data in the vendor's platform? The answer should be obvious — the firm generated the data, the firm owns the data — but standard vendor contracts frequently obscure this through language granting the vendor broad rights to use, aggregate, and analyze client data for product development, benchmarking, or "service improvement" purposes.

The contract must state explicitly: - The firm owns all data it provides to the vendor and all data generated by the firm's use of the platform (alert data, case data, decision data). - The vendor may not use the firm's data for any purpose other than service provision without explicit written consent. - On termination (for any reason), the vendor must provide a complete export of all the firm's data in a documented, machine-readable format within 30 days. - The vendor must maintain the ability to export data throughout the contract term, not just at termination.

Data portability provisions are frequently inadequate in standard contracts. The most common failure mode is "data provided in commercially reasonable format" — which, as noted at the start of this chapter, means whatever the vendor finds convenient. "Commercially reasonable" must be replaced with a specific format requirement: CSV with defined field mapping, JSON with documented schema, or a named industry-standard format.

Audit Rights

Under DORA Article 29(3)(j), financial entities are required to have audit rights over their ICT third-party service providers for arrangements involving important or critical functions. This is a legal requirement. The contract must reflect it.

The audit right provision must include: - The firm's right to conduct (or commission) an audit of the vendor's relevant systems, controls, and documentation, with reasonable notice (typically 30-60 days). - The right to engage a qualified third party (a Big 4 firm, a specialist security assessor) to conduct the audit on the firm's behalf. - Access to the vendor's most recent SOC 2 report, penetration test results, and business continuity test results annually or upon request. - The vendor's obligation to respond in writing to audit findings and to provide a remediation plan within 30 days. - The right to share audit results with the firm's regulator upon request.

Vendors — particularly smaller vendors and those who have historically served non-financial services clients — sometimes resist audit rights provisions on the grounds of operational disruption or confidentiality. This resistance is not a negotiating position the compliance team should accommodate. If a vendor will not accept a DORA-compliant audit right provision, it is not a vendor a regulated entity can use for an important or critical function. That conversation should happen before six months of evaluation work have been invested.

Exit Assistance

The provision that is most absent from standard contracts, and most costly in its absence, is exit assistance. Exit assistance is the vendor's obligation to actively support the firm's transition to an alternative provider when the contract ends.

A complete exit assistance provision should specify: - A transition period of not less than six months from notice of termination (regardless of which party terminates). - During the transition period, the vendor continues to provide the service at the same SLA, at the same price (or a defined transition price). - The vendor provides a complete data export at the start of the transition period and upon request during it. - The vendor provides access to its technical team to support the firm's transition team in configuring a replacement system. - The vendor provides documentation of all customizations, configurations, and integrations implemented during the contract term. - The vendor cooperates with the replacement vendor's technical team for data migration and integration transfer.

Exit assistance provisions that specify "commercially reasonable efforts" without defining what those efforts consist of are not adequate. Vendors under competitive or financial pressure have no incentive to provide commercially reasonable transition support unless the contract compels specific obligations.

Pricing and Escalation

The pricing provisions must address:

Base pricing: The contract price must be defined clearly, with explicit statements of what is and is not included. "Unlimited users" means unlimited users. "Up to 500,000 transactions per month" means the pricing structure changes when that threshold is crossed, and the new pricing must be pre-agreed, not subject to future negotiation.

Annual escalation cap: Price escalation must be capped. The cap must be defined numerically, not by reference to an index that the firm cannot control. CPI-linked escalation is defensible; 8% uncapped compounding escalation (as in Rafael's opening contract) is not. A cap of 3-5% annually is a common negotiating outcome for Tier 1 vendors; lower caps are achievable for multi-year commitments.

Change order process: When new features, integrations, or configurations are required, how is the pricing for those changes determined? A contract that is silent on change orders creates unlimited vendor pricing power for any deviation from the initial scope. The contract must specify: fixed-price changes for defined categories (additional user licenses, additional jurisdictions, standard integrations); and a time-and-materials rate card with a defined cap for bespoke development.

Regulatory change: When regulatory requirements change (a new reporting format, a new typology requirement, an updated data standard), is the vendor obligated to update the platform at its own cost? For core regulatory functionality — the reason the firm bought the platform — the answer must be yes. A vendor who treats every regulatory update as a billable change order is not acting as a compliance partner; it is acting as an opportunistic contractor.

Subcontracting

Under GDPR Article 28, a data processor (the vendor) who engages a sub-processor must obtain the data controller's (the firm's) prior written authorization. The contract must reflect this:

• The vendor must notify the firm of any new sub-processor engagement before it takes effect.
• The firm has the right to object to a new sub-processor.
• If the firm objects and the vendor proceeds, the firm has the right to terminate the contract without penalty.
• The vendor's sub-processor contracts must impose data protection obligations at least equivalent to those in the firm's contract with the vendor.
• The vendor remains fully liable for sub-processor performance and data handling.

Under DORA, the subcontracting chain for ICT services is also subject to scrutiny. For critical functions, the firm should have visibility of the full sub-service provider chain — not just the immediate vendor relationship.

Business Continuity

The vendor must have a documented, tested business continuity plan and disaster recovery plan. The contract must require:

• Annual BCP/DRP testing (tabletop or live), with results available to the firm.
• Notification to the firm within a defined timeframe (typically 2-4 hours) if the vendor experiences an incident that affects or is likely to affect service delivery.
• The vendor's obligation to invoke its BCP/DRP when relevant, with notification to the firm as part of that invocation.
• An agreed failover architecture — if the primary data center fails, what is the secondary and what is the target RTO?

For DORA-covered arrangements, the vendor's BCP/DRP must be detailed enough to satisfy the regulatory requirements for the firm's own operational resilience documentation. Firms should request the vendor's BCP/DRP documentation as part of due diligence and verify that it is adequate before contract signature.

Liability and Indemnification

Standard vendor contracts cap liability at the fees paid in the preceding 12 months. For a £340,000-per-year contract, that means a maximum liability of £340,000 — regardless of the actual harm caused by vendor failure.

This cap is inadequate in a RegTech context. The harm from a compliance platform failure — regulatory fines, remediation costs, customer redress, reputational damage — can far exceed 12 months of fees. The following provisions must be negotiated:

• Uncapped liability for data breaches: Where the vendor's breach of its data security obligations results in a personal data breach, the liability cap must be lifted or substantially increased.
• Regulatory fine indemnification: Where a regulatory fine or enforcement action is causally linked to a vendor failure — the platform failed to generate an alert it was configured to generate; the regulatory report contained errors caused by a vendor software defect — the vendor must indemnify the firm for the resulting fine.
• Consequential loss carve-outs: Standard contracts exclude consequential loss. In RegTech, consequential loss (regulatory fines, remediation costs) is the primary harm. Negotiate specific carve-outs for regulatory fines caused by vendor failure.

These are the provisions vendors resist most strongly, because they are the provisions that would make vendor failure most costly. That resistance is precisely why they matter.

The Vendor Evaluation Scorecard — Python Implementation

The following code implements the weighted scorecard framework described in this chapter, allowing compliance teams to run a structured, auditable vendor evaluation:

from dataclasses import dataclass, field
from typing import Optional


@dataclass
class EvaluationCriterion:
    name: str
    weight: float  # 0.0 to 1.0, all weights must sum to 1.0
    max_score: int = 10


@dataclass
class VendorScore:
    vendor_name: str
    scores: dict[str, int] = field(default_factory=dict)  # criterion name -> score
    notes: dict[str, str] = field(default_factory=dict)

    def weighted_score(self, criteria: list[EvaluationCriterion]) -> float:
        total = 0.0
        for criterion in criteria:
            if criterion.name in self.scores:
                score = self.scores[criterion.name]
                total += (score / criterion.max_score) * criterion.weight * 100
        return total

    def score_for(self, criterion_name: str) -> Optional[int]:
        return self.scores.get(criterion_name)


@dataclass
class VendorEvaluation:
    project_name: str
    criteria: list[EvaluationCriterion] = field(default_factory=list)
    vendors: list[VendorScore] = field(default_factory=list)

    def validate_weights(self) -> bool:
        total = sum(c.weight for c in self.criteria)
        return abs(total - 1.0) < 0.001

    def ranked_vendors(self) -> list[tuple[str, float]]:
        """Return vendors ranked by weighted score, highest first."""
        scored = [
            (v.vendor_name, v.weighted_score(self.criteria))
            for v in self.vendors
        ]
        return sorted(scored, key=lambda x: x[1], reverse=True)

    def scorecard_report(self) -> str:
        if not self.validate_weights():
            return "ERROR: Criteria weights do not sum to 1.0"

        lines = [f"Vendor Evaluation: {self.project_name}", "=" * 50]
        ranked = self.ranked_vendors()
        for rank, (name, score) in enumerate(ranked, 1):
            lines.append(f"{rank}. {name}: {score:.1f}/100")
        return "\n".join(lines)


# Example usage: AML Transaction Monitoring Platform selection
evaluation = VendorEvaluation(project_name="AML Transaction Monitoring — Cornerstone Financial Group")

# Define weighted criteria (must sum to 1.0)
evaluation.criteria = [
    EvaluationCriterion("Functional Capability", weight=0.25),
    EvaluationCriterion("Regulatory Compliance", weight=0.20),
    EvaluationCriterion("Technical Architecture", weight=0.15),
    EvaluationCriterion("Implementation Approach", weight=0.15),
    EvaluationCriterion("Financial Stability", weight=0.10),
    EvaluationCriterion("Pricing / Value", weight=0.10),
    EvaluationCriterion("Contract Flexibility", weight=0.05),
]

# Score vendors (0-10 per criterion)
vendor_a = VendorScore(vendor_name="VendorAlpha")
vendor_a.scores = {
    "Functional Capability": 8,
    "Regulatory Compliance": 9,
    "Technical Architecture": 7,
    "Implementation Approach": 7,
    "Financial Stability": 9,
    "Pricing / Value": 6,
    "Contract Flexibility": 5,
}
vendor_a.notes["Contract Flexibility"] = (
    "Resisted audit rights; escalation cap not agreed"
)

vendor_b = VendorScore(vendor_name="VendorBeta")
vendor_b.scores = {
    "Functional Capability": 7,
    "Regulatory Compliance": 8,
    "Technical Architecture": 8,
    "Implementation Approach": 9,
    "Financial Stability": 6,
    "Pricing / Value": 8,
    "Contract Flexibility": 9,
}
vendor_b.notes["Financial Stability"] = (
    "Series B only; 18-month runway documented"
)

evaluation.vendors = [vendor_a, vendor_b]

print(evaluation.scorecard_report())
# Output:
# Vendor Evaluation: AML Transaction Monitoring — Cornerstone Financial Group
# ==================================================
# 1. VendorBeta: 77.5/100
# 2. VendorAlpha: 75.5/100

The scorecard separates the financial attractiveness of Vendor Alpha from the contractual risk embedded in its unwillingness to accept audit rights. Vendor Beta's slightly lower functional score is outweighed by its superior implementation track record and contractual flexibility — the factors that will determine the experience after go-live.

This is the point of the scorecard: to make trade-offs visible before they become commitments.

Section 7: Implementation Management

Signing the contract is not the end of the procurement process. It is the beginning of the implementation process — and implementation failure is as common as contract failure, and often more immediately damaging.

The most common cause of implementation failure is not technical complexity. It is governance failure: unclear ownership, compressed timelines, underdefined acceptance criteria, and the gradual erosion of scope discipline as go-live pressure mounts.

The Three Phases of Implementation

Phase 1: Mobilization (typically 4-8 weeks) Mobilization is the setup phase. The governance structure is established: who is the project sponsor, who is the vendor project manager, who is the client project manager, what is the steering committee composition and cadence? The implementation plan is finalized and baselined — not "reviewed and accepted," but baselined, meaning any deviation from it triggers a formal change control process. The data mapping documentation is completed: every data field that will flow from existing systems to the new platform is identified, mapped, and validated for completeness and quality. The environment is provisioned: development, test, and production instances; user access; integration connectivity. Issues identified in mobilization that are not resolved — data quality problems, integration complexity, resource availability — do not disappear in the next phase. They become more expensive.

Phase 2: Build and Configure (typically 8-16 weeks, depending on complexity) This phase is where the platform is configured to the firm's specific requirements: typologies calibrated to the firm's customer and transaction profile, thresholds set and validated, workflows configured, integrations built and tested, user roles and permissions established. The build phase requires active participation from the firm's compliance team — not just the technology team. The people who will use the system must be involved in the configuration decisions that determine how it behaves. Configuration decisions made without compliance input produce a system that is technically functional but operationally wrong.

Phase 3: Go-Live and Hypercare (30-90 days post-activation) Go-live is the moment of activation. But go-live is not the end of the implementation — it is the beginning of the most vulnerable period. The first 30-90 days after go-live (the hypercare period) are when the gap between configuration assumptions and operational reality is discovered. Alert volumes are higher or lower than expected. Integration feeds drop data in unexpected circumstances. Users find workarounds that bypass the system's intended workflow. In the hypercare period, the vendor's support team should be actively engaged — not in a break-fix capacity, but in a continuous monitoring and optimization capacity.

User Acceptance Testing

UAT is the formal process by which the firm's business and compliance users verify that the configured system meets the agreed requirements before go-live. UAT is consistently underinvested — it is the phase that is compressed when the project falls behind schedule — and consistently the source of post-go-live failures.

Effective UAT requires: - A documented test plan, aligned to the original requirements document - Specific test cases that test edge cases and failure scenarios, not just happy paths - Participation by actual users — not just project team members who have been involved throughout and understand the system's quirks - A formal defect management process: issues found in UAT are logged, classified by severity, and tracked to resolution - A clear go/no-go criterion: what defect count and severity distribution makes the system ready for go-live? This criterion must be agreed before UAT begins, not after.

The most common UAT failure is the "good enough" judgment — "there are still 47 open defects but we have a regulatory deadline, so we're going live." Priya Nair's case study in this chapter's supplementary materials describes exactly what happens next.

Data Migration

Data migration is the process of moving historical data — past alerts, case records, customer risk ratings, transaction history — from existing systems into the new platform. It is consistently underestimated.

The underestimation has a pattern. The firm knows what data it has in the old system. The vendor knows what data its platform requires. The distance between those two things — the mapping, transformation, cleansing, and validation required to bridge them — is where the surprise is.

Data migration planning must begin during mobilization. The migration scope must be formally agreed: what historical data is migrated, over what time period, at what level of completeness? The migration must be tested in the test environment before it is run in production. The production migration must have a validation step — a defined process to verify that migrated data is complete, accurate, and accessible. And there must be a rollback plan: if the migration fails validation, what happens?

Training

Training for a RegTech platform should not be treated as a product demo. It should be treated as a compliance process orientation.

The difference matters. A product demo teaches users what buttons to press. Compliance process orientation teaches users why they are pressing them — what the regulatory obligation behind the workflow is, what the consequences of the wrong decision are, and what the escalation path looks like when they encounter something unexpected.

Training should be role-differentiated: analysts who work the alert queue need different training from supervisors who review case closures, who need different training from managers who monitor the system's overall performance. Training should be documented — for regulatory purposes, the firm must be able to demonstrate that its staff were trained on the system and what that training covered. And training should not be a one-time event — as the system is updated and as regulatory requirements evolve, training must be refreshed.

Go-Live Planning

The decision between a phased rollout and a big-bang go-live is one of the most consequential in implementation management, and it is rarely given enough consideration.

A phased rollout — activating the system for one business unit, one geography, or one transaction type before full deployment — reduces risk but extends the period during which the firm is operating two systems simultaneously. The parallel operation creates its own operational complexity and compliance exposure: which system is the system of record? What happens when the two systems produce different results?

A big-bang go-live — full activation on a single date — concentrates risk in a single moment but eliminates the parallel operation complexity. It requires a higher degree of pre-go-live confidence and a robust rollback plan.

The rollback plan is not optional. It is the answer to the question: "If we activate the system tomorrow morning and discover a critical problem by noon, what do we do?" The rollback plan specifies the trigger conditions, the decision authority, the operational steps, and the timeline for reverting to the previous system. A rollback plan that cannot be executed within four hours is not a rollback plan.

The Hypercare Period

The 30-90 days after go-live are the most operationally demanding in any implementation. Alert volumes are unpredictable. Users are slow and uncertain. Integration issues that were not caught in testing emerge under production conditions. The vendor's support team is an essential resource during this period.

The hypercare provisions must be agreed contractually before implementation begins. Hypercare support should include: dedicated vendor support personnel (not a shared support queue), daily status calls for the first two weeks, weekly status calls thereafter, and a defined escalation path for critical issues that bypasses the standard ticket queue.

Post-hypercare, the transition to standard operational support should be gradual, not abrupt. The first 90 days post-go-live are when the firm's operational team is developing the muscle memory that will sustain the system. They need the vendor present and responsive while that memory is being built.

Section 8: Post-Implementation Governance

Implementation ends. Vendor relationship management does not. The Procurement Trap's most insidious version is the trap of post-implementation neglect — signing a good contract, running a successful implementation, and then allowing the vendor relationship to deteriorate into passive consumption with no active oversight.

Ongoing Relationship Management

A formal vendor review cadence must be established and maintained:

Quarterly Reviews: Operational performance against SLAs; outstanding incidents and their resolution status; upcoming product releases and their impact on the firm's operations; regulatory developments relevant to the platform's function; open issues and escalations. The quarterly review is attended by the firm's vendor relationship manager and compliance owner, and the vendor's account manager and a technical representative.

Annual Assessments: A comprehensive review of the vendor's performance over the year against all dimensions of the original due diligence framework. Financial health review: has the vendor's funding or ownership position changed? Technical security review: have there been significant incidents, changes to the security architecture, or changes to sub-processors? Contractual compliance review: has the vendor met its contractual obligations? Market assessment update: have better alternatives emerged?

The annual assessment should be documented and retained. It is the evidence that the firm is exercising ongoing oversight of its third-party ICT risk — the evidence that regulators will request when they examine the firm's DORA or operational resilience compliance.

SLA Monitoring

SLA monitoring must be operationalized — it cannot be reactive. The firm must have an independent mechanism for tracking vendor SLA performance, not just the vendor's self-reported metrics. This typically means:

• Automated uptime monitoring using a tool independent of the vendor's platform
• An incident log maintained by the firm, not just the vendor
• Monthly SLA compliance reports from the vendor, reviewed by the firm's vendor relationship manager
• A formal process for raising SLA disputes when the firm's records and the vendor's records diverge

When SLA failures occur, the remedy process must be activated promptly. Delayed activation — "we'll raise it at the quarterly review" — creates a de facto waiver of the remedy. Contract provisions that are not actively enforced are not provisions.

Concentration Risk Monitoring

As the firm's use of and dependence on a vendor grows, the concentration risk may evolve beyond its original assessment. The platform that was initially a Tier 2 vendor may have become operationally Tier 1 as the firm's reliance on it deepened. The vendor that served 30% of the firm's transaction monitoring needs at contract signature may now serve 90% following a system consolidation.

Annual assessments should explicitly review concentration risk and update the tier classification if appropriate. Increased tier classification should trigger enhanced due diligence and, where necessary, enhanced contractual protections or the development of contingency alternatives.

Section 9: The Procurement Trap — Rafael's Rules

After fifteen years of compliance integration consulting — and more post-mortems on bad vendor contracts than he would like to count — Rafael Torres distills his experience into ten rules. He shares them with every client at the beginning of every engagement. They are not complicated. They are not novel. They are the rules that, when followed, prevent the call he too often receives eighteen months after contract signature.

Rule 1: Requirements Before Conversations. Never speak to a vendor until your requirements document is complete and signed off. Every conversation before requirements are complete is a conversation in which the vendor is shaping your requirements. Some of that shaping is helpful; all of it is self-interested.

Rule 2: Three Bids Minimum for Any Significant Investment. Not because the third bid will necessarily be better, but because the discipline of running three bids forces the evaluation discipline that produces good decisions. A sole-source procurement — regardless of how compelling the vendor appears — is a procurement that has not been adequately challenged.

Rule 3: Never Buy from a Vendor Who Cannot Provide Three Reference Clients at Similar Scale. The vendor whose only references are large global banks is not proven for a mid-size challenger bank. The vendor who has no UK-regulated references is not proven for FCA-regulated deployment. References at comparable scale and comparable regulatory profile are not a nice-to-have — they are evidence of fitness for your specific purpose.

Rule 4: Read Every Word of the Contract Before Signing. Not the summary. Not the executive overview. Every word. Then have compliance counsel read every word. The provisions that create the most problems are never in the sections that get the most attention. They are in the definitions, the limitation of liability, the force majeure, and the termination provisions.

Rule 5: Negotiate Audit Rights as a Must-Have, Not a Nice-to-Have. If a vendor will not accept DORA-compliant audit rights, it is not a vendor a regulated financial entity can use for an important or critical function. This is not a negotiating position. It is a legal requirement. The conversation should happen early enough that it is not a surprise when it becomes a deal-breaker.

Rule 6: Plan the Exit Before You Sign the Entry. Before you sign, ask: "If this vendor fails us in Year 3, how do we leave?" If the answer is unclear, the exit provisions in the contract are inadequate. Exit assistance provisions are easier to negotiate before you are committed than after you are trapped.

Rule 7: Own Your Data — Make Sure You Can Extract It. Your data is not the vendor's data. It is your compliance record, your operational history, your regulatory evidence base. It must be exportable, in a documented format, at any point during the contract term and immediately upon termination. If the vendor cannot demonstrate the export capability in the proof of concept, that is a red flag, not a punch list item.

Rule 8: SLA Remedies Must Include the Right to Terminate, Not Just Credits. A service credit for an SLA failure is the vendor compensating itself for its own failure at a fraction of the actual cost. The right to terminate for persistent or material SLA failure — executed without penalty, with full exit assistance — is the only remedy that creates the incentive for the vendor to maintain service quality.

Rule 9: The Implementation Budget Should Equal the License Budget. This is the heuristic that compliance teams most frequently get wrong. The license fee is the annual platform cost. The implementation cost — integration, data migration, configuration, training, testing — typically equals the first year's license fee for a complex Tier 1 platform. Plan for it. Budget for it. Do not be surprised by it.

Rule 10: Day-1 Post-Go-Live Governance Is as Important as Implementation. The governance structures, monitoring practices, and vendor management disciplines that sustain the vendor relationship over its full term must be in place before go-live, not planned for "after things settle down." Things never settle down. The operational environment changes, regulations change, vendors change. Day-1 governance is what makes a successful implementation into a durable compliance capability.

Summary

Vendor selection and implementation management in RegTech is not a technology function with compliance approval at the end. It is a compliance function that happens to involve technology procurement. The regulatory obligations — DORA Articles 28-30, the FCA operational resilience framework, the CTP regime — attach to the process, the documentation, and the outcomes of vendor selection. They create legal requirements for what must be in the contract, what ongoing oversight must look like, and what the firm must be able to demonstrate to regulators when asked.

The Procurement Trap is not a trap of malice — vendors do not generally set out to lock in clients with bad contracts. It is a trap of asymmetric information and asymmetric urgency. The vendor has executed this contract before. The compliance team, under pressure to solve a regulatory problem, is executing it for the first time. The chapter's purpose — and Rafael's purpose — is to close that asymmetry: to give compliance teams the knowledge, the frameworks, and the negotiating positions that transform a procurement event into a durable compliance partnership.

The ten rules are not the last word on vendor procurement. They are the starting point. The details — the specific contract provisions, the specific evaluation criteria, the specific implementation governance structure — must be calibrated to the firm's specific context, its regulatory profile, its operational capability, and the specific vendor and platform being considered.

But the rules are the floor. No professional responsible for a RegTech vendor procurement should leave the table without them.

Next: Chapter 37 — Building and Scaling a RegTech Function: People, Processes, and Organizational Design