How We Built an AI System That Reads Regulations Across 4 Continents So a Compliance Team of 8 Doesn't Miss the One That Matters

Client: Under NDA — cross-border B2B payments company | Industry: Fintech / Regulatory Compliance | Jurisdictions: US, EU, UK, UAE, Saudi Arabia | Regulatory Bodies Monitored: 18 | Timeline: ~8 months | HQ: London, with offices in New York, Amsterdam, and Dubai

---

At a Glance

---

What Was Going Wrong

The company processes cross-border B2B payments — businesses in Europe paying suppliers in the Middle East, US companies receiving payments from UK clients, that kind of thing. They hold licenses in 8 jurisdictions: an EMI license in the EU (passported across member states), FCA e-money authorization in the UK, money transmitter licenses in 23 US states, CBUAE payment service provider license in the UAE, and SAMA fintech license in Saudi Arabia. Annual transaction volume: about $1.8 billion.

That's a lot of regulators to keep happy. Here's who was watching them:

US: FinCEN (AML), CFPB (consumer protection), OCC (banking regulation), plus 23 individual state regulators — each with their own examination schedules, reporting requirements, and rule changes. California alone issues more guidance than some entire countries.

EU: European Banking Authority, European Central Bank, plus national regulators — BaFin in Germany, AMF in France, DNB in the Netherlands. EU-wide directives (PSD2, now PSD3 in progress, AML Directives, GDPR, DORA, MiCA) that each member state implements slightly differently.

UK: FCA and PRA. Post-Brexit, the UK started diverging from EU regulations — sometimes subtly, sometimes significantly. What was once "follow the EU rule" became "follow the EU rule AND the UK version AND track where they differ."

Middle East: CBUAE and DFSA in the UAE, SAMA in Saudi Arabia. Both countries were building their regulatory frameworks in real time — new rules every few months as they established fintech ecosystems from near-scratch.

Plus: FATF for global AML standards, OFAC/EU/UK/UN for sanctions, and the DPDP/GDPR/CCPA/PDPL data protection patchwork.

Eighteen regulatory bodies. Four languages (English, German, French, Arabic). Roughly 800+ publications per month across all of them — circulars, guidance notes, consultation papers, enforcement actions, FAQs, master directions, and amendments to amendments.

The compliance team was 8 people: 2 in London, 2 in New York, 2 in Amsterdam, 2 in Dubai. They were experienced, diligent, and completely overwhelmed.

They couldn't read fast enough. Each person was responsible for monitoring 4–5 regulatory sources. In practice, they'd check their assigned regulators' websites once or twice a week, skim the latest publications, and flag anything that looked relevant. "Looked relevant" was the operative phrase — they were making judgment calls based on titles and executive summaries, because reading every 40-page circular in full wasn't humanly possible. They estimated they were thoroughly reading about 25% of publications and skimming the rest.

They found out about things too late. When DORA (the EU's Digital Operational Resilience Act) came into full effect in January 2025, their compliance team didn't flag its relevance to their payment processing operations until 6 weeks before the deadline. The regulation had been published 2 years earlier, but it was initially categorized as "mostly for banks and insurers" — which was true, but payment service providers were also in scope, buried in a definition clause on page 34. Six weeks wasn't enough time. They scrambled, engaged emergency external counsel at €600/hour, and barely made it.

Cross-jurisdiction conflicts were invisible. The UK and EU AML frameworks diverged after Brexit. Their AML policy was written for EU compliance and assumed UK alignment. It didn't align anymore. Nobody noticed until a FCA examiner pointed it out during a routine review. Not a fine, but a formal "requirement to remediate" — which meant 3 months of policy rewriting and a follow-up examination.

Audit preparation was a marathon. When a regulator announced an examination (FCA annual review, CBUAE inspection, FinCEN examination), the team would spend 4–6 weeks gathering evidence. Policy documents in SharePoint. Training records in the HR system. Transaction monitoring logs in the AML platform. Compliance meeting minutes in someone's email. Board reports in a shared drive. Every audit was a scavenger hunt. Two people would be effectively full-time on audit prep while their regular monitoring duties slipped.

They were spending $1.2M/year on external help. Compliance consultants, law firms, and regulatory intelligence services — just to stay informed about what was happening. Most of that spend was defensive: "tell us what we're missing." The answer was usually "quite a lot."

The Chief Compliance Officer put it this way: "My team is smart. But I'm asking 8 people to read everything that 18 regulators publish, in 4 languages, across 4 legal systems, and tell me which ones could shut us down. The math doesn't work."

---

What We Built

A system that reads every regulatory publication across all 18 sources, determines what's relevant, maps it to the company's existing policies, identifies gaps, generates action items with deadlines, and answers the compliance team's questions — with citations to the specific regulatory text. The AI does the reading; the compliance team does the judgment.

Step 1: Multi-Source Regulatory Feed

The foundation: getting every regulatory publication into one place, in real time.

We built scrapers for 18 regulatory body websites. Each one is different. The FCA publishes on a clean, well-structured website with RSS feeds. BaFin publishes in German, sometimes with English summaries, sometimes without. The SEC has EDGAR (structured data, APIs available). CBUAE publishes circulars as PDFs uploaded to a page with no consistent naming convention. SAMA publishes in Arabic with English translations that arrive 1–3 weeks later.

Each scraper runs on a schedule — hourly for the high-volume sources (SEC, FCA, EBA), every 4 hours for others. When a new publication is detected, the system:

1. •Downloads the full text (HTML, PDF, or DOCX — whatever format the regulator uses)
2. •Extracts and cleans the text (PDF extraction is the worst — regulatory PDFs love multi-column layouts, footnotes that break parsing, and tables that span pages)
3. •Translates non-English publications (German, French, Arabic) using the LLM with specialized legal terminology preservation — we don't use generic machine translation because regulatory terms have precise legal meanings that Google Translate butchers
4. •Generates a structured metadata record: source regulator, publication date, document type (circular/guidance/enforcement/consultation), topic tags, affected entity types
5. •Indexes the full text for search and RAG

One specific nightmare: regulatory bodies don't just publish new regulations. They publish amendments to existing regulations, sometimes as "tracked changes" PDFs, sometimes as "replace paragraph 4.3.1 with the following" — requiring you to read the amendment against the original to understand what changed. We built a diffing system that takes the original regulation and the amendment and produces a clean "here's what's new and what changed" summary. This alone saved the compliance team hours every week.

The system ingests about 800–900 publications per month across all sources. Before, the team was aware of maybe 200 of them.

Step 2: Relevance Classification

Not everything matters. An FCA circular about mortgage lending doesn't affect a payments company. A SAMA directive about insurance reserves is irrelevant. The team was drowning partly because they couldn't quickly separate signal from noise.

The LLM reads each publication and classifies it into three buckets:

• •Relevant (~30–50/month): Directly affects the company's licensed activities, products, or obligations
• •Potentially relevant (~40–60/month): Might affect them — depends on interpretation, or affects adjacent areas that could have knock-on effects
• •Not relevant (~700+/month): Outside their scope entirely

The classification isn't based on keywords — it's based on the LLM understanding the company's business model, licenses, products, and jurisdictions. We gave the system a detailed "company profile" — what they do, where they're licensed, what products they offer, what customer types they serve. The LLM uses this context to make relevance judgments.

Example: A new EU directive on "operational resilience for financial entities" — is that relevant? The title doesn't mention payments. But the definition section includes "payment service providers" in scope. A keyword-based system would miss it. The LLM reads the definition section and flags it.

Accuracy after 6 months of tuning: the system correctly classifies about 93% of publications. The 7% errors split roughly evenly between false positives (flagged as relevant when it wasn't — annoying but safe) and false negatives (missed something relevant — dangerous). The false negatives tend to be edge cases where a regulation affects them indirectly — through their banking partners or technology providers rather than directly. We're still improving this, and the compliance team reviews the "potentially relevant" bucket manually as a safety net.

Step 3: Impact Analysis & Gap Detection

This is where the AI earns its keep. For every relevant publication, the system generates an impact analysis:

What it produces:

• •Plain-language summary — What the regulation says, in 2–3 paragraphs that a non-lawyer can understand
• •Specific requirements extracted — Each obligation pulled out as a discrete item: "Firms must implement [X] by [date]", "Reports must be filed [frequency] to [authority]"
• •Affected business areas — Which products, processes, teams, and systems are impacted
• •Gap analysis — Maps each requirement against the company's existing policies and procedures. "Your current Transaction Monitoring Policy (v4.2, last updated March 2025) addresses requirement 3.1 but does not cover requirement 3.4 (enhanced monitoring for crypto-related transactions)"
• •Cross-jurisdiction comparison — "This requirement is similar to UK FCA PS 22/4, which you already comply with. Key differences: [specific differences]"
• •Action items — What needs to happen, by when, who should own it, and priority level (critical/high/medium/low)
• •Source citations — Every statement references the specific paragraph, page, and section of the regulation

The gap analysis requires the system to know the company's current policies. We ingested every policy document, procedure manual, board report, and compliance framework into the RAG system. When the LLM says "your AML policy doesn't cover X" — it's making that statement after reading the actual AML policy, not guessing.

The first time we ran a full gap analysis against all active regulations, the system found 23 gaps that the compliance team hadn't identified. Seven were critical — regulatory requirements that the company was not meeting and hadn't noticed. Three of those were in Middle East regulations that the Dubai team had flagged as "not applicable" based on the title alone. One was a SAMA requirement about transaction reporting thresholds that applied specifically to B2B payment service providers — a category that didn't exist in the original SAMA framework and was added in an amendment 4 months earlier.

The CCO's reaction: "Three of these could have been examination findings. One of them could have been a license condition." That was the moment the project went from "useful tool" to "critical infrastructure."

Step 4: Living Policy Map

Regulations don't exist in isolation and neither do policies. The system maintains a structured, bidirectional map:

• •Regulation → Policies: "EU PSD2 Article 97 (Strong Customer Authentication) is addressed by: Authentication Policy v3.1, Customer Onboarding Procedure v2.4, and Technical Security Standard v1.8"
• •Policy → Regulations: "Our AML Policy v4.2 satisfies: EU AMLD6 Articles 8–11, UK MLR 2017 Regulations 18–21, FinCEN BSA requirements 31 CFR 1010.310–312, CBUAE AML Circular 2024/C3 Sections 4–7"

When a regulation changes, the system immediately identifies which policies need updating. When a policy is modified, the system verifies it still satisfies all mapped regulations.

This solved a problem they'd had for years: policy documents that were "compliant when written" but had drifted out of compliance as regulations evolved. Their Customer Due Diligence policy was last updated 14 months ago. In that time, the UK had tightened beneficial ownership requirements, the EU had added crypto-asset service providers to the CDD scope, and CBUAE had introduced risk-based CDD tiers. The policy satisfied none of these updates. Nobody had noticed because nobody was tracking the mapping.

Step 5: Compliance Calendar

Every regulation comes with deadlines — implementation dates, reporting periods, filing due dates, examination schedules. The system automatically extracts these and builds a unified compliance calendar.

The calendar shows:

• •Upcoming deadlines — filings, reports, implementation milestones
• •Cascading reminders — 90, 60, 30, 15, and 5 days before each deadline
• •Per-jurisdiction view — "What's due in the UK this month?"
• •Consolidated view — "What's due everywhere this month?"
• •Owner assignment — each deadline assigned to a specific team member
• •Evidence tracking — has the required submission/report/policy update been completed?

Before this, deadlines lived in individual calendars, sticky notes, and one shared Excel file that was perpetually out of date. They'd missed two filing deadlines in the previous year — one FinCEN BSA filing (resulted in a formal warning) and one CBUAE periodic report (resulted in a ₹15,000 administrative fee — small, but embarrassing).

Step 6: Audit Preparation Engine

When a regulator announces an examination, the system generates an evidence package:

1. •Identifies the regulatory framework the examiner will likely test against (based on the examination scope letter and historical patterns)
2. •For each requirement in that framework, locates: the relevant company policy, the procedure document, evidence of implementation (training records, system logs, sample files), and the last review/update date
3. •Flags gaps: "No evidence found for requirement 4.3 — enhanced due diligence for PEPs. Your EDD policy exists but no sample case files are in the evidence repository"
4. •Generates a draft "regulatory return" or "compliance attestation" based on the evidence collected
5. •Produces a readiness score: "78% ready — 12 items need attention before examination"

What took 4–6 weeks of scavenger hunting now takes 3–5 days — mostly the time needed to fill gaps that the system identifies, not the time spent finding things.

Step 7: Regulatory Q&A

At any point, the compliance team can ask questions:

• •"Does the new DORA regulation require us to have a dedicated ICT risk management function, or can it be part of our existing operational risk team?"
• •"What are the key differences between EU and UK beneficial ownership requirements as of today?"
• •"If we launch a remittance product in Saudi Arabia, what additional SAMA approvals do we need?"
• •"Has FATF issued any new guidance on virtual asset service providers since our last policy update?"

The system answers using RAG over the full regulatory corpus (every publication it's ever ingested) plus the company's policy documents. Every answer includes citations — specific regulation, specific section, specific paragraph. The compliance team can click through to the source text and verify.

Usage is heavy — about 15–20 questions per day across the team. The most common: "does [new regulation] apply to us?" and "what's the difference between [jurisdiction A] and [jurisdiction B] on [specific topic]?"

Step 8: Cross-Jurisdiction Intelligence

This is the feature that's genuinely unique. The system understands that regulations across jurisdictions are related — and where they diverge.

Regulatory convergence tracking: When the EU updates its AML directive, the system automatically checks: Has the UK's MLR been updated similarly? Is there now a gap between UK and EU requirements? Do the company's policies need jurisdiction-specific versions?

Conflict detection: "Your UAE entity processes transactions that touch EU counterparties. The CBUAE permits [specific practice] but EU AMLD6 prohibits it for transactions involving EU persons. Your current process doesn't distinguish — risk of EU regulatory breach."

Regulatory cascade alerts: When FATF (the global standard-setter) issues new guidance, the system predicts which national regulators will implement it: "FATF updated Recommendation 16 on wire transfers. Based on historical patterns, expect: FCA implementation within 6 months, EU directive amendment within 12–18 months, CBUAE circular within 3–6 months, SAMA adoption within 6–12 months. Begin gap analysis against your current wire transfer procedures now."

This kind of cross-jurisdictional thinking was previously only available from expensive law firms charging $800/hour. The system does it continuously, for every regulation, automatically.

From 800+ monthly publications down to actionable intelligence. The AI layer sits between the regulatory noise and the compliance team's judgment.

Technical stack (for the engineering-minded)▾

• •Scrapers: Playwright-based headless browsers for regulatory websites. Each of the 18 sources has its own scraper — the FCA has a clean site with RSS feeds, CBUAE uploads PDFs with no consistent naming, SAMA publishes in Arabic first. Scraping schedules: hourly for high-volume sources (SEC EDGAR, FCA, EBA), every 4 hours for others. Total new documents ingested: ~30/day average, with spikes around regulatory calendar dates (quarter-end, year-end).
• •Document processing: PyMuPDF for PDF extraction (regulatory PDFs are notoriously complex — multi-column, footnotes, cross-references, tables spanning pages). Custom handling for amendment documents — diffing against the original to extract "what changed." HTML extraction with BeautifulSoup for web-published content. DOCX handling for consultation papers.
• •Translation: Claude for legal translation (German, French, Arabic → English). We chose LLM translation over machine translation (Google/DeepL) because regulatory terms have precise legal meanings — "Sorgfaltspflichten" in BaFin German is not just "due diligence" but "due diligence obligations" with a specific legal weight. The LLM preserves these distinctions better than generic MT. Translation quality verified by bilingual compliance analysts during the first 3 months.
• •LLM pipeline: Claude for relevance classification, impact analysis, gap detection, and Q&A (chosen for superior performance on long regulatory documents — some are 200+ pages). GPT-4o for structured extraction tasks (pulling specific requirements into a schema: obligation, deadline, affected entities, penalty for non-compliance). Prompt chains: classify → extract requirements → map to policies → identify gaps → generate action items. Each step is a separate call with the previous step's output as context.
• •RAG: Weaviate vector database. Regulatory text + company policies indexed with 2000-token chunks (larger than typical — legal text needs more context per chunk to preserve meaning around specific clauses). Hybrid search: semantic + BM25 keyword (regulatory text uses very specific terminology that pure semantic search misses — "Section 31 CFR 1010.310" needs exact matching). Metadata filtering by jurisdiction, document type, date range.
• •Backend: FastAPI (Python 3.12), async throughout. PostgreSQL for structured data (policies, action items, deadline calendar, gap records, audit evidence tracking). Redis for caching frequently accessed regulatory summaries. Celery for background scraping jobs, translation, and LLM analysis pipelines.
• •Frontend: React 18 + TypeScript. Dashboard views: regulatory feed (filterable by jurisdiction, topic, relevance), policy map (interactive graph visualization), compliance calendar (Gantt-style with deadline countdown), Q&A chat interface, audit preparation workflow with evidence checklist. Role-based views: CCO sees everything, regional compliance officers see their jurisdiction + cross-border items.
• •Amendment tracking: Custom diffing engine that compares new regulation versions against the base text. Uses LLM to generate human-readable change summaries: "Paragraph 4.3.1 — beneficial ownership threshold changed from 25% to 10% for high-risk entities." Tracks a version history per regulation — the system knows exactly which version the company's current policies were built against.
• •Monitoring & alerting: Scraper health monitoring — if a regulatory website changes structure (happened 3 times in 8 months), the scraper fails gracefully and alerts the engineering team. LLM classification confidence tracking — low-confidence classifications are flagged for human review. Daily digest emails to compliance team: new publications, new action items, upcoming deadlines. Critical alerts (new regulation with <30 days to comply) sent via Slack and SMS.
• •Infrastructure: AWS — ECS for services, RDS for PostgreSQL, S3 for raw regulatory documents and evidence files, CloudWatch for monitoring. LLM API costs: ~$2,800/month (the main cost driver — each regulatory document gets multiple LLM passes: translation, classification, analysis, gap detection). Total infra cost: ~$3,500/month.
• •Security: All data encrypted at rest and in transit. Role-based access control per jurisdiction and policy area. Audit log on every access to policy documents and regulatory analysis. SOC 2 Type II compliant — the client required it because the system handles regulatory and compliance data.

---

How We Rolled It Out

Months 1–2: Building the ingestion machine. We started with the 6 regulatory sources that generated the most volume and risk: FCA, EBA, FinCEN, CBUAE, BaFin, and FATF. Each scraper took 3–5 days to build and stabilize. The FCA was easy — structured website, RSS feeds, clean HTML. CBUAE was the hardest — PDFs uploaded to a page with no date sorting, no consistent naming, and occasional duplicate uploads of the same circular with minor formatting changes that we had to detect and deduplicate.

The Arabic translation took more work than we expected. Legal Arabic is a specialized register — even native speakers who aren't lawyers struggle with it. The LLM handled it well for CBUAE circulars (relatively modern Arabic) but struggled with SAMA publications (more formal, classical-influenced legal style). We added a specialized prompt with a legal Arabic glossary of 200+ terms and their precise English equivalents. Translation quality went from "usable but awkward" to "accurate and natural" over about 4 weeks of iteration.

By the end of month 2, we had 6 sources live and had ingested 8 months of historical publications — about 3,200 documents — to build the RAG corpus.

Month 3: Relevance engine and company profile. This was the make-or-break phase. The relevance classification needed to be good enough that the compliance team could trust the system's "not relevant" judgments. If they had to manually verify every classification, we'd just be adding work, not removing it.

We built the company profile document — 15 pages describing every business line, product, license, customer type, and jurisdiction. Fed it to the LLM as context for every classification decision. Then we ran the model against 3,200 historical documents and compared its classifications to the compliance team's own assessments.

First pass accuracy: 81%. Not good enough. The main failure mode: regulations that affected them indirectly (through banking partners, technology providers, or market infrastructure) were being classified as "not relevant." We added a secondary prompt: "Consider indirect impacts — would this regulation affect the company's counterparties, service providers, or market infrastructure in ways that create obligations or risks for the company?" Accuracy went to 89%. After a third round of prompt tuning and adding edge-case examples: 93%.

The remaining 7% are genuinely ambiguous — the kind of cases where two compliance lawyers would disagree. We handle these with the "potentially relevant" bucket and human review.

Months 4–5: Impact analysis, gap detection, and the remaining 12 sources. Added the remaining regulatory sources (state regulators, AMF, DNB, DFSA, ADGM, SAMA, OFAC, EU Official Journal, UN sanctions). Built the impact analysis pipeline — the part that reads a relevant regulation, extracts requirements, and maps them to existing policies.

The gap detection was the highest-stakes component. We ingested every company policy document (47 policies, 230 procedure documents, 15 framework documents). The LLM had to compare regulatory requirements against these policies and identify gaps — places where the policy didn't address a regulatory requirement.

We tested this by having the compliance team run a gap analysis on 5 recent regulations, then independently running the AI's analysis. The team found 18 gaps across the 5 regulations. The AI found 23. The 5 additional gaps the AI found were all real — requirements that the human analysis had missed because they were embedded in subordinate clauses or cross-referenced from other parts of the regulation. The team didn't find any gaps that the AI missed.

That test was the turning point for adoption. The CCO started forwarding AI gap reports directly to the board compliance committee.

Months 6–7: Calendar, audit prep, and cross-jurisdiction intelligence. The compliance calendar was relatively straightforward — extract deadlines from regulations and track them. The audit preparation engine required more work — we needed to integrate with SharePoint (policy documents), the HR system (training records), the AML platform (transaction monitoring logs), and email (board committee meeting minutes) to build evidence packages automatically.

The cross-jurisdiction intelligence feature was the last major build. This required the LLM to understand that a UK regulation and an EU regulation might address the same underlying FATF recommendation, but with different implementation details. We built a "regulatory lineage" layer — tracking which national regulations implement which international standards. When a standard changes at the FATF level, the system traces the cascade to every national implementation and flags divergences.

Month 8: Stabilization and trust-building. The last month was about building the compliance team's confidence. We ran every new publication through the system and through the team's manual process in parallel. After 4 weeks of consistent results (the AI caught 3 relevant publications that the team missed; the team caught 1 that the AI missed), the CCO authorized the team to rely on the system as the primary monitoring tool, with human verification only for the "potentially relevant" bucket.

---

What Changed

Six months after the system became the primary compliance monitoring tool:

The $400K they still spend on external counsel is for genuinely complex legal opinions — "should we restructure our UAE entity to avoid this cross-border conflict?" — not for "tell us what regulations came out this month." The expensive lawyers now do expensive-lawyer work instead of expensive-monitoring work.

The team dynamic shifted. The London compliance officers used to spend Monday mornings reading FCA publications from the previous week. Now they spend Monday mornings reviewing the AI's analysis of FCA publications and deciding what to do about the gaps it found. The Dubai team — who had the hardest job because UAE and Saudi regulations were changing fastest — went from perpetually behind to actually ahead. When CBUAE issued a new payment services circular in October, the AI had an impact analysis ready before the team's morning standup. The Dubai compliance lead sent the analysis to the CCO with the message: "The system flagged this at 6am. We need to update three policies. Here's the plan." That used to be a 2-week process.

The cross-jurisdiction feature had an impact nobody predicted. The EU started working on PSD3 (the update to the payments directive). The system tracked the consultation papers, mapped the proposed changes against the company's current PSD2 compliance, and flagged: "15 requirements will change when PSD3 is finalized. 8 of these diverge from the UK's current Payment Services Regulations, which are still based on PSD2. Your policies will need jurisdiction-specific versions." The compliance team started preparing 18 months early. Previously, they'd have started 6 months before the deadline — or less.

One thing we got wrong: consultation papers. These are draft regulations — regulators publish them, solicit feedback, and may or may not finalize them. Early on, the system treated consultation papers with the same urgency as final regulations, generating gap analyses and action items for rules that might never take effect. The compliance team was getting action fatigue. We adjusted: consultation papers now get a lighter analysis ("here's what this would mean if finalized") and only trigger full gap detection when the regulation moves to final/adopted status.

Another thing: the amendment diffing system sometimes misses context. When a regulator amends "Section 4.3.1" and the AI reports the change, it shows the new text but doesn't always capture why the change was made — the regulatory intent behind the modification. The compliance team still needs to read the explanatory notes and policy statements to understand the "why." The system gives them the "what" instantly; the "why" still takes human judgment.

"I've been in compliance for 18 years, across three firms and two continents. Every compliance team I've ever worked on operates the same way — smart people reading as fast as they can and hoping they don't miss the one circular that matters. This is the first time I've run a team that actually knows, with confidence, that we've read everything. The gap analysis is what I'd pay for on its own — it found 7 gaps in our policies that we'd been carrying for months without knowing. But the cross-jurisdiction tracking is what keeps me up at night in a good way. When PSD3 hits, we'll be ready. That's never happened before." — Chief Compliance Officer (name withheld at client's request)

---

What's Next

The system covers regulatory monitoring and gap detection well. But compliance is bigger than monitoring:

1. •

   Automated policy drafting — Right now, the system identifies gaps but a lawyer has to write the policy update. The next step: the AI drafts policy language that addresses the regulatory requirement, in the company's existing policy format and tone. A lawyer reviews and approves instead of writing from scratch. Early prototypes are promising but not reliable enough yet — regulatory language needs precision that the LLM sometimes approximates rather than nails.

2. •

   Enforcement action intelligence — Regulators publish enforcement actions (fines, sanctions, license revocations) against other companies. These are goldmines of "what the regulator actually cares about" — far more useful than the regulations themselves. We're building analysis that reads enforcement actions and maps the violations to the company's own policies: "The FCA fined Company X for inadequate PEP screening. Your PEP screening process has [similarity/difference] to what was found deficient."

3. •

   Regulatory change prediction — FATF issues guidance → national regulators implement it 6–18 months later. Can the system predict implementation timelines based on historical patterns? Early data suggests yes — with wide confidence intervals. "70% likely that the UK will implement this FATF recommendation within 8–14 months." Useful for planning, even if imprecise.

4. •

   Client regulatory intelligence — Their clients (the businesses using their payment services) also have compliance obligations. The company is exploring offering a simplified version of the monitoring tool to enterprise clients as a value-added service. Different business model, same infrastructure.

---

Built by GammaEdge. If your compliance team is reading as fast as they can and still falling behind — across one jurisdiction or twenty — we should talk.