Capstone Project 01: Design a KYC/AML RegTech Program for a Fintech Startup

Practitioner Role: Priya Nair, RegTech Senior Manager (newly promoted Partner), engaged as lead RegTech consultant to FlowPay Ltd

Client: FlowPay Ltd — UK-licensed payment institution (FCA PI licence, granted Q1 of the current year)

Product: Consumer peer-to-peer payments platform targeting the 18–35 demographic

Year 1 Targets: 50,000 customer onboardings; £120M payment volume; 90% automated onboarding

Budget: £250,000 Year 1 RegTech spend (software, implementation, integration only — compliance headcount budgeted separately)

Scenario Context

Priya Nair has spent the last three years in Big 4 RegTech advisory, and her promotion to Partner came on the back of two successful challenger bank compliance builds. When FlowPay's CEO, Chloe Adeyemi, called to discuss the engagement, Priya recognised the pattern immediately: technically capable founders, a genuinely innovative product, and almost no instinct for the compliance machinery that the FCA licence now demands.

FlowPay has 40 employees. Its CTO has built a clean, fast payment rails infrastructure. Its head of compliance — hired six weeks ago — is competent but has never built a programme from scratch. The regulatory clock started the moment the PI licence was issued. Priya has eight weeks to design the programme architecture, select vendors, and hand off a twelve-month implementation roadmap. She opens her working papers and begins with the only sensible starting point: what does the law actually require?

Part A: Regulatory Requirements Analysis

A.1 Customer Due Diligence (CDD)

FlowPay's obligations derive from the Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017 (MLR 2017), as amended, and are supplemented by the Joint Money Laundering Steering Group (JMLSG) Guidance, which the FCA treats as an industry standard.

Standard CDD (Regulation 28) is required before establishing a business relationship or carrying out an occasional transaction. For a consumer P2P payments product, every customer onboarding triggers CDD. The minimum requirements are:

• Identify the customer using a name, date of birth, and residential address
• Verify that identity using documents, data, or information from a reliable, independent source
• Assess the purpose and intended nature of the business relationship

For FlowPay's 18–35 target demographic, verification will primarily be electronic — document scanning combined with database checks against credit reference agency data, electoral roll, or other reliable sources. The JMLSG Guidance (Part I, Chapter 5) confirms that digital identity verification is acceptable provided it meets the "reliable, independent source" standard.

Simplified Due Diligence (SDD) (Regulation 37) is available where the risk associated with the customer or product is assessed as low. FlowPay may apply SDD to customers who meet all of: UK-domiciled, using the platform for everyday consumer payments, no PEP or sanctions flags, and falling within standard transaction limits. SDD does not mean no verification — it means a lighter verification touch and reduced ongoing monitoring intensity.

Important constraint: SDD is a risk-based decision, not a default. FlowPay's risk assessment must document the basis for applying SDD to each customer segment. The FCA has taken enforcement action against firms that treated SDD as a blanket exemption.

A.2 Enhanced Due Diligence (EDD)

EDD is mandatory under Regulation 33 where a higher risk is identified. FlowPay's EDD triggers will include:

EDD content must be documented and retained. The MLRO (or delegated compliance officer) should approve all EDD decisions where the outcome is to continue the relationship despite elevated risk.

A.3 Sanctions Screening

FlowPay must screen against the UK's consolidated sanctions list (maintained by OFSI — the Office of Financial Sanctions Implementation), which incorporates all UK autonomous sanctions regimes and UN Security Council measures implemented into UK law post-Brexit.

Required screening points: - At customer onboarding (before activating the account) - At any change in customer data (name change, address change) - When transacting with a new counterparty (recipient screening) - Ongoing: daily re-screening of the full customer base against list updates, since OFSI updates designations with immediate effect

Matching logic: Fuzzy matching is essential — sanctions lists contain transliterated names and aliases. A pure exact-match approach will produce both false negatives (missed hits on transliterated variations) and false positives (common names generating spurious matches). The JMLSG Guidance recommends a risk-based approach to matching thresholds, documented in the firm's AML policy.

Critical operational point: A sanctions match is not an alert to investigate — it is a potential legal freeze obligation. FlowPay must have an operational procedure that suspends the relevant transaction or account immediately upon a confirmed match, notifies the MLRO, and seeks OFSI guidance where appropriate. The tipping-off prohibition (POCA 2002, s.333A) applies: FlowPay must not inform the customer that a screening match has occurred.

A.4 Transaction Monitoring

MLR 2017 Regulation 28(11) requires ongoing monitoring of business relationships, including scrutiny of transactions to ensure they are consistent with the firm's knowledge of the customer, the business and risk profile, and the source of funds where necessary.

The JMLSG Guidance adds operational texture: monitoring should be proportionate to the firm's risk assessment, cover the entire customer base, and be capable of detecting patterns as well as individual transactions. For a P2P payments firm, key monitoring scenarios include:

• High-volume, low-value transactions (structuring/smurfing indicators)
• Rapid fund cycling (in and out within a short window)
• Payments to or from high-risk jurisdictions
• Transactions inconsistent with stated purpose (e.g., a student account receiving £15,000 in one month)
• Dormant account reactivation with immediate high-value outbound payment
• Multiple accounts sending to a single beneficiary (aggregation indicator)

At FlowPay's Year 1 scale (50,000 customers; £120M volume), a rules-based transaction monitoring system is appropriate. ML-augmented monitoring should be considered for Year 2 once there is sufficient transaction history to train models and tune thresholds.

A.5 Suspicious Activity Reporting

FlowPay's MLRO has a legal obligation under the Proceeds of Crime Act 2002 (POCA 2002) and the Terrorism Act 2000 (TA 2000) to submit a Suspicious Activity Report (SAR) to the National Crime Agency (NCA) whenever they know, suspect, or have reasonable grounds to suspect that a person is engaged in or benefiting from money laundering or terrorist financing.

Operational process: 1. A transaction monitoring alert or staff referral triggers an internal investigation 2. The compliance analyst reviews the alert, gathers context, makes a preliminary assessment 3. If suspicion is reasonable, the analyst escalates to the MLRO via internal referral (documented) 4. The MLRO makes the SAR decision — to file or to close with documented rationale 5. If filing: the SAR is submitted via the NCA's SAR Online portal within the required timeframe 6. If the transaction is still pending: the MLRO may need to request a Defence Against Money Laundering (DAML) before proceeding 7. All decisions (file or no-file) must be documented and retained

Tipping off: At no stage may FlowPay inform the customer, counterparty, or any person not involved in the SAR process that a report has been or may be made.

A.6 Record-Keeping

MLR 2017 Regulation 40 requires that FlowPay retain: - CDD records (identity documents, verification records): five years from the end of the business relationship - Transaction records: five years from the date of the transaction - SAR-related records: five years from the date of submission (noting that law enforcement may have operational reasons to request extension)

Records must be retrievable in a timely manner to respond to regulator, law enforcement, and court requests. They must be stored in a manner that ensures integrity — they cannot be altered after the fact. For a digital-native firm like FlowPay, this means audit-logged, immutable record storage — not simply saving files to a shared drive.

Part B: Program Architecture Design

B.1 Technology Stack

The following architecture describes FlowPay's Year 1 KYC/AML technology stack, presented in the sequence in which a customer encounters each component:

CUSTOMER ONBOARDING JOURNEY
============================================================

  [Customer App]
       |
       v
  [1. IDENTITY VERIFICATION ENGINE]
  - Document capture (passport/driving licence)
  - Liveness / biometric check
  - Document authenticity check (NFC chip read where available)
  Vendor: third-party IDV SaaS (e.g., Onfido, Jumio, Veriff)
       |
       v
  [2. ELECTRONIC IDENTITY VERIFICATION (eIDV)]
  - Name + DOB + address check vs. credit bureau, electoral roll
  - Confirms document matches live data records
  Vendor: same IDV vendor OR credit reference bureau API
       |
       v
  [3. SANCTIONS & PEP SCREENING]
  - Real-time check on customer name, DOB, address at point of onboarding
  - Includes OFSI list, HMT, UN lists, PEP databases, adverse media
  Vendor: dedicated watchlist screening SaaS
       |
       v
  [4. RISK SCORING ENGINE]
  - Inputs: identity verification result, screening result, customer
    attributes (geography, product use, income band)
  - Outputs: risk tier (LOW / MEDIUM / HIGH)
  - Decision: CDD / SDD / EDD pathway
  Built: in-house rules engine (lightweight, rules configured in YAML)
       |
  _____|_______________________________
  |              |                    |
  v              v                    v
[SDD Path]  [Standard CDD]        [EDD Path]
  Auto-         Standard            Manual review
  approve       auto-review;        by analyst;
                approve or          MLRO approval
                escalate            required
  |              |                    |
  |______________|____________________|
                 |
                 v
  [5. CORE BANKING / PAYMENT RAILS]
  - Account activated; payment capability enabled
  - Customer data written to the master customer record
                 |
                 v
  [6. TRANSACTION MONITORING ENGINE]
  - Rules-based monitoring on all transactions in real time
  - Configurable rule library (velocity, amount, geography, pattern)
  - Alert generation and prioritisation
  Vendor: transaction monitoring SaaS
                 |
                 v
  [7. CASE MANAGEMENT / SAR WORKFLOW]
  - Alert queue management
  - Analyst investigation workspace
  - Internal referral workflow (analyst → MLRO)
  - SAR drafting and submission log
  - Audit trail
  Vendor: case management module (standalone or bundled with TM vendor)
                 |
                 v
  [8. RECORD STORE]
  - Immutable audit log of all CDD, screening, and monitoring records
  - Retention enforcement (5-year minimum)
  - Retrieval API for regulatory/law enforcement requests
  Built: cloud object storage (AWS S3 / Azure Blob) with lifecycle policy
         + audit log (CloudTrail or equivalent)

============================================================

B.2 Customer Risk Segmentation Model

Estimated Year 1 volume by tier (based on typical UK fintech demographics): - Tier 1 (SDD): ~55% of onboardings (~27,500 customers) - Tier 2 (Standard): ~38% of onboardings (~19,000 customers) - Tier 3 (EDD): ~5% of onboardings (~2,500 customers) - Tier 4 (Declined): ~2% of applications (~1,000 applicants)

This segmentation supports the CEO's 90% automation target: Tier 1 (SDD) is fully automated; Tier 2 largely automated with automated review queue for edge cases; Tier 3 requires human analyst involvement.

B.3 Data Flows

ONBOARDING DATA FLOW

Customer App
  → Document image + selfie → IDV Vendor API
  → IDV result (pass/fail + confidence score) → Risk Scoring Engine
  → Customer attributes (DOB, address, stated income) → eIDV + Screening APIs
  → Screening result (clear/match/possible match) → Risk Scoring Engine
  → Risk tier determination → CDD decision (auto / escalate / EDD)
  → All results + raw data → Record Store (immutable write)
  → Customer record → Core Banking system (account creation)

ONGOING MONITORING DATA FLOW

Core Banking / Payment Rails
  → Transaction events (real-time) → Transaction Monitoring Engine
  → Rules evaluation → Alert (if triggered) → Alert Queue
  → Analyst review → Case record → Investigation → MLRO referral (if warranted)
  → SAR decision (file / no-file) → SAR submission log → Record Store
  → Case closure → All documentation → Record Store

PERIODIC REVIEW DATA FLOW (monthly batch)

Customer database
  → Full population → Sanctions re-screening (nightly batch)
  → Hits → Priority alert queue → Analyst review
  → Periodic risk review (annual for Tier 1/2; more frequent for Tier 3)
  → Updated risk tier → CDD refresh if required → Record Store

B.4 Integration Requirements

B.5 Human-in-the-Loop Design

The following decisions require human review: - Any onboarding application that the risk engine places in Tier 3 (EDD) - Any onboarding application where the IDV confidence score falls below the configured threshold - Any transaction monitoring alert that the system assigns a priority score above the defined escalation threshold - All SAR decisions (the MLRO makes the final filing determination; this cannot be automated) - Any sanctions match that is assessed as a potential true positive - All relationship exit decisions

Analyst workflow: 1. Alert appears in the analyst's queue with: customer profile, triggering data, rule(s) fired, risk tier, prior case history 2. Analyst reviews within SLA (standard: 2 business days; high priority: 4 hours; sanctions: 1 hour) 3. Analyst documents investigation: what was reviewed, what was found, what conclusion was reached 4. If closing without escalation: closure rationale documented and retained 5. If escalating to MLRO: internal referral completed with analyst recommendation 6. MLRO reviews and makes SAR decision; decision and rationale documented 7. Case closed; full record written to record store

Part C: Vendor Selection and Budget Allocation

C.1 Required Vendor Categories

Rationale for build decisions: The risk scoring engine and record store are not RegTech products — they are configuration and infrastructure problems. Building them in-house gives FlowPay direct control over the risk appetite settings embedded in the scoring logic, which the FCA will expect the firm to own and be able to explain. Outsourcing the scoring logic to a vendor creates a governance problem: "the vendor told us to classify them as low risk" is not an acceptable regulatory explanation.

C.2 Budget Allocation

Note on IDV pricing: The £80,000 allocation assumes a blended per-check rate of approximately £1.60, covering document scanning, liveness detection, and basic eIDV. Some IDV vendors price the document check and database cross-check separately; the £80,000 is allocated across both. Volume discounts should be negotiated from the outset — FlowPay's 50,000 Year 1 target is a meaningful volume for challenger bank IDV vendors and creates negotiating leverage.

C.3 Vendor Selection Criteria

Identity Verification vendor: - FCA-aware implementation team with UK challenger bank references - API-first, documented SDK for mobile integration - Liveness detection certified to ISO 30107-3 Level 1 (minimum) or Level 2 - Configurable confidence score thresholds - Transparent pricing model; clear volume discount schedule - Data residency: UK or EEA (GDPR implications) - SOC 2 Type II or ISO 27001 certification

Watchlist Screening vendor: - Coverage: OFSI consolidated list; HMT; UN; FATF; all UK autonomous regimes - PEP database coverage including RCA (relatives and close associates) - Adverse media monitoring (structured) - Fuzzy matching algorithm with configurable threshold - Real-time API for onboarding; batch capability for nightly re-screening - Audit log of every match decision - SLA for list updates following OFSI designation changes (same-day minimum)

Transaction Monitoring vendor: - Pre-built rule library for UK P2P payments (velocity, geography, structuring scenarios) - Configurable thresholds with audit log - Alert scoring and prioritisation - Integrated case management with SAR workflow - Export capability for regulatory data requests - References from UK payment institutions specifically

C.4 Budget Trade-offs and Constraints

The £250,000 budget is tight for a Year 1 build. The key trade-offs are:

What FlowPay can do well within this budget: - Identity verification at scale: the per-check cost is competitive at 50,000 volume - Sanctions screening: watchlist SaaS is a solved problem at this price point - Basic transaction monitoring: a mid-market TM platform covers the mandatory scenarios

What FlowPay will need to do manually or defer: - ML-augmented transaction monitoring: no budget for it in Year 1; rules-based is appropriate at this volume and provides a baseline dataset for Year 2 ML model training - Advanced adverse media monitoring (structured AI-driven): the budget allocation covers basic adverse media; sophisticated adverse media NLP is a Year 2 enhancement - Direct SAR API integration with NCA: manual portal submission in Year 1 is adequate at expected SAR volumes; API integration is a Year 2 efficiency gain - Automated periodic review workflow: Year 1 periodic reviews will be managed manually on a spreadsheet-tracked schedule; automated workflow is Year 2

The most important constraint: The 90% automation target is achievable for Tier 1 and Tier 2 onboarding. However, the EDD workflow will require analyst time that is not covered by this budget (it is covered by the headcount budget). The compliance lead must ensure sufficient analyst capacity from day one — the architecture is only as good as the people who work the queues.

Part D: Implementation Roadmap

D.1 Minimum Viable Compliance (Months 0–1)

Before FlowPay can onboard a single customer, the following must be operational:

D.2 Phase 2 (Months 2–6)

D.3 Year 2 Enhancements (Defer from Year 1)

• ML-augmented transaction monitoring (requires 6+ months of transaction data for model training)
• Automated periodic review workflow with risk-based scheduling
• NCA SAR API integration (replaces portal submission)
• Advanced adverse media with AI-driven entity resolution
• Dynamic customer risk score (real-time score updates based on transaction behaviour)
• Passporting / EEA operations support (not in scope for Year 1)

D.4 Key Milestones and Dependencies

Part E: Key Risk Assessment

Risk 1: IDV Bypass or Manipulation

Description: A bad actor uses a high-quality document forgery, a photograph of a third party's ID, or an injection attack against the mobile IDV SDK to pass identity verification and open a fraudulent account for money laundering purposes.

Likelihood: Medium. Injection attacks against mobile biometric systems are a documented and growing threat vector. Sophisticated criminal groups specifically target fintech onboarding.

Impact: High. A successfully bypassed onboarding creates an anonymous payment account usable for layering. Regulatory consequences include enforcement action if the FCA concludes that onboarding controls were inadequate.

Mitigation: Require NFC chip reading for passports and biometric residence permits where available (makes injection attacks significantly harder). Configure liveness detection at Level 2 (active challenge) for applications above a transaction threshold. Implement device fingerprinting as a secondary signal. Review IDV vendor's security disclosure programme before contracting. Conduct a penetration test of the onboarding flow in Month 3.

Risk 2: Sanctions Match False Negative (Missed Hit)

Description: A sanctioned individual passes FlowPay's screening because the screening vendor's fuzzy matching algorithm does not match a transliterated name variant against the OFSI list.

Likelihood: Low-Medium. OFSI lists are relatively small, but they include individuals from jurisdictions with significant name transliteration complexity (Russian, Arabic, Iranian names).

Impact: Critical. Processing a payment for a designated person is a criminal offence under the Sanctions and Anti-Money Laundering Act 2018. OFSI can impose unlimited financial penalties. The reputational consequences for a young fintech would likely be existential.

Mitigation: Require vendors to demonstrate matching against a test dataset that includes known transliteration variants of sanctioned individuals' names. Set the matching threshold conservatively (accepting higher false positives as the cost of lower false negatives). Conduct a manual quality review of screening results in Month 1 before relying fully on the system. Review the matching algorithm with the vendor during procurement.

Risk 3: Transaction Monitoring Threshold Misconfiguration

Description: FlowPay's transaction monitoring rules are configured with thresholds that are either too high (missing genuine suspicious activity) or too low (generating an unworkable volume of false positives that overwhelm the analyst team).

Likelihood: High. Threshold calibration is a known challenge for new entrants with no historical data. The vendor's default thresholds are set for a generic customer base, not FlowPay's 18–35 P2P demographic.

Impact: Medium-High. Thresholds set too high create regulatory exposure (failures to detect and report suspicious activity). Thresholds set too low create operational failure — analysts drown in false positives, genuine alerts are missed, and the MLRO cannot make timely SAR decisions.

Mitigation: In Months 1–2, run transaction monitoring in shadow mode — generating alerts but reviewing them for calibration rather than treating them as live compliance obligations. Use the first 90 days of transaction data to tune thresholds before relying on the system for SAR decision-making. Document the calibration process and threshold rationale; the FCA will ask about it.

Risk 4: Data Protection Conflict with Record-Keeping

Description: A customer exercises their GDPR right to erasure. FlowPay's legal team, uncertain about the interaction between GDPR and MLR 2017 record-keeping obligations, deletes CDD records before the five-year retention period expires.

Likelihood: Low-Medium. Most UK fintechs encounter this issue within the first two years as customers churn and submit erasure requests.

Impact: Medium. Deleting records before the MLR 2017 retention period expires creates a regulatory breach. Worse, if an NCA investigation subsequently requires those records, their absence would be a serious matter.

Mitigation: Document the legal position in the data retention policy: MLR 2017 Regulation 40 creates a legal obligation that overrides the GDPR right to erasure for the retention period, and the ICO's guidance confirms this. Train the customer service team on the correct response to erasure requests from former customers whose records are within the retention window. Configure the record store's lifecycle policy to enforce the five-year minimum.

Risk 5: Vendor Dependency and Single Point of Failure

Description: FlowPay's IDV vendor — a key dependency in the onboarding flow — experiences a service outage during a peak onboarding period (e.g., following a marketing campaign). FlowPay cannot onboard customers without IDV.

Likelihood: Medium. SaaS vendor outages are not unusual; a multi-hour outage in the first year of operation is a plausible scenario.

Impact: Medium. Business impact (lost sign-ups) is manageable. Compliance impact is limited provided FlowPay does not attempt workarounds that bypass identity verification. The risk becomes High if FlowPay activates accounts without completed IDV.

Mitigation: Include uptime SLA (99.9% minimum) and financial remedies for breach in the vendor contract. Design the onboarding flow with a graceful degradation mode: if IDV is unavailable, the application is held in a pending state (not rejected, not approved) and the customer is notified. Evaluate whether a second IDV vendor should be contracted for failover in Year 2.

Part F: Deliverables and Assessment Rubric

Deliverables

Students and practitioners completing this capstone should produce the following:

1. AML Risk Assessment: A written risk assessment of FlowPay's inherent AML risk, covering customer risk, product risk, geographic risk, and delivery channel risk. This document forms the foundation for all subsequent programme design decisions. Minimum 1,500 words.

2. KYC/AML Programme Architecture Document: A written and diagrammatic description of the full technology stack, data flows, and integration requirements. Must include the customer journey from onboarding through ongoing monitoring. Should be written for a technical compliance audience — the FCA Skilled Person reviewer is the imagined reader.

3. Vendor Evaluation Summary: A written analysis of at least three vendors considered in each of the two primary categories (IDV and transaction monitoring). Must include evaluation criteria, scoring, and a recommendation with documented rationale.

4. Year 1 Budget Allocation with Justification: A line-item budget table with narrative justification for each allocation. Must address the trade-offs explicitly: what is being prioritised and what is being deferred, and why.

5. 12-Month Implementation Roadmap: A milestone-level roadmap covering MVP compliance, Phase 2 enhancements, and Year 2 deferrals. Must identify dependencies and owners for each milestone.

6. Key Risk Register: A risk register covering the top five compliance risks, with likelihood and impact assessment and documented mitigations. Written for presentation to FlowPay's Board.

Assessment Rubric

This capstone integrates material from Part 2 (KYC/AML), Part 1 (Technology Foundations and Data Architecture), and Part 5 (Vendor Selection and Procurement). Students should revisit Chapters 6 through 11 and Chapter 28 before beginning. Priya Nair's engagement with FlowPay continues in Capstone Project 03, where Maya Osei faces the next generation of the same problem at much larger scale.