Module 3

AI in Compliance and RegTech

Automating transaction monitoring, SAR generation, sanctions screening, KYC verification, and regulatory governance

---

The Compliance Problem: Rules, Volume, and Risk

Financial institutions are regulated by dozens of agencies. Every transaction must be screened for money laundering, terrorist financing, sanctions violations, and fraud. Every customer must be verified and their risk assessed. Every suspicious activity must be documented and reported. The volume is staggering. A large bank processes billions of transactions annually. Manual review of even 1 percent would require armies of analysts.

The result: rule-based compliance systems. If a transaction exceeds $10,000, file a report. If a customer matches a sanctioned person list, block the transaction. If a customer's transaction volume spikes, escalate to human review. These rules are explicit, auditable, and regulatory-approved. They are also noisy. Financial institutions file millions of suspicious activity reports (SARs) annually. Regulators estimate 95-98 percent of SARs are false positives. The true threats are buried in noise.

Compliance automation is not about reducing regulatory burden. It is about reducing noise so that human analysts can focus on genuine risk instead of spending 95 percent of their time on false positives that mean nothing.

This is where AI comes in. Machine learning can learn suspicious patterns without explicit rule programming. Anomaly detection can flag deviations from customer baseline behaviour. Natural language processing can extract information from documents and news. Computer vision can verify that a physical ID matches the customer's face. The result: fewer false positives, more genuine risk flagged, higher analyst productivity, and better regulatory outcomes.

---

Transaction Monitoring: From Rules to ML-Based Anomaly Detection

Transaction monitoring is the frontline of compliance. Every transaction is screened for suspicious activity. Rule-based monitoring generates false positive rates so high that they are practically noise. ML-based monitoring aims to change that.

Rule-Based Transaction Monitoring: The Baseline

Rule-based monitoring uses explicit thresholds. Any transaction over $10,000 is flagged (federal reporting threshold in the US). Any transaction to a high-risk country is flagged. Any customer whose transaction volume increases 10x in a month is flagged. Any transaction matching a keyword search (money, gold, cash, transfer) is flagged.

These rules catch some real money laundering. They also flag millions of legitimate transactions. A customer vacationing in Mexico might make multiple international transfers. A business importing goods might make large payments. A legitimate customer moving money between their own accounts triggers velocity alerts. The false positive burden is enormous.

ML-Based Anomaly Detection: Customer-Centric Baselines

ML-based monitoring learns what "normal" is for each customer, then flags deviations. For a customer who regularly sends $500 international transfers to family, a $50,000 transfer is anomalous. For a business that regularly makes $100,000 payments, it is normal. The model learns this distinction from data.

Customer-centric baselines are powerful because they eliminate false positives from legitimate high-value activity. A customer with a high baseline still triggers alerts for genuine suspicious behaviour within their pattern. A $1 million transfer from a customer whose typical transfer is $500 is still anomalous even though their absolute baseline is high.

Peer Group Analysis: Is Your Behaviour Like Others Like You?

Beyond individual customer baselines, peer group analysis asks: is this customer's behaviour similar to other customers with similar characteristics? If all customers in a certain geography, business type, or risk profile send average transfers of $50,000, and one customer is sending $5,000 transfers with unusual patterns, is that suspicious?

Peer group analysis catches targeted fraud or money laundering that would look normal within an individual baseline. A customer might normally send $50,000 transfers (high but normal). Suddenly they start sending $1,000 transfers in unusual patterns (low but suspicious). An individual model might miss it (activity is lower than baseline). A peer group model flags it (pattern is different from peer group average).

Explainability and Analyst Efficiency

Compliance analysts need to understand why something was flagged. A rule-based system is trivial: this transaction exceeded the $10,000 threshold. A model-based system requires explainability: which features contributed to this anomaly score? Was it the transfer amount, the destination, the frequency, the time of day?

Modern ML-based transaction monitoring systems provide feature importance: which factors drove the alert. This allows analysts to quickly assess whether the alert is legitimate or a false positive. A transfer that looks anomalous because it is higher than the customer's baseline is probably legitimate. A transfer that is anomalous for multiple reasons (high amount, unusual destination, unusual timing, rare customer activity pattern) is more likely suspicious.

---

SAR Auto-Generation: From Manual Drafting to NLP

When a transaction is flagged as suspicious, a compliance analyst must investigate and potentially file a Suspicious Activity Report (SAR) with regulators. The SAR is a legal document describing the suspicious activity, the parties involved, and the bank's analysis of why it was suspicious. Manually drafting SARs is labor-intensive. Automating it is one of RegTech's most impactful applications.

Information Extraction: NLP Reads the Transaction

An NLP model reads transaction data, customer information, and investigation notes, then extracts key information: parties involved, transaction amounts, timing, patterns, and risk factors. The model identifies which information is relevant to the SAR filing and structures it appropriately. A SAR requires specific information (originator, beneficiary, amount, date, narrative description of suspicious activity). The NLP model ensures all required information is captured.

Narrative Generation: Drafting the SAR Text

The narrative section of a SAR is critical. It describes why the transaction is suspicious, which facts led to that determination, and what patterns were observed. Manual drafting requires trained compliance specialists. Generating narratives automatically is challenging because the narrative must be clear to regulators, legally defensible, and factually accurate.

Modern language models can generate SAR narratives by learning patterns from previously filed SARs. The model learns which facts are relevant, how to structure the narrative, which language regulators expect. Given extracted information about a transaction, the model generates a narrative that a compliance analyst can review, edit, and file.

Context and Audit Trails: Why This Was Flagged

SAR auto-generation requires maintaining full audit trails. Why was this transaction flagged? Which alert rule or ML model triggered the flag? What human review occurred? Which analyst made the filing decision? Regulators require this trail. If a bank is accused of missing money laundering, the bank must defend its compliance process. Complete audit trails demonstrate that the bank executed a diligent review.

AI systems handling compliance decisions are held to this standard. If a model made a recommendation, the input data and model logic must be documentable. Opaque black-box models are problematic in compliance. Explainable models with logged decisions are defensible.

---

Sanctions Screening: Entity Resolution at Scale

Sanctions screening is matching customer names against sanctioned person lists: OFAC (US Office of Foreign Assets Control), EU sanctions lists, UN lists, and others. If a customer or beneficiary appears on a sanctioned list, the transaction must be blocked. The problem: names have variants, transliterations differ, and lists are massive. A customer named "Muhammad Ahmed Hassan" might appear as "Mohammed Ahmad Hassan" or "Mohammad Ahmet Hasan" in records. The variations are infinite. Exact matching fails. Fuzzy matching helps but generates false positives.

Fuzzy Matching and String Similarity

Fuzzy matching uses string similarity algorithms to match names that are similar but not identical. Levenshtein distance measures the number of edits needed to transform one string into another. If two names require only a few edits to match, they are probably the same person. A similarity threshold (e.g., 90 percent match) triggers an alert for manual review.

Fuzzy matching reduces false negatives (missed matches) but increases false positives (incorrect matches). A customer with a common name might match dozens of sanctioned persons due to similarity alone. Manual review burden becomes enormous.

Transliteration and Entity Resolution Across Languages

International sanctions lists include names in multiple scripts and languages. A person might appear as "Владимир Путин" (Cyrillic) or "Vladimir Putin" (Latin characters). Different transliteration standards produce different romanizations. Matching across languages requires transliteration: converting from one script to another, then applying fuzzy matching.

Entity resolution at scale uses machine learning. Given a customer name and a sanctions list, which records on the list correspond to the same person? The model learns features beyond name similarity: birth date matches, known associates, historical patterns. A name match with the same birth date and nationality is more likely the same person than a name match alone.

Reducing False Positives: Confidence Scoring

Sanctions screening produces confidence scores: how confident is the system that this customer matches a sanctioned person? High confidence (99 percent) triggers automatic blocking. Medium confidence (70-90 percent) triggers manual review. Low confidence (below 70 percent) is ignored or used for supplementary risk scoring.

The confidence score combines multiple signals: name similarity, date of birth match, nationality match, known associates. If all signals align, confidence is high. If only the name is similar but date of birth and nationality diverge, confidence is lower. This reduces false positives from simple name matches while maintaining detection of actual matches.

---

KYC Automation: Document Verification and Risk Scoring

Know Your Customer (KYC) verification is the gate to account opening. Before a bank accepts a customer, they must verify identity, assess risk, and determine appropriate limits. Traditional KYC is manual: a customer submits documents, a compliance specialist reviews them, the specialist makes a decision. The process takes days or weeks. Digital KYC automation can reduce this to minutes using AI.

Document Verification: Computer Vision for ID Matching

A customer uploads a government-issued ID (passport, driver's license) and a selfie. Computer vision models verify that the ID is genuine and that the face in the selfie matches the face on the ID. This is called liveness detection. The system confirms the customer is real, the document is real, and the customer is the person on the document.

Computer vision for document verification has become standard. Major platforms like Jumio, Socure, and Onfido provide APIs for this verification. The technology checks for document authenticity (is this a real passport or a fake?), extracts key information (name, date of birth, document number), and compares the extracted information with the customer's declared information.

Data Extraction: OCR and Structured Information

Optical character recognition (OCR) extracts text from documents. A passport becomes machine-readable data: name, date of birth, nationality, passport number, expiration date. This structured information is then compared against customer-provided information for consistency. If the customer claims a different name or date of birth than the document shows, a flag is raised for manual review.

Modern OCR uses deep learning and can handle complex documents: passports in any language, driver's licenses with various formats, residence permits with worn pages. The accuracy is high enough for automated decision-making in most cases.

Risk Assessment: From Documents to Scores

After documents are verified, a risk score is computed. The score incorporates document factors (document age, authenticity checks) and customer factors (age, nationality, geography, profession, intended transaction size). A student opening an account for small transfers is low risk. A customer in a high-risk jurisdiction with large transaction intentions is flagged for enhanced due diligence.

Risk scoring combines structured data (age, document type, nationality) with unstructured signals (customer information gathered from news searches, adverse media checks). ML models learn which combinations of factors predict high risk. The result: risk scores that can be automated for common cases and escalated for unusual cases.

Frictionless Onboarding vs. Regulatory Safety

Automating KYC speeds onboarding but creates risk. A fully automated system might approve suspicious accounts quickly. A system with too much manual review is slow and customers abandon the signup process. The optimal system uses smart risk routing: approve clear cases automatically, escalate borderline cases to humans, and block obvious high-risk cases.

This tiered approach balances customer experience and compliance. Most customers (95 percent) are approved in seconds. A few percent require manual review. A tiny percent are blocked. The business outcome: good customer experience for most, compliance for all.

---

Regulatory Guidance and Model Governance

Financial regulators are watching AI adoption in compliance closely. The use of AI in high-stakes decisions (deny a customer, block a transaction) creates regulatory risk if the AI is not properly governed. Key regulatory concerns come from SR 11-7, US Federal Reserve guidance on model risk management.

SR 11-7: Model Risk Management Principles

SR 11-7 (issued 2011, reinforced through recent guidance) requires financial institutions using models for decision-making to implement model risk management. The key principles: model governance (clear ownership and oversight), model development standards (validation, testing, documentation), model implementation controls (monitoring, escalation procedures), and audit trails (complete logging of decisions and reasoning).

For AI models in compliance, this means: the bank must document the model's purpose, the data used, the validation results, and known limitations. The bank must monitor the model's performance and retrain it if performance degrades. The bank must be able to explain any individual decision made by the model. The bank must test the model for bias and adverse impact.

Explainability Requirements: Decisions Must Be Defensible

A model that flags a customer as high-risk and blocks them is subject to explainability requirements. Why was this customer blocked? If the answer is "the model said so," that is insufficient. The bank must explain which factors the model considered, which thresholds were exceeded, what alternative actions were considered.

This is driving demand for interpretable models. Gradient boosted trees (used in fraud and risk) are more interpretable than neural networks. Ensemble models with documented voting logic are more defensible than black-box models. Linear models with logged coefficients are more auditable than complex non-linear models.

Bias and Adverse Impact: Models Must Not Discriminate

A model that systematically denies credit to customers from certain geographies or demographics is discriminatory, even if unintentional. Regulators require testing for adverse impact: does the model produce different outcomes for protected classes (based on race, gender, nationality)? If so, the model must be adjusted.

Testing for adverse impact requires careful analysis. Some demographic differences in outcomes are explained by legitimate factors (credit history, income). Others indicate the model learned to use proxies for protected classes. A model that approves customers from certain zip codes might be using zip code as a proxy for race, which is illegal even if the model never explicitly sees race as a feature.

---

RegTech Platforms: Unit21 and Hummingbird

Two specialized RegTech platforms illustrate different approaches to compliance automation.

Unit21: Workflow Automation and Case Management

Unit21 builds compliance case management and workflow automation. The platform provides no-code rule building: compliance teams can define alert rules without writing code. It provides ML-based case prioritisation: cases likely to be genuine fraud are prioritised above cases likely to be false positives. It provides document management: SARs can be drafted, reviewed, and filed through the platform.

Unit21's value is in workflow efficiency. Rather than analysts manually handling alerts in spreadsheets, cases flow through defined workflows. Alerts are deduplicated, related cases are grouped, and analyst notes are tracked. The result: analysts spend less time on data entry and more time on judgment calls.

Hummingbird: SAR Filing and Regulatory Reporting

Hummingbird specializes in SAR filing and regulatory reporting automation. The platform takes alert data, generates SAR narratives, and manages filing workflows. SAR information is standardized and filed electronically with FinCEN (US Financial Crimes Enforcement Network).

Hummingbird's value is in regulatory compliance. SARs must be filed with precise information and correct timing. Missing a filing deadline or submitting incomplete information creates regulatory violations. Hummingbird ensures accuracy and timeliness through workflow automation and audit trails.

---

The RegTech Category: Fastest-Growing Segment of Financial AI

Compliance automation is the fastest-growing category of financial AI. Why? The problem is enormous. Regulatory burden is increasing. Analyst costs are rising. And AI solutions have proven ROI: fewer false positives mean better analyst productivity, fewer missed threats, and better regulatory outcomes.

RegTech is particularly attractive to incumbents because it directly reduces costs. A large bank might have 500 compliance analysts. AI-driven automation could reduce that to 300 while actually improving detection. The savings are hundreds of millions annually. Banks invest heavily in RegTech because the payback is direct and fast.

RegTech is also attractive to smaller financial institutions because it democratizes compliance. A fintech startup cannot afford to build internal compliance infrastructure. But using a RegTech platform like Unit21 or Hummingbird, they can automate compliance at scale. This shifts competitive advantage: the question is no longer who can afford to hire the best compliance team, but who can best use automated tools.

---

The Future: Real-Time Compliance Decisioning

Today's compliance automation is mostly retroactive. A transaction is flagged, analysts investigate, regulators are notified. The future is real-time compliance decisioning: blocking suspicious transactions at the moment of initiation based on automated analysis.

This requires end-to-end automation: the transaction is submitted, real-time features are computed (customer risk level, transaction patterns, sanctions screening results), a decision model scores the transaction, the transaction is approved or blocked in milliseconds, and audit trails are logged. For high-risk transactions, the system escalates to human review automatically.

Real-time compliance decisioning creates new regulatory questions. If a bank automatically blocks a transaction based on an AI decision, what transparency must be provided to the customer? The tension is between compliance efficiency (fast decisions) and customer rights (explanation for decisions). Regulators are still working out these questions, but the direction is clear: more real-time, more automated, more AI-driven.