Appendix F: Frequently Asked Questions

Regulatory Technology (RegTech): Common Questions from Practitioners and Students

This appendix addresses questions that frequently arise when practitioners engage with RegTech concepts for the first time, or when moving from classroom understanding to real-world implementation.

Part 1: Foundational Questions

Q: What exactly counts as "RegTech"? Is any compliance software RegTech?

The term RegTech (regulatory technology) is sometimes used narrowly — to describe only the most technically advanced compliance automation tools — and sometimes broadly, to encompass any technology applied to compliance challenges. This textbook uses a functional definition: RegTech is technology that materially improves the effectiveness, efficiency, or scalability of regulatory compliance. By this definition, a well-implemented Excel-based reporting system is not RegTech; an AI-driven transaction monitoring system is. The key characteristics are: automation of compliance processes that would otherwise require manual effort; use of data and analytics to improve compliance outcomes; and scalability that allows compliance programs to grow without proportional increases in headcount.

Q: Do I need to be a programmer to work in RegTech compliance?

No — but you need data literacy. The most effective compliance professionals working in RegTech contexts are not necessarily programmers; they are people who can read a technical specification, understand what a model's outputs mean, ask the right questions of data scientists, and translate between regulatory requirements and technical capabilities. Python programming skills are increasingly valuable for compliance professionals who want to do their own analysis (and this textbook provides a foundation for that), but they are not required for most compliance roles that involve RegTech oversight.

Q: What is the difference between RegTech and FinTech?

FinTech (financial technology) refers broadly to technology applied to financial services — payments, lending, investing, banking. RegTech is a subset of FinTech specifically focused on regulatory compliance. A mobile payment app is FinTech. The compliance infrastructure that prevents that payment app from being used for money laundering is RegTech. In practice, many FinTech firms use RegTech solutions to meet the compliance obligations that come with financial services regulation.

Q: Is RegTech only for large institutions?

No. While large institutions have the volume of compliance work that makes the economics of sophisticated automation most compelling, many RegTech solutions are available at price points accessible to challenger banks, fintechs, and smaller regulated entities. The FCA's Innovation Hub and similar regulatory sandboxes have specifically encouraged RegTech adoption by smaller, newer entrants. Indeed, challenger banks like the fictional Verdant Bank throughout this textbook are often RegTech's most enthusiastic adopters — they lack the legacy infrastructure that makes transformation difficult for large incumbents.

Part 2: KYC and AML Questions

Q: What is the difference between KYC and CDD? Are they the same thing?

KYC (Know Your Customer) is the broader concept — understanding who your customer is. CDD (Customer Due Diligence) is the specific regulatory obligation under AML rules that requires financial institutions to verify customer identity, understand the nature of the business relationship, and assess the risk of money laundering. In practice, KYC and CDD are often used interchangeably, but strictly speaking, KYC is the business practice and CDD is the regulatory requirement that formalizes it. A well-designed KYC program satisfies CDD requirements; CDD requirements define the minimum standard that a KYC program must meet.

Q: Why do AML systems have such high false positive rates? Can't they be made more accurate?

False positive rates in AML monitoring reflect a fundamental tradeoff: the cost of missing a true positive (a real money laundering transaction that is not caught) is regulatory, reputational, and potentially criminal. Institutions therefore calibrate their systems to err on the side of catching more alerts, accepting that many will turn out to be legitimate. A 30% false positive rate is not a system failure — it is a deliberate calibration choice. ML-based systems have reduced false positive rates substantially (from 80-90% in older rules-based systems to 20-30% in better ML systems) but cannot eliminate them without accepting higher miss rates. The regulatory expectation is not zero false positives; it is a defensible calibration that prioritizes detection over efficiency.

Q: What is the difference between a Suspicious Activity Report (SAR) and a currency transaction report (CTR)?

A SAR (Suspicious Activity Report, called a Suspicious Activity Report in the US and a Suspicious Transaction Report or STR in some other jurisdictions) is filed when a financial institution has a reason to suspect that a transaction involves money laundering, terrorism financing, or other financial crime. It is judgment-based — the institution decides whether suspicion exists. A Currency Transaction Report (CTR, known by various names in different jurisdictions) is filed automatically when a cash transaction exceeds a specified threshold (USD 10,000 in the US). CTRs are threshold-based, not judgment-based. Both exist to provide financial intelligence to law enforcement, but they serve different analytical purposes.

Q: What does "tipping off" mean and why is it such a serious offense?

Tipping off means informing a customer — directly or indirectly — that they are the subject of a suspicious activity report or an AML investigation. It is a criminal offense in most AML jurisdictions because it allows potential criminals to destroy evidence, move funds, or alter their behavior to evade investigation. Compliance professionals who are investigating suspicious activity must be careful not to alert the customer through their actions (for example, by requesting unusual documentation or holding a transaction without explanation in ways that signal an investigation is underway). This creates genuine operational tensions — especially in contestability processes for AML-triggered account restrictions — that require careful procedure design.

Q: How does Beneficial Ownership work in practice? Why is it difficult?

Beneficial ownership refers to identifying the natural persons who ultimately own or control a legal entity (a company, trust, partnership). The challenge is that ownership structures can be highly complex: Company A is owned by Company B, which is owned by a trust in Jurisdiction C, whose beneficiaries include several natural persons. Determining who ultimately controls Company A requires working through each layer of this structure — and many jurisdictions have incomplete or inaccurate company ownership registries that make verification difficult. AMLA (the EU Anti-Money Laundering Authority) and similar regulatory initiatives are improving beneficial ownership transparency, but it remains one of the most challenging and resource-intensive aspects of KYC.

Part 3: Regulatory Reporting Questions

Q: What is XBRL and why is it used for regulatory reporting?

XBRL (eXtensible Business Reporting Language) is a structured data format that allows regulatory reports to be machine-readable. Instead of a PDF or spreadsheet that a human must interpret, an XBRL document contains data in tagged form — each data point is labeled with its precise meaning (e.g., "total_tier_1_capital" rather than a number in a particular cell of a spreadsheet). This allows regulators to aggregate and analyze data from thousands of reporting firms automatically. Most major regulatory reporting regimes — EBA, SEC, FCA — use XBRL or are transitioning to it.

Q: What is the difference between EMIR and MiFIR reporting?

Both are EU (and UK post-Brexit) regulatory reporting requirements for financial instruments, but they cover different things. EMIR (European Market Infrastructure Regulation) reporting covers derivatives transactions — all OTC derivatives must be reported to a trade repository. MiFIR (Markets in Financial Instruments Regulation) transaction reporting covers a broader set of financial instruments traded on or through regulated venues, focusing on market transparency and abuse detection. A financial institution active in derivatives markets may need to report the same trade to both regimes, with different data requirements under each. The overlap is a significant source of operational complexity and regulatory reporting cost.

Q: How often must regulatory reports be filed?

It depends on the report. Some are real-time or near-real-time (EMIR derivative reporting must occur by the next business day; MiFIR transaction reporting occurs T+1). Some are daily (certain liquidity metrics under the liquidity coverage ratio framework). Some are monthly (many FCA firm data returns). Some are quarterly (many capital adequacy reports). Some are annual (ICAAP, ILAAP, some AML risk assessments). The compliance reporting calendar — tracking all deadlines across all applicable reporting obligations — is itself a complex management task for large institutions.

Part 4: Technology and AI Questions

Q: What is the difference between explainability and interpretability in AI models?

These terms are often used interchangeably, but there is a useful distinction. Interpretability refers to the intrinsic property of a model that makes it possible to understand its predictions directly — a decision tree is interpretable because you can trace the exact path from inputs to output. Explainability refers to the ability to provide a post-hoc explanation of a model's prediction — even for a black-box model like a gradient boosted tree, you can use SHAP values to explain why a specific prediction was made. Most regulatory requirements (adverse action explanation, GDPR right to explanation, EU AI Act transparency) require explainability rather than interpretability — the explanation can be generated after the fact, as long as it accurately reflects what the model was doing.

Q: What is a "hallucination" in an LLM context and why does it matter for compliance?

A "hallucination" occurs when a large language model generates text that is factually incorrect or unsupported by its training data but presents it with the same confident tone as accurate information. In compliance contexts, this is a significant risk: an LLM asked to summarize a regulation might invent details of specific article numbers, penalty amounts, or effective dates that do not correspond to the actual regulation. Unlike a factual error in a human analyst's work (which tends to be associated with evident uncertainty), LLM hallucinations are often stated confidently, making them difficult to identify without verification against primary sources. Chapter 39 discusses the appropriate use of LLMs in compliance — as research accelerators requiring expert verification, not as autonomous compliance decision-makers.

Q: What is "model drift" and when does it become a compliance problem?

Model drift occurs when the statistical characteristics of the data a model encounters in production differ significantly from the data it was trained on. For a fraud detection model trained on 2021 data, drift might occur because fraud tactics have evolved — the patterns the model was trained to detect are no longer the patterns being used. For an AML monitoring model, drift might occur because the customer base or transaction patterns have changed. Drift becomes a compliance problem when the model's performance has degraded — when its alert accuracy, precision, or recall has fallen below the level the institution told regulators it would maintain. PSI (Population Stability Index) is the standard metric for detecting drift; a PSI above 0.25 requires investigation.

Q: What does the EU AI Act classify as "high-risk AI"?

The EU AI Act Annex III lists eight categories of high-risk AI systems, several of which are directly relevant to financial services: (1) AI used in credit scoring and creditworthiness assessment; (2) AI used in determining access to financial services; (3) AI used in employment and hiring decisions; (4) AI used in biometric identification and categorization. High-risk AI systems must meet requirements including: a risk management system throughout the lifecycle; data governance for training data; technical documentation; transparency; human oversight; accuracy and robustness testing; and a conformity assessment before market placement. Financial institutions deploying AI in credit decisioning, KYC, or fraud detection should assess whether those systems fall into Annex III categories.

Q: What is SupTech and how is it different from RegTech?

RegTech is technology used by regulated firms to meet their compliance obligations. SupTech (supervisory technology) is technology used by regulators to supervise regulated firms. The same underlying technologies (AI, ML, NLP, data analytics) are used on both sides of the regulatory relationship. Examples of SupTech include the FCA's use of NLP to analyze regulatory submissions; the ECB's AnaCredit system for granular credit data collection; and the BIS Innovation Hub's various supervisory analytics projects. The growing sophistication of SupTech changes the compliance environment for regulated firms: regulators who can analyze firm data directly, in near-real-time, have very different supervisory capabilities than those who rely on periodic paper-based submissions.

Part 5: Professional Practice Questions

Q: What is the difference between a CISO and a CCO? Where do their responsibilities intersect?

The CISO (Chief Information Security Officer) is responsible for the firm's information security posture — protecting its systems and data from cyber threats. The CCO (Chief Compliance Officer) is responsible for the firm's regulatory compliance program — ensuring it meets its legal obligations to regulators. These roles intersect extensively in the cybersecurity compliance area: when a cyber incident triggers regulatory notification obligations, both the CISO (who manages the incident) and the CCO (who manages the regulatory response) must work together. DORA, UK GDPR, and operational resilience frameworks have formalized this intersection by making cybersecurity governance a compliance obligation, not just an IT best practice.

Q: How should a compliance professional approach a situation where their firm's legal team says something is compliant but they believe it raises ethical concerns?

Chapter 34 addresses this directly. The key insight is that legal compliance and ethical conduct are not the same thing — what is legal is the floor, not the ceiling, of acceptable behavior. A compliance professional who identifies ethical concerns that legal counsel has not addressed should raise those concerns explicitly and through the appropriate channels. The virtue ethics framework is particularly relevant here: the compliance professional's distinctive role is to ask questions that others may not be positioned to ask — "who is this affecting?", "is it fair?", "can we explain and defend it?" If internal channels are unavailable or unresponsive, professional obligations may require escalation. The specific escalation path depends on the severity of the concern and the firm's governance structure.

Q: What does it mean to be "fit and proper" in a compliance role?

In UK financial services, the FCA and PRA require that individuals in controlled functions (including senior compliance functions) be "fit and proper" — meaning they have the appropriate honesty, integrity, reputation, competence, capability, and financial soundness for their role. For compliance professionals in technical RegTech roles, competence includes not just regulatory knowledge but the technical literacy to understand and govern the systems they oversee. An individual who approves the use of an AI credit scoring system without understanding what the system does, how it can fail, and how its outputs should be interpreted is arguably not competent for that oversight function.

Q: How do I keep up with regulatory change in RegTech? The landscape seems to change constantly.

The most effective approaches combine breadth and depth: - Regulator feeds: Sign up for email updates from the FCA, PRA, EBA, ESMA, FinCEN, CFTC, SEC, and other relevant regulators. Most publish Dear CEO letters, consultation papers, and policy statements directly. - Horizon scanning tools: NLP-based regulatory intelligence platforms (Chapter 23) aggregate and summarize regulatory developments across multiple regulators. Several are available at accessible price points for individual practitioners. - Professional networks: ICA, ACAMS, CISI, and similar professional bodies provide continuing education, publications, and peer networks that keep practitioners current. - Regulatory engagement: Regulators genuinely welcome engagement through consultation processes. Responding to consultations is both an opportunity to influence regulation and a way to understand regulatory thinking before it becomes final. - This textbook: Provides the frameworks for understanding how regulatory change fits into the broader landscape — which is more durable than knowledge of any specific current rule.

Part 6: Implementation Questions

Q: How do I know if a RegTech vendor is financially stable enough to be a long-term partner?

Chapter 36 covers this in detail. Key indicators: the vendor's funding history (how much have they raised, from whom, when?); their revenue concentration (do they depend on a small number of large clients?); their profitability trajectory; and whether they have been subject to acquisition interest or consolidation. A vendor that has a single institutional investor, is pre-revenue, and serves fewer than 20 clients represents a different concentration risk than one with strategic investors, established revenue, and 200 clients. DORA and the FCA CTP framework both require firms to assess vendor financial stability as part of third-party risk management.

Q: What is "implementation creep" and how do I prevent it?

Implementation creep is the expansion of a RegTech implementation's scope beyond its original design — adding features, integrations, and capabilities that were not in the original specification. It is one of the most common causes of RegTech implementation delays and cost overruns. Prevention requires: a well-defined requirements document that is formally frozen before implementation begins; a formal change request process for any scope changes; a project governance structure with authority to reject scope changes that are not critical; and explicit management of the trade-off between additional capability and implementation timeline and budget.

Q: How long should I expect a RegTech implementation to take?

It depends significantly on the system type and complexity. Simple transaction monitoring upgrades with an established vendor: 3-6 months. Complex integrations involving multiple source systems and data migration: 9-18 months. Enterprise-wide regulatory reporting platforms: 12-24 months. Cloud migrations with regulatory data residency requirements: 6-18 months. These ranges assume adequate project governance, skilled implementation teams, and no major scope changes. Underestimation of implementation timelines is endemic in RegTech — budget for contingency.

Q: My institution already has a compliance team that does this work manually. How do I make the business case for automation?

Chapter 38 covers business case construction in detail. The key components: (1) document the cost of the current manual process (FTE time, error rates, management time, consultant spend); (2) identify the value categories that automation delivers (cost efficiency, risk reduction, regulatory relationship, revenue enablement); (3) build the three-year NPV with explicit assumptions; (4) run sensitivity analysis to test robustness; (5) present the cost of the status quo, not just the benefit of automation. The most powerful business cases are not "automation will save money" but "here is what our current process is actually costing us, including the regulatory risks it is not fully managing."