Answers to Selected Exercises

Regulatory Technology (RegTech): Compliance Automation, Algorithmic Auditing, Computational Law

This appendix provides worked answers and answer guidance for selected exercises from across the textbook. For exercises requiring judgment, design, or ethical analysis — such as strategy questions, framework comparisons, and governance design — these answers illustrate one strong approach. Other approaches may be equally valid if rigorously argued and supported by evidence.

Quantitative exercises have definite answers; the calculations shown should be reproducible. Minor rounding differences (due to intermediate rounding choices) are acceptable provided the method is correct.

Exercises not appearing here should be completed using the chapter content, the further reading, and instructor guidance. The selection below prioritizes exercises where a model answer provides the most learning value: quantitative exercises where common errors arise, technical design exercises with multiple valid structures, and analytical exercises where the evaluative framework matters as much as the conclusion.

Chapter 5: Data Architecture

Exercise 5.1: Data Quality Dimension Identification

Answer:

a) Timeliness failure. The OFAC SDN list was not updated between Friday and Monday. The screening system checked against a list that did not include the newly added counterparty. Compliance consequence: the institution screened a transaction against an out-of-date watchlist, potentially processing a transaction with a newly sanctioned party without flagging it. This could constitute a sanctions violation. Regulators expect screening lists — particularly OFAC SDN — to be updated as close to real-time as feasible, not weekly. OFAC's guidance makes clear that the obligation runs from the moment a designation is published.

b) Consistency failure (also: standardization/conformity). The same person is represented differently across two systems. "JOHN SMITH" and "John Smith" are logically the same, but the systems do not recognize them as such because there is no name normalization applied before matching. Compliance consequence: duplicate records may be created in the golden record, breaking the single customer view. Customer risk ratings may be calculated separately on incomplete transaction pictures. EDD triggers may be missed.

c) Completeness failure. Eight months of transaction history was lost during migration. Compliance consequence: the transaction monitoring system cannot see the full behavioral baseline for customers in that product line. Anomaly detection is impaired — a transaction that appears normal against a partial history might flag against a complete one. Audit trail obligations under AML/regulatory frameworks cannot be met. Any investigation requiring historical data will be incomplete.

d) Conformity failure (also: standardization). The data is recorded in free text ("Business Owner") where a controlled vocabulary ("Self-Employed") was required. Compliance consequence: risk-rating logic that relies on occupation codes will apply the "Self-Employed" category to this customer, potentially incorrectly. Reporting that aggregates customers by occupation will be unreliable. Regulatory examination of KYC data quality will reveal inconsistency.

e) Uniqueness failure (also: identity resolution failure). The same corporate client has been onboarded twice under different name variations, creating duplicate records. Compliance consequence: the customer's complete transaction picture is split across two records, so no single view of their activity exists. AML transaction monitoring will not aggregate the full behavioral profile. The total exposure for credit risk reporting is split. BCBS 239 Principle 2 (data architecture and IT infrastructure) is undermined.

Exercise 5.2: Building a BCBS 239 Assessment

Answer:

The following assessment applies five of the eleven BCBS 239 principles. Other principle selections are valid; the quality of the assessment lies in the depth of reasoning and the specificity of remediations.

Principle 2 — Data Architecture and IT Infrastructure: NON-COMPLIANT BCBS 239 requires a single, authoritative data dictionary and defined data architecture. The bank has 12 source systems feeding risk data, no documented data lineage, and no data dictionary. Risk: when errors appear in reports, the bank cannot trace which system caused them or which fields are affected. Remediation: conduct a data architecture review across all 12 source systems; create a data catalogue identifying each risk data element, its source system, transformation logic, and owner.

Principle 3 — Accuracy and Integrity: NON-COMPLIANT Three report corrections in twelve months due to data errors indicates material accuracy failure. BCBS 239 expects institutions to be able to generate accurate and reliable risk data. Remediation: implement automated reconciliation controls at each stage of the data pipeline; establish error tracking and root cause analysis for all report corrections.

Principle 4 — Completeness: PARTIALLY COMPLIANT The principle requires that risk reporting capture all material risk exposures. With no formal data owner and no data lineage documentation, the bank cannot confirm that all relevant exposures are captured. The Pillar 2 report requiring 3 weeks of manual work suggests gaps in automated coverage. Remediation: assign formal data owners for all major risk data domains; conduct a completeness audit mapping regulatory report fields to source data.

Principle 6 — Adaptability (Ad Hoc Reporting): NON-COMPLIANT BCBS 239 requires that institutions be able to generate risk data and reports quickly, including on an ad hoc basis. The bank's 3-week manual process for the Pillar 2 report (a scheduled report) almost certainly means that ad hoc reporting to management or supervisors during stress is not feasible. Remediation: invest in a risk data warehouse or data lake capable of producing ad hoc queries without manual assembly; document the ad hoc reporting capability and test it against realistic scenarios.

Principle 12 — Governance: NON-COMPLIANT An annual data governance committee meeting and no formal data owner structure represent critically insufficient governance. BCBS 239 requires active oversight of data governance including clearly defined ownership. "IT is generally responsible for data" is not acceptable — IT manages systems, not data quality and business accuracy. Remediation: establish a Data Governance Committee that meets at minimum quarterly; assign data owners for all material risk data domains from the business side (not IT); create a formal escalation path for data quality issues.

Exercise 5.3: Designing a Customer Golden Record

Answer:

a) Customer golden record field categories:

Identity fields: Full legal name (primary), also-known-as names, date of birth, gender, nationality, national identifier (NI number, passport, driving licence), correspondence address, registered address (if different), email address, phone number(s).

KYC/verification fields: KYC status (active, expired, pending refresh), KYC tier (standard/enhanced), KYC verified date, KYC next review date, identity verification method (documentary/electronic), identity documents verified (type, issuer, expiry), beneficial owner link (if applicable), PEP status, sanctions screening status, adverse media status, last screen date.

Risk fields: Customer risk rating (Low/Medium/High), risk rating calculation date, risk rating rationale, EDD indicator, source of funds verified, source of wealth verified (private banking).

Account/product fields: Account list (IDs and types), relationship start date, relationship manager, primary product category, product history summary.

Operational fields: Customer unique identifier (golden record ID), source system IDs (cross-reference), data lineage log, last update timestamp, update source, consent preferences.

b) Authoritative source system per field category:

Identity fields (name, DOB, nationality, address) → KYC platform (has verified identity; core banking may have unverified data). National identifiers → KYC platform. KYC/verification fields → KYC platform (authoritative for all KYC data). Risk fields → KYC platform (risk rating computed here against verified data). Account/product data → Core banking (authoritative for account records). Relationship manager, product history → CRM. Consent preferences → CRM (if consent management is housed there) or dedicated consent store.

c) Survivorship rule for address conflict:

The KYC platform address should win. Reasoning: the KYC platform contains verified identity data — the address in the KYC platform should have been confirmed against a utility bill, bank statement, or electronic verification during the onboarding process. The core banking address may have been self-entered or may reflect a mailing address rather than a verified residential address. The survivorship rule should therefore be: KYC platform address prevails over core banking address for verified identity purposes. However, if a customer updates their address through core banking (e.g., via online banking), a trigger should be sent to the KYC platform to re-verify. Document the rule explicitly in the data governance policy.

d) Handling the Elizabeth/Liz Johnson identity matching problem:

Step 1 — Probabilistic matching: Run a probabilistic entity matching algorithm comparing shared attributes — date of birth, address, account number prefix, branch, product origination date. High-confidence matches (>85% similarity score) can be automatically linked as the same person pending human confirmation.

Step 2 — Human review: A KYC analyst reviews the flagged match, confirms shared attributes, and documents the decision.

Step 3 — Process: Contact the customer (using the more formal name "Elizabeth Johnson") and confirm that both accounts belong to her. Obtain written confirmation or voice-record confirmation (depending on channel).

Step 4 — Record update: Consolidate the records in the golden record, flagging "Elizabeth Johnson" as the verified legal name and "Liz Johnson" as an alias. Maintain the alias for matching purposes.

Note: this is precisely the situation that Master Data Management (MDM) tools with entity resolution capabilities are designed to handle at scale. Manual resolution is feasible for small volumes; automated probabilistic matching is essential for institutions onboarding thousands of customers per week.

Chapter 7: AML Transaction Monitoring

Exercise 7.3: False Positive Analysis

Answer:

Part a) Calculations:

Definitions: - False Positive Rate (FPR) = False Positives / (False Positives + True Negatives). For this exercise, True Negatives can be estimated, but since the total population is not given, use FPR = FP / Total Alerts (the operational false positive rate). - Precision = True Positives / Total Alerts (i.e., TP / (TP + FP)) - Recall = True Positives / (True Positives + False Negatives)

Part b) Analyst capacity by threshold:

At 30 alerts/analyst/day, with weekly runs:

• $5,000 threshold: 1,240 alerts ÷ 30 = 41.3 analyst-days ÷ 5 = 8.3 FTE-weeks per run cycle (clearly unmanageable).
• $10,000 threshold: 380 alerts ÷ 30 = 12.7 analyst-days = 2.5 FTE-weeks per run cycle.
• $15,000 threshold: 95 alerts ÷ 30 = 3.2 analyst-days = 0.6 FTE-weeks per run cycle.

Part c) Operational feasibility:

Available capacity: 2 analysts × 40 alerts/week = 80 alerts per week across all scenarios (but this scenario gets 40 alerts each, per the question).

The $5,000 threshold (1,240 weekly alerts) is clearly infeasible — it would require over 30 analyst-days per week just for this one scenario.

The $10,000 threshold (380 alerts) exceeds the 80-alert weekly budget and would be infeasible with 2 analysts absent additional capacity.

The $15,000 threshold (95 alerts) is operationally feasible within the 80-alert per analyst weekly budget, with some headroom for other scenarios.

Part d) Regulatory risk assessment:

The 7 missed genuine cases at the $15,000 threshold represent a potentially serious regulatory risk. In AML, failing to file a SAR when one is required (a "missed SAR") exposes the institution to enforcement action for BSA/AML non-compliance. Regulators in both the US and UK have taken action against institutions that systemically failed to identify and report suspicious activity. However, the regulatory risk must be weighed against the operational reality: an alert volume that analysts cannot physically review creates its own failure mode — reviews become rushed, quality deteriorates, and genuine cases may be missed in the backlog of a $10,000 threshold run.

The better answer is not to choose between the $10,000 and $15,000 thresholds as fixed options, but to pursue the segmentation approach in part (e) and to consider ML triage tools that can reduce the false positive rate at any given threshold, making the $10,000 threshold operationally viable.

Part e) Customer segmentation approach:

Apply the $15,000 threshold to customers rated Low Risk (minimal transaction monitoring burden for population with low expected AML risk). Apply the $10,000 threshold to customers rated Medium Risk. Apply the $5,000 threshold only to customers rated High Risk (PEPs, EDD customers, customers with prior STRs) where maximum detection sensitivity is warranted. This tiered approach concentrates analyst attention where the risk is highest, allows lower-risk segments to be monitored with a threshold that generates a manageable number of alerts, and ensures that high-risk customers receive maximum coverage.

Exercise 7.7: Program Design — Capacity Planning

Answer:

Part a) Expected weekly alert volume:

The bank processes 4,200 transactions/day × 7 days = 29,400 transactions/week. Alert rate: 0.8% of weekly transactions = 29,400 × 0.008 = 235 alerts per week.

Part b) Weekly analyst capacity in hours:

2 FTEs × 40 hours × 60% allocation = 48 hours per week available for transaction monitoring alert review.

Part c) Alerts reviewable per week:

At 25 minutes per alert: 48 hours × 60 minutes ÷ 25 minutes = 115.2 alerts per week.

Part d) Capacity gap:

Required: 235 alerts per week. Available: 115 alerts per week. Shortfall: 120 alerts per week — the team can only review approximately 49% of the expected alert volume. This is a material capacity deficiency. Options: (i) hire additional analyst(s); (ii) reduce scenario library scope; (iii) raise alert thresholds to reduce volume; (iv) implement ML triage (see Part e).

Part e) Impact of ML triage tool:

With ML triage reducing false positive rate from 92% to 75%:

Of 235 weekly alerts, the ML tool would auto-close 75% as low-risk (not 92%): - Alerts requiring human review = 235 × (1 − 0.75) = 58.75 ≈ 59 alerts per week.

At 25 minutes each, this requires 59 × 25 = 1,475 minutes = 24.6 hours per week. Available capacity is 48 hours. The ML triage tool brings the review burden well within capacity, with significant headroom (48 − 24.6 = 23.4 hours) available for other AML tasks or to handle backlog.

Note: the "true positive" rate does not change — the ML tool must be validated to confirm it is not discarding genuine suspicious activity in the auto-closed population. A regular review of a sample of auto-closed alerts (typically 5–10%) should be part of the quality assurance program.

Part f) First-90-day metrics:

Metrics to collect in the first 90 days: 1. Actual alert volume by week (to validate the 0.8% assumption). 2. Actual review time per alert (to validate the 25-minute estimate — this often increases once analysts encounter complex cases). 3. Actual false positive rate (to calibrate against the 92% assumption). 4. Analyst backlog (pending alerts) by week — an increasing backlog is an early warning sign. 5. SAR conversion rate (SARs filed / alerts reviewed) — baseline this before any tuning. 6. Case closure time (time from alert generation to disposition decision) — regulatory expectation is generally that alerts not be aged more than 30 days without disposition. 7. Scenario-level alert rates — which of the 8 scenarios are generating the most volume and what is each scenario's SAR conversion rate?

Chapter 10: Customer Risk Rating

Exercise 10.2: Rating Calculation

Answer:

Applying the specified rule: any individual factor High → overall High; two or more Medium (no High) → overall Medium; otherwise Low.

Customer Profile A — UK retail individual:

Factors assessed: - Entity type (individual, UK national): Low - PEP status (no PEP): Low - Adverse media (none): Low - Country risk (UK only): Low - Products (basic current account and savings): Low - Industry (salaried employee): Low

No High factors. No Medium factors. Overall rating: LOW.

Customer Profile B — UK accountancy firm, sole director is a domestic PEP:

Factors assessed: - Entity type (UK-registered limited company, regulated profession): Low - PEP status (sole director is a current local councillor — a domestic PEP): Medium (Note: UK domestic PEPs attract a Medium rather than automatic High under FATF's risk-based approach, though enhanced monitoring is required. Current office-holders are higher risk than former.) - Adverse media (none): Low - Country risk (primarily domestic transactions): Low - Industry (accountancy — a designated non-financial business and profession (DNFBP), professional services with access to client money): Medium - Products (standard business current account): Low

Two Medium factors (PEP, industry), no High. Overall rating: MEDIUM.

Customer Profile C — BVI holding company, Azerbaijani beneficial owner in Dubai:

Factors assessed: - Entity type (BVI holding company — high-opacity jurisdiction, shell company indicators): High - PEP status (no PEP indicators): Low - Adverse media (no results, but absence is noted): Low - Country risk (BVI incorporation, Azerbaijani BO, Dubai residence, international wire transfers): High (multiple high-risk jurisdiction indicators) - Industry ("real estate investment" — classic layering vehicle): High - Products (international wire transfers for property acquisition): High

Multiple High factors. Overall rating: HIGH. (EDD and possible senior management sign-off required.)

Customer Profile D — UK-registered charity, global donations including from Pakistan and Nigeria, distributions to Kenya and Tanzania:

Factors assessed: - Entity type (charity — designated as higher-risk sector under FATF Recommendation 8 and UK guidance): Medium to High - PEP status (no PEP indicators): Low - Adverse media (none): Low - Country risk (donors from Pakistan — FATF grey list at various times; distributions to Kenya and Tanzania — FATF mutual evaluation concerns): High (cross-border activity involving FATF-monitored jurisdictions) - Industry (charitable sector — significant AML/CFT risk per FATF guidance): High - Products (cash/wire receipt from global sources, outbound transfers to Africa): Medium

Multiple High factors (charity type, cross-border jurisdictions). Overall rating: HIGH. Charities operating with global fund flows from and to higher-risk jurisdictions are consistently rated as requiring enhanced scrutiny under UK MLR 2017 and FATF Recommendation 8 guidance.

Exercise 10.6: Review Cycle Capacity Planning

Answer:

Part a) Scheduled reviews per year:

• High Risk (5% of 15,000 = 750): semi-annual review = 750 × 2 = 1,500 reviews/year
• Medium Risk (20% of 15,000 = 3,000): annual review = 3,000 reviews/year
• Low Risk (75% of 15,000 = 11,250): triennial review = 11,250 / 3 = 3,750 reviews/year

Total: 1,500 + 3,000 + 3,750 = 8,250 scheduled reviews per year

Part b) Analyst hours by tier:

Tier 1 — fully automated (65% of Low Risk reviews): 65% × 3,750 = 2,437.5 automated reviews. Zero analyst hours. (5 minutes system time only.)

Tier 2 — system-assisted analyst review: - 30% of Low Risk reviews: 30% × 3,750 = 1,125 reviews - All Medium Risk reviews: 3,000 reviews - Total Tier 2 reviews: 4,125 reviews - Analyst time: 4,125 × 10 minutes = 41,250 minutes = 687.5 analyst-hours

Tier 3 — full analyst review: - All High Risk: 1,500 reviews - 5% quality sample from Low Risk: 5% × 3,750 = 187.5 ≈ 188 reviews - Tier 2 escalations (8% of 4,125 Tier 2 reviews): 8% × 4,125 = 330 reviews - Total Tier 3 reviews: 1,500 + 188 + 330 = 2,018 reviews - Analyst time: 2,018 × 40 minutes = 80,720 minutes = 1,345.3 analyst-hours

Total analyst-hours required: 687.5 + 1,345.3 = 2,032.8 analyst-hours per year

Part c) Available analyst capacity:

1.5 FTE × 1,760 hours/year = 2,640 available analyst-hours per year

Part d) Is capacity sufficient?

Required: 2,032.8 hours. Available: 2,640 hours. The automated tiering model is sufficient. The team has a surplus of approximately 607 hours (23% headroom), which provides capacity for ad hoc reviews, remediation work, and trigger-event reviews outside the scheduled cycle.

However, this assumes the Tier 2 escalation rate of 8% is accurate. If escalation rates are higher in practice (e.g., if the system-assisted review reveals more complex cases than anticipated), analyst hours will increase rapidly. The model should be reviewed after the first 6 months of operation and the 8% escalation assumption validated against actual data.

Part e) QA processes for Tier 1 automated reviews:

Tier 1 reviews require specific QA controls because no human eye touches them: 1. Automated QA sample: randomly select at least 5% of Tier 1 completions for analyst review each month. If the analyst review identifies issues at a rate above 2% of the sample, escalate the finding and consider suspending or narrowing the Tier 1 criteria. 2. Exception logic review: ensure the Tier 1 system has well-defined exception criteria that escalate to Tier 2 if any of the following are detected: new adverse media hit, PEP match, change in country of residence to high-risk jurisdiction, transaction volume increase above threshold. 3. Regulatory audit trail: automated reviews must produce a documented output — a record showing what was checked, what data was reviewed, and what conclusion was reached — even if no analyst was involved. Regulators will expect this documentation to be available on examination. 4. Annual methodology review: the criteria defining "eligible for Tier 1" should be reviewed annually against regulatory expectations, enforcement trends, and typology updates. 5. Regulatory filing check: ensure no Tier 1-completed customer has a pending SAR or open investigation — automation should not touch active casework.

Chapter 13: Regulatory Reporting

Exercise 13.3: Risk Weight Calculation

Answer:

Using Basel III standardized approach risk weights as specified: - Sovereign CQS1: 0%; Sovereign CQS2: 20%; Sovereign CQS3: 50% - Institution CQS1: 20%; Institution CQS2: 50% - Corporate CQS2: 50%; Corporate CQS3-4: 100% - Retail: 75%; Residential real estate: 35% - Unrated corporate: 100% - Undrawn commitments: apply CCF to exposure before risk weight

Part a) RWA calculations:

Note on #4: Under Basel III, eligible financial collateral (cash) reduces the exposure after application of haircuts. For simplicity and as specified in the exercise, the £5M cash collateral reduces the net credit exposure to £15M before applying the 50% corporate risk weight.

Part b) Total portfolio RWA:

£0 + £0 + £3M + £7.5M + £8M + £18.75M + £14M + £5M = £56.25M

Part c) Capital ratios:

CET1 ratio = £18M / £56.25M = 32.0% Tier 1 ratio = £18M / £56.25M = 32.0% (assuming no AT1; only CET1 given) Total Capital ratio = £22M / £56.25M = 39.1%

Part d) Basel III compliance:

This institution is very well capitalized relative to minimums. Note that the relatively high capital ratios reflect a conservative, low-risk portfolio (dominated by sovereign and mortgage exposures with low risk weights). Real-world analysis would also include the capital conservation buffer (+2.5%), any countercyclical buffer, and G-SIB/D-SIB buffers where applicable.

Chapter 19: Market Surveillance

Exercise 3: Cancel Ratio Analysis from Order Data

Answer:

Part A: Metric Computation

Working from the order data for Trader LN-7731:

Orders placed (status: "Placed"): ORD-001, ORD-003, ORD-005, ORD-007, ORD-009, ORD-011, ORD-012, ORD-014 = 8 placed orders

Orders cancelled (status: "Cancelled"): ORD-001, ORD-003, ORD-005, ORD-007, ORD-009, ORD-012, ORD-014 = 7 cancelled orders

1. Total orders placed: 8
2. Total orders cancelled: 7
3. Cancel ratio: 7/8 = 0.875 (87.5%)

Quantities — cancelled orders: ORD-001 (4,000,000), ORD-003 (3,500,000), ORD-005 (5,000,000), ORD-007 (2,000,000), ORD-009 (4,500,000), ORD-012 (4,000,000), ORD-014 (1,000,000) Sum: 24,000,000 / 7 = EUR 3,428,571 mean cancelled order quantity

Quantities — executed orders: ORD-002 (350,000), ORD-004 (300,000), ORD-006 (400,000), ORD-008 (200,000), ORD-010 (450,000), ORD-011 (3,000,000), ORD-013 (380,000), ORD-015 (250,000) Sum: 5,330,000 / 8 = EUR 666,250 mean executed order quantity

4. Mean quantity of cancelled orders: EUR 3,428,571
5. Mean quantity of executed orders: EUR 666,250
6. Size asymmetry ratio: 3,428,571 / 666,250 = 5.15

Buy cancellations followed within 20 seconds by a sell execution: - ORD-001 cancelled at 09:15:11 → ORD-002 sell executed at 09:15:18 (7 seconds): YES - ORD-003 cancelled at 09:38:29 → ORD-004 sell executed at 09:38:41 (12 seconds): YES - ORD-005 cancelled at 10:12:13 → ORD-006 sell executed at 10:12:25 (12 seconds): YES - ORD-007 cancelled at 11:04:44 → ORD-008 sell executed at 11:04:55 (11 seconds): YES - ORD-009 cancelled at 12:22:19 → ORD-010 sell executed at 12:22:30 (11 seconds): YES - ORD-011 was executed (not cancelled): N/A - ORD-012 cancelled at 14:30:31 → ORD-013 sell executed at 14:30:42 (11 seconds): YES - ORD-014 sell order cancelled at 15:01:25 → ORD-015 buy executed at 15:01:35 (10 seconds): Note — this is a sell placed/cancelled followed by a buy, the reverse direction.

7. Buy cancellations followed within 20 seconds by a sell execution: 6 out of 6 applicable buy cancellation instances = 100% (6/6)

8. Average price improvement per cycle:

Average price improvement: +0.02 per cycle (consistently 2 basis points above each cancelled buy order price). This consistency is itself notable — it suggests systematic behavior rather than coincidence.

Part B: Surveillance Threshold Assessment

• Cancel ratio (0.875 = 87.5%): exceeds the 0.85 threshold.
• Size asymmetry ratio (5.15): exceeds the 5.0 threshold.
• Directional asymmetry: 6/6 buy cancellations followed by sell executions within 20 seconds = 100%, well above the 60% trigger.

All three thresholds are triggered. The pattern requires automatic escalation to Head of Compliance.

Part C: The ORD-011 Execution

ORD-011 is a buy order for EUR 3,000,000 that was placed and fully executed at 13:45:17. At first examination, one genuine execution might appear to weaken the spoofing hypothesis — if the trader were purely spoofing, why would they execute a real buy? However, this does not materially undermine the hypothesis for three reasons:

First, sophisticated spoofing strategies may include occasional real executions to provide a legitimate business explanation and reduce the apparent manipulative intent. Second, ORD-011 occurs mid-session and represents only 1 of 8 placed orders (12.5%). The pattern across the other 7 orders remains highly consistent with the spoofing signature. Third, the question that surveillance must answer is not whether any legitimate activity occurred, but whether the dominant pattern of activity gives rise to reasonable grounds for suspicion — and the 6-cycle pattern of large cancelled buys followed by small sell executions at systematically higher prices satisfies that test.

Part D: Additional Data Requests

1. Position data: What is the trader's net position in XS2345678901 at the start and end of the session? If the trader was net short going into the session, the pattern of large buy orders (which would appear to tighten the spread and push prices up) followed by sell executions at higher prices has a clear economic logic consistent with spoofing.

2. Communications data: Voice calls, instant messages, and chat logs for Trader LN-7731 on 14 November 2024. Spoofing prosecution cases (including the landmark US DOJ cases) have routinely relied on trader communications confirming intent — messages such as "got the price up, now selling" or similar. Communications data is critical before a STOR recommendation.

3. Historical trading data for LN-7731: Review cancel ratios and size asymmetry across the prior 90 days. A single session with these metrics could be an anomaly; consistent patterns over multiple sessions materially strengthen the reasonable grounds for suspicion and may indicate a systematic strategy.

Chapter 21: Algorithmic Trading Controls

Exercise 21.2: Kill Switch Design

Answer:

Part a) Five key requirements under MiFID II / RTS 6:

1. Immediacy: The kill switch must be capable of cancelling all outstanding orders in all relevant instruments across all venues promptly and simultaneously. RTS 6 Article 9 requires "immediate cancellation" — industry expectation is this means within seconds, not minutes.

2. Coverage: The kill switch must cover all algorithms and all trading venues on which the firm trades. Partial coverage — algorithms or venues outside the switch's reach — does not satisfy the requirement.

3. Independent activation authority: The kill switch must be operable independently of the trading algorithms themselves. Activation authority must not require IT department involvement during market hours; compliance or risk management must be able to activate without technical assistance.

4. Regular testing: The kill switch must be tested regularly to confirm it works as intended. RTS 6 does not specify a minimum test frequency but supervisory guidance (FCA Market Watch) indicates annual testing is a minimum; many firms test quarterly.

5. Documented governance: There must be written procedures governing: who can activate the switch; what authority level is required; what situations trigger activation; what happens to pending orders on activation; and what is required before trading can resume. These procedures must be kept current and tested.

Part b) Deficiencies in the proposed design:

1. Two-person authorization requirement: Requiring two-person sign-off before activation is a critical deficiency. In a market emergency (e.g., runaway algorithm generating rapid losses or erroneous order flood), the time required to secure two authorizations may itself cause harm. The kill switch must be activatable by a single authorized person immediately. Two-person authorization may be appropriate for pre-planned shutdowns but not for emergency activation.

2. 30-second cancellation time: "Within 30 seconds" may be acceptable for some contexts but the RTS 6 expectation is immediate cancellation. In a fast-moving market, 30 seconds of open orders can generate significant losses or market impact. Best practice is measured in seconds (typically 1–5 seconds for single-venue kill; longer for multi-venue but still measured in seconds, not tens of seconds).

3. Two legacy algorithms outside coverage: This is a binary non-compliance issue. 100% coverage is required. "Cannot be reached by the system" is not an acceptable justification — those algorithms must either be included in the kill switch coverage or decommissioned. Running algorithms not subject to the kill switch is a material regulatory breach.

4. Annual testing: Annual testing is the bare minimum and is widely regarded as insufficient for a control this critical. Quarterly testing is strongly preferable; some firms test each major version change as well. Annual testing means 11+ months may pass between confirmations that the kill switch actually works.

Part c) Compliant kill switch design:

• Activation authority: Single authorized individual (Head of Compliance, Head of Risk, or designated deputy) can activate without requiring a second authorization. A log of activations is maintained.
• Coverage: All 12 algorithms across all 5 venues. Legacy algorithms must be included within 30 days or decommissioned.
• Cancellation speed: Target: all outstanding orders cancelled within 5 seconds of activation confirmation. Maximum acceptable: within 15 seconds for full multi-venue cancellation. This should be measured and recorded at each test.
• Testing frequency: Full kill switch test conducted quarterly during non-market hours with all 5 venues. At minimum, an annual test is conducted with all algorithms active simultaneously. Results documented and signed off by CRO and CCO.
• Reactivation protocol: Before trading resumes after a kill switch activation, written authorization is required from: the Head of Compliance (confirming the cause of activation has been investigated and addressed); the Head of Risk (confirming risk limits are appropriate for resumption); and senior management sign-off for any activation that was triggered by actual losses or control failure.

Chapter 26: Explainable AI and Model Governance

Exercise 3: Calculating Population Stability Index

Answer:

Part 3.1: PSI Calculation

PSI formula: PSI = Σ [(Current% − Training%) × ln(Current% / Training%)]

Training total: 100,000 applicants. Current total: 18,000 applicants.

Calculations for all ten bands (showing intermediate steps):

Total PSI = 0.0368 + 0.0329 + 0.0209 + 0.0147 + 0.0101 + 0.0039 + 0.0347 + 0.0591 + 0.0327 + 0.0257 = approximately 0.272

(Minor variation in the final digit is acceptable due to rounding at different stages.)

Part 3.2: Interpretation

PSI = 0.272 falls in the critical shift category (above 0.25). Under standard model monitoring thresholds: - Below 0.10: Model stable, no action required. - 0.10–0.25: Minor shift, investigate and monitor. - Above 0.25: Critical shift. Investigate root cause and consider retraining.

Required action: formal escalation to model owner and model risk management. The model should be placed on enhanced monitoring; a root cause investigation should be initiated immediately; and a retraining or recalibration project should be scoped.

Part 3.3: What has happened to the distribution?

Comparing the training distribution to the current distribution: - In training, the distribution is roughly bell-shaped and centered around the 0.3–0.5 score range (high-probability-of-default applicants). - In the current population, the distribution has shifted rightward — a higher proportion of applicants now score in the 0.5–1.0 range (higher scores = lower predicted default probability = better credit quality).

The population is scoring higher on average than the training population. Possible causes in a consumer credit context: 1. Economic improvement: if the training period (2020–2022) coincided with COVID-19 economic stress, the current applicant pool may simply have better credit profiles as the economy recovered. 2. Applicant selection shift: the bank's marketing or distribution channels may have changed, attracting a different (lower-risk) applicant profile. 3. Score inflation / gaming: if applicants have learned how to optimize the inputs that drive the score (e.g., paying down credit cards before applying), the score distribution shifts without the underlying risk changing. 4. Regulatory credit support ending: pandemic-era credit support programs that helped consumers maintain payment records may have ended, changing the benchmark against which the model was trained.

Part 3.4: Escalation memo (150-word sample):

"To: [Model Business Owner Name] From: Model Risk Management Re: PSI Alert — Consumer Credit Scorecard (Model ID: CC-SCR-001) Date: [Date]

This memo confirms the findings of the Q[X] Population Stability Index (PSI) review for the consumer credit scorecard. The PSI for the current production population versus the training baseline is 0.272, which exceeds the critical threshold of 0.25. This indicates a significant shift in the population the model is scoring relative to the data on which it was trained.

The shift is primarily driven by a movement of applications toward higher score bands (0.6–1.0), suggesting the current applicant population has materially better credit characteristics than the training population. This raises the risk that the model's discriminatory power and calibration may no longer be reliable.

Required action: please initiate a root cause investigation within 10 business days and schedule a model retraining review. This model is now on enhanced monitoring pending your response. Please contact the MRM team to scope the remediation."

Chapter 25: Machine Learning in Fraud Detection

Exercise 25.1: Precision-Recall Tradeoff Analysis

Answer:

Part a) Calculations for each threshold:

Definitions: - Precision = TP / (TP + FP) - Recall = TP / (TP + FN) - F1 = 2 × (Precision × Recall) / (Precision + Recall) - False Positive Rate = FP / (FP + TN)

Total fraud: 800. Total non-fraud: 99,200.

Part b) Best F1 score:

Threshold 0.55 achieves the best F1 score at 57.9%, representing the best balance between precision and recall at these three operating points. The 0.20 threshold prioritizes recall at the cost of extremely low precision (only 1 in 7 flagged transactions is genuine fraud). The 0.35 threshold represents a middle point. The 0.55 threshold gives the best combined performance.

Part c) Operational feasibility:

The fraud operations team can review 2,500 alerts/day.

• Threshold 0.20: 720 + 4,200 = 4,920 alerts — exceeds daily capacity. Not operationally feasible.
• Threshold 0.35: 640 + 1,800 = 2,440 alerts — within the 2,500-alert capacity (marginally).
• Threshold 0.55: 480 + 380 = 860 alerts — well within capacity.

At the highest-precision threshold (0.55), recall falls to 60% — meaning 40% of actual fraud (320 transactions) is not flagged. This represents material missed fraud.

Part d) Financial analysis:

Average fraud amount: £380. Fraud amounts uniform between £50–£2,000.

Total fraud value in the population: 800 × £380 = £304,000.

At each threshold, fraud value caught = TP count × £380; fraud value missed = FN count × £380.

The processor bears 40% of fraud above £500 (uniform distribution implies approximately 84% of fraud transactions are above £500 — those between £500 and £2,000 out of the £50–£2,000 range = 1,500/1,950 ≈ 76.9%; use 77% as an approximation).

For the purpose of this exercise, the processor's share of missed fraud (FN cost) ≈ FN losses × 40% × 77%:

• Threshold 0.20: Processor bears: £30,400 × 0.40 × 0.77 = £9,363
• Threshold 0.35: Processor bears: £60,800 × 0.40 × 0.77 = £18,727
• Threshold 0.55: Processor bears: £121,600 × 0.40 × 0.77 = £37,453

A processor choosing purely on its own financial interest would prefer threshold 0.20 (lowest processor-borne missed fraud). A processor choosing for merchant interests would also prefer threshold 0.20 (merchants bear 60% × 77% of missed fraud above £500, so lower missed fraud benefits merchants most). However, at 0.20, the alert volume (4,920/day) exceeds operational capacity, making this an operationally infeasible choice in practice.

Part e) Two-tier threshold evaluation:

The two-tier approach (automatic block above 0.55; manual queue 0.35–0.55; auto-approve below 0.35) is a sound operational design. It captures the highest-confidence fraud automatically while allowing human review for ambiguous cases. Operational requirements for the middle tier: sufficient analyst capacity to review the daily volume (2,440 − 860 = 1,580 in the middle tier); defined turnaround time standards (e.g., review within 2 hours); clear escalation path for complex cases; and a feedback loop where middle-tier dispositions are used to retrain the model.

Chapter 33: Cybersecurity Regulations

Exercise 33.1 Part B: Notification Deadline Mapping

Answer:

Key facts: Incident discovered 14:00 Friday. CISO classifies as DORA major incident at 17:00 Friday. Portfolio reporting service offline Friday 14:15 to Monday 09:00 = 43 hours of outage.

DORA initial notification (EU subsidiary — BaFin supervised):

DORA Article 19(4): financial entities shall submit an initial notification to the competent authority "without undue delay and in any case by the end of the business day" where the major incident is classified during business hours, or by the end of the next business day where classified outside business hours. Classification occurred at 17:00 Friday — this is close of business. Most interpretations require initial notification by close of business the next working day, i.e., Monday by 17:00 local time. The clock runs from the classification time (17:00 Friday), not the detection time, per the instruction.

UK GDPR / ICO notification:

UK GDPR Article 33: notification must be made within 72 hours of becoming aware of the breach. "Becoming aware" = when the organization first has confirmed knowledge, which in this scenario is the forensic assessment at 16:30 Friday. 72 hours from 16:30 Friday = 16:30 Monday (continuous calendar hours, weekends do not pause the clock). If it is not possible to provide all information within 72 hours, an initial notification must be filed with further information following.

EU GDPR / German DPA notification (for EU clients' data):

GDPR Article 33 applies identically to the EU subsidiary. Awareness = 16:30 Friday (same forensic assessment). 72-hour deadline = 16:30 Monday. The relevant supervisory authority for the German DPA is the Bundesbeauftragter für den Datenschutz und die Informationsfreiheit (BfDI) or the relevant Länder DPA depending on Hartwell GmbH's registered location in Germany.

FCA PRIN 11 notification:

PRIN 11.1R: a firm must notify the FCA "immediately" when it becomes aware of information that the FCA would reasonably expect to be notified of. There is no fixed deadline. In practice, "immediately" means as soon as the firm has sufficient information to file a meaningful notification — typically within hours of the incident being confirmed, not days. Given that the incident was confirmed at 16:30 Friday and involves a service affecting 8,400 UK retail clients, the FCA would expect notification at the earliest opportunity. Given the Friday afternoon timing, a reasonable interpretation is that notification should be filed no later than first thing Monday morning (09:00–10:00), with a clear explanation if any delay arose from the timing of the incident.

FCA PS21/3 operational resilience — impact tolerance breach:

Declared impact tolerance: 24 hours. Actual outage: 43 hours (Friday 14:15 to Monday 09:00). The impact tolerance is breached. The firm must document the breach in its self-assessment, including: how the tolerance was breached, why it was breached, what actions were taken during and after the incident, and what changes will be made to prevent recurrence. There is no notification deadline per se for a PS21/3 breach (it is self-assessed), but the breach must be disclosed to the FCA as a significant operational incident under PRIN 11.

Customer notification under GDPR Article 34:

Article 34 requires notification to affected individuals where the breach is likely to result in high risk to their rights and freedoms. Portfolio valuations and account reference numbers were exposed for approximately 5,200 clients. Whether this triggers Article 34 requires assessment of the risk: portfolio valuations could enable targeted social engineering or financial fraud; account reference numbers combined with other public data could enable account enumeration attacks. A conservative assessment would be that notification is required. Deadline: "without undue delay" — in practice, as soon as the firm has identified and can contact the affected clients, typically within a few days of the breach being confirmed.

Chapter 38: RegTech ROI

Exercise 38.1: Cost Baseline Documentation

Answer:

Part A: Weekly cost model

Alert volume analysis (weekly): - Total alerts per week: 185 - False positive alerts (triage-level closures): 185 × 88% = 162.8 ≈ 163 alerts closed at triage - Escalated for full investigation: 185 × 12% = 22.2 ≈ 22 full investigations per week - SAR decisions required: 22 reviews per week (all escalated cases reach the SAR decision stage) - SARs filed per week: 18 SARs/month ÷ 4.33 weeks/month = 4.16 SARs per week

Fully-loaded hourly rates: - AML Analyst: £58,000 / 1,600 hours = £36.25/hour - Senior AML Analyst: £72,000 / 1,600 hours = £45.00/hour - Compliance Manager: £88,000 / 1,600 hours = £55.00/hour

Stage 1 — Initial triage (AML Analyst): 185 alerts × 25 minutes = 4,625 minutes = 77.1 hours/week Cost: 77.1 × £36.25 = £2,794/week

Stage 2 — Full investigation (AML Analyst): 22 investigations × 3.5 hours = 77 hours/week Cost: 77 × £36.25 = £2,791/week

Stage 3 — SAR decision (Senior AML Analyst / Compliance Manager): 22 reviews × 45 minutes = 990 minutes = 16.5 hours/week Assume split evenly between Senior AML Analyst and Compliance Manager: 8.25 hours each. Cost: (8.25 × £45.00) + (8.25 × £55.00) = £371.25 + £453.75 = £825/week

Stage 4 — SAR drafting (Senior AML Analyst): 4.16 SARs × 2.5 hours = 10.4 hours/week Cost: 10.4 × £45.00 = £468/week

Stage 5 — Quality review and sign-off (Compliance Manager): 4.16 SARs × 30 minutes = 2.08 hours/week Cost: 2.08 × £55.00 = £114/week

Stage 6 — Record retention (AML Analyst): 4.16 SARs × 20 minutes = 1.39 hours/week Cost: 1.39 × £36.25 = £50/week

Total weekly cost: £2,794 + £2,791 + £825 + £468 + £114 + £50 = £7,042/week

Part B: Annual cost model

£7,042/week × 52 weeks = £366,184/year

Part C: Cost per SAR filed

Annual SAR volume: 18 SARs/month × 12 = 216 SARs/year Cost per SAR filed: £366,184 / 216 = £1,695 per SAR filed

Note: this is the fully-loaded cost of the entire process per SAR filed — including the false positive triage burden that does not result in a SAR. This metric (cost per SAR) is the key denominator for RegTech ROI analysis: a case management platform that reduces the false positive rate or triage time will reduce cost per SAR.

Part D: The cost driver

Stage 1 (triage of false positives) accounts for £2,794/week = 39.7% of total weekly cost — the single largest cost driver. Stage 2 (full investigation) accounts for £2,791/week = 39.6%.

Together, the triage and investigation stages consume 79% of total process cost. This is typical for AML programs and confirms that technology creating value in alert triage — reducing false positive rates or automating low-risk alert closures — delivers the highest return on investment. This is where a case management platform with ML triage capabilities would be most impactful.

Part E: Costs not captured in this model

At minimum, the following cost categories are excluded:

1. Technology and infrastructure costs: The transaction monitoring system itself (licensing, hosting, maintenance) has not been included. These costs can be £30,000–£150,000/year for a building society of this size and are a material component of total AML program cost.

2. Management oversight and governance: The Compliance Manager's AML time allocation has been included only in the SAR decision and quality review stages. Their broader program governance activities — policy review, training, regulatory liaison, MI and board reporting — are not captured. If approximately 35% of the Compliance Manager's time goes to AML, this represents approximately £30,800/year in additional management cost.

3. Regulatory examination and enforcement response: The cost of hosting regulator visits, responding to supervisory queries, and conducting thematic reviews is not included. These can be significant when they occur — a focused FCA review of an AML program might require 100–200 hours of senior staff time.

4. Training and development: Annual AML training for the team, ACAMS certifications, industry conference attendance, and external legal counsel for novel issues are excluded.

5. Error and remediation costs: The cost of correcting cases that were incorrectly closed as false positives and later identified as genuine suspicious activity — re-investigation, late SAR filing, regulatory notification — is not captured in the routine cost model.

Chapter 38: RegTech ROI (continued)

Exercise 38.2: Business Case Construction

Answer:

Part A: Three-year cost model (Years 0–3)

Year 1 license escalation at 3%: £210,000 × 1.03 = £216,300 (Year 2); × 1.03² = £222,789 (Year 3). Year 1 vendor support at 4%: £62,000 × 1.04 = £64,480 (Year 2); × 1.04² = £67,059 (Year 3).

Total three-year cost (Years 0–3): £548,000 + £281,000 + £289,780 + £298,848 = £1,417,628

Part B: Benefit model

FTE savings: Current: 4.2 FTE × £68,000 = £285,600/year. Post-implementation: 1.8 FTE × £68,000 = £122,400/year. Annual saving: £163,200/year (applicable from Year 1 — assume full FTE savings from Year 1).

External consultant elimination: £85,000/year eliminated from Year 1. Annual saving: £85,000/year.

Resubmission and error reduction: Current: 240 filings × 8% resubmission × £1,200 = £23,040/year. Post-implementation: 240 filings × 2% × £1,200 = £5,760/year. Annual saving: £17,280/year.

FCA data quality query elimination: Historical rate: 2 queries per 18 months ≈ 1.33/year at £18,000 each = £24,000/year expected. Post-implementation: 0. Annual saving: £24,000/year.

Enforcement risk reduction (expected value): Current: 4% probability × £1.5M = £60,000 expected annual loss. Post-implementation: 2% × £1.5M = £30,000 expected annual loss. Annual risk reduction EV: £30,000/year.

Total three-year benefits: £958,440

"High confidence" benefits (FTE savings + consultant + errors) = £265,480/year × 3 = £796,440 = 83% of total benefits. "Medium confidence" benefits = £54,000/year × 3 = £162,000 = 17% of total benefits.

Part C: NPV and payback period

Net cash flows: - Year 0: −£548,000 - Year 1: −£281,000 + £319,480 = +£38,480 - Year 2: −£289,780 + £319,480 = +£29,700 - Year 3: −£298,848 + £319,480 = +£20,632

NPV at 8%: NPV = −548,000 + 38,480/1.08 + 29,700/1.08² + 20,632/1.08³ NPV = −548,000 + 35,630 + 25,436 + 16,381 NPV ≈ −£470,553 over the three years shown.

Important note: This investment has a significant Year 0 implementation cost. A three-year NPV is negative because the majority of cost is front-loaded while benefits accrue evenly. A five-year analysis, or consideration of the perpetuity of benefits, is necessary to evaluate this investment fairly. In Year 4 and beyond, annual net benefit is approximately +£20,000–30,000 with no additional implementation cost, turning NPV positive around Year 4–5.

Payback period: Cumulative cash flows: Year 0: −£548,000. After Year 1: −£509,520. After Year 2: −£479,820. After Year 3: −£459,188. The investment does not pay back within the three-year window. Extending to Year 5 (assuming similar annual benefit/cost structure): payback occurs in approximately Year 6–7.

Part D: Sensitivity analysis

At 75% and 50% of benefits, the investment remains deeply negative-NPV over three years. However, this reflects the front-loaded cost structure — not a poor investment. This analysis reinforces the importance of a five-year view.

Part E: Recommendation memo (200 words):

"To: CCO, Cornerstone Financial Group Re: Regulatory Reporting Platform — Business Case Summary

The three-year NPV of the proposed regulatory reporting automation platform is negative at −£471K, which reflects the front-loaded implementation cost of £548,000 in Year 0. This should not be interpreted as a poor investment.

High-confidence annual benefits total £265,480/year — comprising FTE savings (£163,200), external consultant elimination (£85,000), and resubmission cost reduction (£17,280) — generating a payback period of approximately six years. Additional medium-confidence benefits (enforcement risk reduction and query elimination) add £54,000/year, shortening payback.

I recommend proceeding with this investment on the following basis: the high-confidence benefits are substantially predictable and achievable; the qualitative benefits of improved regulatory relationships and reduced resubmission risk are underweighted in the model; and the current state — 4.2 FTE of analyst time on manual reporting — represents a fragile and unsustainable process at scale.

Conditions: the implementation timeline must be held to 12 months or Year 1 benefits will not materialize as modeled. FTE reduction should be achieved through redeployment to higher-value activities, not redundancy, to preserve institutional knowledge during transition."

These worked answers are intended as learning tools, not as definitive scripts. In examination settings, alternative approaches that correctly apply the relevant frameworks, reach defensible conclusions, and demonstrate understanding of the regulatory and analytical context will receive full credit. Where questions involve regulatory interpretation, reasonable practitioners may reach different conclusions; the quality of the analysis and the rigor of the supporting argument are the primary assessment criteria.