Appendix D: Templates and Checklists

Practical Tools for RegTech Compliance Professionals

Ready-to-use templates and checklists for common RegTech compliance activities. Each tool can be adapted to specific institutional contexts. These are starting points — not substitutes for institutional judgment or legal advice.

Template 1: RegTech Vendor Due Diligence Checklist

Purpose: Structured assessment for any RegTech vendor under consideration for a material compliance function

Use: During RFP process and before final vendor selection decision

Section A: Technical Due Diligence

Item	Response	Evidence Required
System architecture documented?	☐ Yes ☐ No ☐ Partial	Architecture diagram
API documentation available?	☐ Yes ☐ No	API specification
Data residency: where is data processed?		Written confirmation
Data residency: where is data stored?		Written confirmation
SOC 2 Type II certified? (or equivalent)	☐ Yes ☐ No	Certificate (< 12 months old)
ISO 27001 certified?	☐ Yes ☐ No	Certificate
Last penetration test date?		Test executive summary
Critical vulnerabilities unresolved?	☐ Yes ☐ No	Vulnerability report
Sub-processors used?	☐ Yes ☐ No	Sub-processor list
GDPR/UK GDPR compliant?	☐ Yes ☐ No	DPA template; privacy policy
DORA Article 30 provisions included in contract?	☐ Yes ☐ No ☐ N/A (non-EU)	Contract review
Data export capability (formats, timeline)?		Written specification
Business continuity plan (BCP) documented?	☐ Yes ☐ No	BCP executive summary
Disaster recovery plan (DRP) documented?	☐ Yes ☐ No	DRP executive summary
BCP/DRP last tested?		Test report date

Section B: Regulatory Due Diligence

Item	Response	Notes
Vendor subject to any regulatory enforcement actions (past 3 years)?	☐ Yes ☐ No	Describe if Yes
Vendor's clients subject to regulatory findings related to this product?	☐ Yes ☐ No	Describe if Yes
Does the system output meet current regulatory format requirements?	☐ Yes ☐ No	Specify requirements checked
Has the product been reviewed by any regulator?	☐ Yes ☐ No	Describe if Yes
How does the vendor manage regulatory changes (e.g., new SAR format, XBRL updates)?		Written process
Who bears the cost of regulatory change updates?	☐ Vendor ☐ Client ☐ Shared	Contract clause reference
Does the product support audit trail requirements for your jurisdiction?	☐ Yes ☐ No	Specify requirements

Section C: Financial Due Diligence

Item	Response	Notes
Years in operation?
Number of clients?
Revenue (approximate, if available)?
Funding history (investment rounds, investors)?
Revenue concentration: largest client as % of revenue?
Profitable?	☐ Yes ☐ No ☐ Unknown
Any recent acquisition attempts or M&A activity?	☐ Yes ☐ No
Vendor concentration risk assessment? (Do other regulated clients use this vendor?)

Section D: Reference Assessment

Item	Response	Notes
Three references provided at similar-scale institutions?	☐ Yes ☐ No
Reference 1 contacted? Outcome?
Reference 2 contacted? Outcome?
Reference 3 contacted? Outcome?
Key questions for references:
— What didn't work as advertised?
— How does the vendor respond to problems?
— Would you select this vendor again?
— What do you wish you had known before signing?

Assessment Outcome: ☐ Proceed to contract ☐ Conditional proceed ☐ Further diligence required ☐ Do not proceed

Signed: __ Date: __

Template 2: Model Risk Governance — Model Inventory Record

Purpose: Document each analytical model in the compliance program for SR 11-7 / EU AI Act governance

One record per model

Model Name: ___________

Model ID: ___ Version: __ Last Updated: ____

Field	Detail
Business purpose	What decision or process does this model support?
Model type	(e.g., Gradient Boosted Tree; Logistic Regression; Rules Engine; Neural Network)
Owner (business)	Name and role
Owner (technical)	Name and role
Developed by	☐ Internal ☐ Vendor: _______
Deployment date
Risk tier	☐ Tier 1 (Critical) ☐ Tier 2 (Material) ☐ Tier 3 (Low)
EU AI Act high-risk?	☐ Yes — Annex III category: _______ ☐ No ☐ Under assessment
SR 11-7 model?	☐ Yes ☐ No ☐ N/A (non-US)
Decision type	☐ Fully automated ☐ Human-in-loop ☐ Decision support only

Training Data

Field	Detail
Data source(s)
Training period	From: _ To: _
Sample size
Known biases / limitations
Data quality issues noted

Performance Metrics

Metric	At deployment	Current	Target	Last measured
Primary performance metric (e.g., AUC, Precision)
False positive rate
Population Stability Index (PSI)
Other:

Validation Status

Item	Status	Date	Performed by
Initial validation	☐ Complete ☐ Pending
Most recent periodic validation	☐ Complete ☐ Pending
Next scheduled validation
Validation findings (summary)
Outstanding findings

Regulatory Audit Trail

Field	Detail
Documentation location
SHAP / explainability method available?	☐ Yes ☐ No
Adverse action explanation generated?	☐ Yes ☐ No ☐ N/A
Human oversight mechanism

Change Log (most recent 5 changes)

Date	Change description	Approved by

Template 3: Cyber Incident Notification Decision Matrix

Purpose: Immediate reference tool for compliance professionals assessing notification obligations when a cyber incident is detected

Use: Within the first 4 hours of a confirmed incident

Step 1: Classify the Incident

Question	Yes	No
Does the incident affect ICT systems?	Proceed to Step 2	Non-ICT — different track
Is the incident contained?	May reduce severity	Increases urgency
Is personal data potentially involved?	Triggers GDPR track	No GDPR immediate action
Is payment processing affected?	Check impact tolerance
Are customer-facing services affected?	Check impact tolerance

Step 2: DORA Assessment (EU/Dublin branch operations)

Question	Answer	Action
Does the firm have EU-regulated operations?	☐ Yes ☐ No	If No: skip DORA
Number of users affected?
Affected geographical areas?
Duration of disruption (hours)?
Estimated financial impact?
Major incident?	☐ Yes ☐ No ☐ Unclear	If Yes/Unclear: file initial notification within 4h of classification

If DORA Major Incident: - Initial notification: within 4 hours of classification - Intermediate report: within 72 hours of classification - Final report: within 30 days of classification

Step 3: UK Regulatory Assessment

Obligation	Trigger	Deadline	Action
FCA PRIN 11	Material incident	"As soon as practicable"	☐ Notify ☐ Not required
PRA notification	Material incident	"As soon as practicable"	☐ Notify ☐ Not required
Impact tolerance breach	Actual or projected breach	Document immediately	☐ Document

Step 4: UK GDPR Assessment

Question	Answer	Action
Personal data involved?	☐ Yes ☐ No ☐ Unknown	Unknown = assume Yes
If Yes: awareness time (for 72h clock)
High risk to individuals?	☐ Yes ☐ No	If Yes: notify individuals too
ICO notification required?	☐ Yes ☐ No	Notify within 72h of awareness

Step 5: US Assessment (if US operations)

Obligation	Trigger	Deadline	Action
SEC cybersecurity	Material cybersecurity incident	4 business days	☐ Notify SEC ☐ N/A
FINRA	As applicable	Per FINRA rules	☐ Notify ☐ N/A
State breach laws	Personal data of state residents	Varies by state	☐ Assess ☐ N/A

Decision Log (complete for every incident assessed)

Field	Detail
Incident detected at
Classified at
CCO notified at
DORA classification decision
UK GDPR awareness time (for ICO clock)
Notifications filed
Next deadline
Completed by

Template 4: SAR Filing Decision Checklist

Purpose: Structured documentation of the decision-making process for a Suspicious Activity Report in the UK

Use: Before escalating a case to the MLRO and before filing a SAR with the NCA

Case Reference: ___ Analyst: __ Date: ____

Step 1: Does Suspicion Exist?

The UK tipping-off prohibition (POCA 2002 s.333A) applies once this form is initiated. Do not discuss this case with the customer.

Question	Assessment
What specific activity triggered the alert?
Is there an innocent explanation consistent with the customer's profile?	☐ Yes ☐ No ☐ Uncertain
Have you reviewed the customer's transaction history (minimum 12 months)?	☐ Yes
Have you checked prior alerts and any prior SARs for this customer?	☐ Yes
Is the suspicion based on knowledge, not just a statistical flag?	☐ Yes ☐ Partially

If innocent explanation exists and is plausible: document and close. If suspicion exists or cannot be ruled out: proceed to Step 2.

Step 2: DAML Assessment (Consent SAR)

If the suspicious activity is ongoing and you intend to process a transaction that may constitute money laundering:

Question	Answer
Is this a consent SAR?	☐ Yes ☐ No
If Yes: can processing wait 7 days for NCA response?	☐ Yes ☐ No
NCA reference number obtained?

Step 3: SAR Content Preparation

Element	Completed
Subject information: full name, DOB, address, ID documents	☐
Relationship history with firm	☐
Suspicious activity: specific transactions (dates, amounts, counterparties)	☐
Reason for suspicion: the specific factors that created suspicion	☐
Customer explanation (if sought and appropriate)	☐
Supporting documents attached	☐

Step 4: MLRO Review and Authorization

Field	Detail
Referred to MLRO at
MLRO decision	☐ File SAR ☐ Do not file — reason:
SAR filed with NCA at
NCA reference number
Record retained at

Non-Filing Record (complete if MLRO decides not to file):

If the MLRO decides not to file, document the reasons in detail. This record is evidence of a considered decision, not absence of a decision.

Reasons for non-filing: _________

MLRO signature: ___ Date: _____

Template 5: KYC Periodic Review Record

Purpose: Document a periodic KYC review for an existing customer

Trigger: Standard review cycle; risk upgrade; trigger event (PEP status, adverse media, SARs)

Customer Reference: ___ Review Date: __ Analyst: ____

Review Trigger: ☐ Scheduled (standard cycle) ☐ Risk upgrade ☐ Trigger event: _______

Current Risk Tier: ☐ Low ☐ Standard ☐ High ☐ Very High

Step 1: Identity Verification

Element	Status	Action Required
ID document current?	☐ Yes ☐ No ☐ Expired
Address confirmed?	☐ Yes ☐ No
Biometric match current?	☐ Yes ☐ No ☐ N/A
Beneficial ownership confirmed?	☐ Yes ☐ No ☐ N/A
Beneficial ownership structure changed?	☐ Yes ☐ No	If Yes: re-verify

Step 2: Screening Refresh

Screen	Result	Action
Sanctions (current lists)	☐ Clear ☐ Match
PEP check	☐ Clear ☐ Match ☐ Already PEP
Adverse media	☐ Clear ☐ Alert
INTERPOL / law enforcement	☐ Clear ☐ Alert

Step 3: Risk Assessment

Factor	Current	Previous	Changed?
Customer type			☐ Yes ☐ No
Business type / industry			☐ Yes ☐ No
Countries of operation			☐ Yes ☐ No
Transaction volumes			☐ Yes ☐ No
Source of funds/wealth			☐ Yes ☐ No
PEP status			☐ Yes ☐ No

Risk Assessment Outcome: ☐ Unchanged ☐ Upgraded ☐ Downgraded New Risk Tier: ☐ Low ☐ Standard ☐ High ☐ Very High

Step 4: Outcome and Actions

Action	Required	Completed	Date
Risk tier updated in system
EDD completed (if High/Very High)
SAR assessment (if suspicious activity noted)
Relationship exited (if unacceptable risk)
Next review date set

Analyst sign-off: ___ Supervisor review: _____

Checklist 6: RegTech Program Initiation Checklist

Purpose: Verify that foundational work is in place before committing to a RegTech program

Use: At the beginning of a program planning exercise

Strategic Clarity

[ ] Problem statement defined: what specific compliance gap or risk is being addressed?
[ ] Regulatory obligation identified: which specific regulation is driving the need?
[ ] Success metrics defined: what does "done" look like, measurably?
[ ] Strategic orientation chosen: compliance-driven / risk-driven / business-driven?
[ ] Build/buy/borrow decision made for each component?

Governance

[ ] Executive sponsor identified and committed?
[ ] System owner designated (post go-live)?
[ ] Governance structure defined (steering committee, PMO if required)?
[ ] Decision authority mapped for key program decisions?
[ ] Escalation path for conflicts between CCO/CTO/COO defined?

Data Readiness

[ ] Required data sources identified?
[ ] Data quality assessed for each required source?
[ ] Data access confirmed (can the compliance function access the data it needs)?
[ ] Data retention requirements confirmed for the proposed solution?
[ ] GDPR/UK GDPR lawful basis confirmed for new data processing?

Stakeholders

[ ] All affected stakeholder groups identified?
[ ] Primary concerns of each group understood?
[ ] Change management plan initiated?
[ ] Middle management engaged (not just senior leadership)?

Priya's Five Questions (see Chapter 35)

[ ] What regulatory obligation or risk are you solving for first?
[ ] Who will own the output of this system day-to-day, and do they know?
[ ] What data will this system use, and is it clean, current, and accessible?
[ ] How will you measure whether this worked?
[ ] What changes to human processes does this technology require, and have you planned for them?

Checklist 7: Go-Live Readiness Assessment

Purpose: Final check before production deployment of a RegTech system

Technical Readiness

[ ] All required integrations tested end-to-end?
[ ] Performance testing completed (load, stress)?
[ ] Security assessment completed?
[ ] Rollback plan documented and tested?
[ ] Data migration validated (counts, quality, reconciliation)?
[ ] Monitoring and alerting for the new system configured?

Process Readiness

[ ] All procedure documentation updated (old system references removed)?
[ ] New process maps approved by compliance leadership?
[ ] Regulatory reporting format validated against current requirements?
[ ] Audit trail outputs validated for completeness?

People Readiness

[ ] All user training completed?
[ ] Competence assessments completed for relevant roles?
[ ] Super-users designated and equipped?
[ ] Team leads briefed and aligned?
[ ] Support escalation path documented and communicated?

Regulatory Readiness

[ ] Regulator notification made where required?
[ ] Regulatory reporting tested against production system?
[ ] Model risk documentation complete (SR 11-7 / EU AI Act)?
[ ] Vendor contract completed (including DORA Article 30 provisions where applicable)?

Go/No-Go Decision

[ ] All critical items above: ☐ Green ☐ Amber (documented exceptions) ☐ Red (go-live blocked)
[ ] Amber items reviewed and accepted by: _______
[ ] Go-live authorized by: ___ Date: _____