Chapter 36 Exercises — Vendor Selection, Due Diligence, and Implementation Management

Exercise 36.1 — RFP Section Drafting: Functional and Regulatory Requirements

Scenario

Verdant Bank, a UK challenger bank with 340,000 retail customers, processes approximately 2.8 million transactions per month across current accounts, savings accounts, and personal loans. Its current KYC/Customer Due Diligence process relies on a manual-intensive workflow: customer documents are uploaded to a shared drive, reviewed by KYC analysts, and rated using a spreadsheet-based risk scoring model. The process takes an average of 4.2 days per new customer onboarding and has a backlog of 1,400 pending reviews. Maya Osei, Verdant's CCO, has obtained board approval to procure an automated KYC/CDD platform.

Verdant is subject to the UK Money Laundering Regulations 2017 (as amended), FCA SYSC requirements for systems and controls, and the JMLSG guidance on customer due diligence. Verdant does not currently have a DORA obligation but expects to be subject to the FCA's equivalent operational resilience framework. Verdant processes personal data of UK individuals under UK GDPR.

Task

Draft the functional and regulatory requirements sections of the RFP for Verdant Bank's KYC/CDD platform procurement. Your requirements document should include:

Part A — Functional Requirements (10-12 requirements) Write each functional requirement in the format: "The system MUST [specific, measurable, outcome-oriented statement]." Requirements should be specific enough to distinguish between systems that meet the requirement and those that do not. Include requirements covering: - Document capture and verification - Identity verification (including liveness detection) - Risk scoring and classification (minimum three risk tiers) - Workflow and queue management for analyst review - Ongoing monitoring and periodic review triggers - Case management and escalation - Watchlist screening integration - Audit trail and recordkeeping

Part B — Regulatory Requirements (6-8 requirements) Write specific regulatory requirements derived from the UK MLRs 2017, FCA SYSC, JMLSG guidance, and UK GDPR. For each requirement, identify the specific regulatory source. Include requirements covering: - GDPR Article 28 data processing agreement - Audit trail retention (with specific retention period) - Risk-based approach documentation - Regulatory reporting output capability - Data residency (UK data processing) - Regulatory change update obligation

Part C — Sign-Off Assessment Identify the five internal stakeholders who should review and sign off the completed requirements document before any vendor engagement begins. For each stakeholder, state what aspect of the requirements is within their review scope and why their sign-off is necessary.

Guidance Notes

Well-written functional requirements use precise, testable language. "The system should support efficient onboarding" is not a functional requirement. "The system MUST complete automated document verification within 90 seconds of document upload for 95% of all submissions" is a functional requirement. The precision matters because these requirements become the UAT test cases — if a requirement cannot be tested, it cannot be confirmed as met.

Regulatory requirements should trace directly to a named provision or guidance. "The system must be GDPR compliant" is not a regulatory requirement. "The system must process personal data only under a Data Processing Agreement that complies with UK GDPR Article 28, specifying the categories of data processed, the purposes of processing, the sub-processors used, and the security measures applied" is a regulatory requirement.

Exercise 36.2 — Scorecard Design: Building a Weighted Vendor Evaluation Framework

Scenario

Cornerstone Financial Group, a diversified UK financial services group with banking, insurance, and wealth management divisions, is selecting a new regulatory reporting platform to consolidate its MiFIR transaction reporting, EMIR trade reporting, and SFTR securities financing transaction reporting across all three divisions. The current state involves three separate systems — one for each division — operated by different technology teams with no shared data model or reporting governance.

The platform will be classified as Tier 1 under Cornerstone's third-party risk framework. It will be subject to DORA Article 30 requirements (critical function). The procurement budget is £2.4 million for implementation and the first two years of license. The RFP has been issued to six vendors.

Task

Part A — Criteria Definition Define eight to ten evaluation criteria appropriate for this specific procurement. For each criterion, write: - The criterion name - A one-sentence description of what is being evaluated - The rationale for including this criterion (what risk or requirement does it address?) - Whether it is a threshold criterion (failure means elimination) or a weighted criterion

Include at minimum: - One threshold criterion (binary: pass/fail) - At least one criterion specifically addressing DORA compliance - At least one criterion addressing the cross-divisional consolidation context - At least one criterion addressing the vendor's approach to regulatory change

Part B — Weight Assignment Assign weights to all weighted criteria such that the weights sum to 100%. Prepare a brief written justification for the weighting of each criterion — not just a number, but a sentence explaining why this criterion deserves this weight relative to the others.

Part C — Scoring Rubric For two of your weighted criteria, develop a detailed scoring rubric (0-10 scale) that defines what a score of 0, 3, 5, 7, and 10 looks like. The rubric must be specific enough that two different evaluators would assign the same score when reviewing the same vendor response. Vague rubrics ("8-10: excellent; 5-7: good; 0-4: poor") are not sufficient.

Part D — Calibration Protocol Describe the calibration process you would run before evaluators begin scoring — specifically, how you would ensure that the five evaluators on the evaluation team interpret the criteria and scoring rubrics consistently before they score independently.

Guidance Notes

The exercise of assigning weights forces explicit prioritization. When compliance officers say "everything is important," they mean that every criterion is relevant — but in a scoring context, equal weights are rarely the honest answer. A Tier 1 compliance platform for a DORA-covered firm places regulatory compliance capability in a different position than pricing. The weight assignment is an expression of the firm's risk priorities, and it should be defensible to a regulator who asks why a vendor with a lower price but weaker audit right provisions was not selected.

Exercise 36.3 — Contract Gap Analysis: Identifying Missing Provisions

Scenario

You have been asked to review the draft contract that Meridian Asset Management (a £6 billion UK UCITS fund manager) has received from a vendor of a compliance monitoring and conduct risk platform. Meridian is Tier 1-classifying this vendor under DORA. The following is a summary of what the draft contract currently contains:

Provisions present in the draft contract: - License grant (SaaS, multi-tenant deployment) - License fees: £220,000 per year, with "annual adjustments in line with RPI" - Uptime guarantee: 99.2% with monthly service credits of 5% per hour of downtime below threshold - IP ownership: vendor retains all IP; customer receives usage license - Support services: email support, response within two business days - Termination: 12 months' notice by either party for convenience; immediate termination for material breach - Confidentiality: standard mutual confidentiality - Limitation of liability: vendor liability capped at 12 months' fees - Governing law: English law; exclusive English jurisdiction - Data protection: brief clause confirming vendor will act as data processor; no GDPR Article 28 detail - Subcontracting: vendor may subcontract without notice

Task

Part A — Gap Identification Identify all material gaps in this contract against the standard of DORA Articles 28-30, GDPR Article 28, and the chapter's contract non-negotiables framework. For each gap, specify: - The missing provision - The regulatory or contractual basis for the requirement - The risk that the absence of the provision creates - A brief statement of what the provision should say

You should identify at least eight material gaps.

Part B — Risk Prioritization Rank the gaps you have identified in order of priority — that is, in the order in which you would raise them with the vendor, if you could only negotiate five provisions before a final deadline. Provide written justification for the ordering, specifically addressing: (1) which gaps create direct regulatory compliance risk; (2) which gaps create the greatest commercial exposure over the full contract term; and (3) which gaps, if not addressed, would be most difficult to remediate post-signing.

Part C — Negotiating Position For the three highest-priority gaps, draft the specific contract language you would propose to the vendor. Your proposed language should be precise, legally clear, and compliant with the requirements you identified in Part A. Annotate each proposed clause to explain the key terms and why they are necessary.

Guidance Notes

The gap analysis is an exercise in reading what is absent as carefully as what is present. A contract that says "vendor may subcontract without notice" is not a contract that has simply omitted a notice requirement — it is a contract that has affirmatively granted the vendor the right to engage any sub-processor for any purpose without the data controller's knowledge or approval. That is a GDPR Article 28 violation, not a drafting gap.

The distinction between a drafting gap (something that was not addressed) and an affirmative conflict (something that contradicts a legal requirement) matters for the negotiation. A gap can be filled by adding a clause. An affirmative conflict requires removing or replacing existing language, which vendors sometimes resist on the grounds that the existing language reflects their standard terms.

Exercise 36.4 — Implementation Planning: Designing a Deployment Plan

Scenario

Cornerstone Financial Group's treasury operations division has selected a vendor for a new liquidity risk management and regulatory reporting platform (covering LCR, NSFR, and ILAAP reporting requirements). The platform is classified as Tier 1. The contract has been signed. The implementation is to begin on September 1 with a target go-live of February 28 (six months).

Known implementation context: - The platform replaces a legacy in-house system that has been in operation for nine years - There are approximately 280,000 historical data records that must be migrated to establish the platform's lookback period for regulatory calculations - The platform requires integration with three existing systems: the core banking ledger (API available), the collateral management system (no API; requires file-based integration), and the Group's DORA-compliant incident management system (webhook-based) - The end-user population is 14 people: 8 treasury analysts, 4 compliance officers, 2 senior managers - The regulatory reporting submissions that will run through the new platform include monthly LCR and NSFR reports (submission deadline: 15th of the following month), and an annual ILAAP document - The first LCR/NSFR submission due through the new system is March 15 (two weeks after go-live)

Task

Part A — Implementation Phase Plan Develop a high-level implementation plan covering the three phases described in Chapter 36 (Mobilization, Build/Configure, Go-Live and Hypercare). For each phase: - Define the phase duration and start/end dates - List 4-6 key milestones with target dates - Identify the critical dependencies (what must be true before this phase can proceed?) - Identify the top two risks to this phase and the proposed mitigation for each

Part B — UAT Design Design the UAT approach for this implementation. Specify: - The scope of UAT (what will be tested) - The UAT participant roles (who will test what) - The number of test cases and the logic for that number (how did you arrive at it?) - The severity classification system for defects found in UAT - The go/no-go criteria (what must be true before the CCO approves go-live?) - The decision-making process and authority if the go/no-go criteria are not met by the target UAT completion date

Part C — Rollback Plan Design the rollback plan for the February 28 go-live. The rollback plan must be executable within four hours of a go-live failure decision. Specify: - The trigger conditions that would activate the rollback decision - The decision authority (who makes the call and within what timeframe?) - The operational steps (in sequence) for reverting to the legacy system - The operational procedure for the regulatory reporting obligation (the March 15 deadline) if the rollback is activated - How the firm would communicate with its regulator if a rollback is activated

Part D — Post-Go-Live Governance Describe the governance structure you would put in place from Day 1 post-go-live. Cover: - The hypercare review cadence (frequency, participants, agenda) - The SLA monitoring mechanism (how will uptime and performance be tracked independently of the vendor's self-reporting?) - The escalation path for critical issues during hypercare - The criteria and timeline for transitioning from hypercare support to standard operational support - The quarterly vendor review structure that will sustain the relationship after hypercare ends

Guidance Notes

Implementation planning for a compliance platform requires two things simultaneously: a realistic assessment of what is technically complex (the collateral management system integration with no available API is a material risk that must be addressed in the plan), and a clear line of sight to the regulatory deadline (the March 15 LCR/NSFR submission is the hard constraint that shapes the entire plan). When these two requirements are in tension — as they often are — the plan must make the tension explicit and present options, not paper over it with optimistic scheduling.

The hardest part of this exercise is the rollback plan, because it requires confronting a scenario that most project teams find psychologically difficult: the possibility that the go-live will fail. Teams that do not plan for failure are teams that cannot execute a rollback efficiently when failure occurs. The plan you design should be specific enough that a member of the compliance team who had not been involved in the implementation at all could execute it, step by step, on the day it was needed.