Regulations
An illustrative sample mapping of the fixed example cases to AMLA 2027, AMLR, AMLD6, MiCA, the Travel Rule, the EU AI Act and DORA. Framework summaries are simplified and are not legal advice.
Sample regulatory mapping — read-only. Status labels describe which frameworks are in scope for the deterministic sample data, not an achieved compliance, verification, or audit state. Decision support pending human review; not a live system, not legal advice.
Sample logic mapped to regulatory expectations
This sample shows how an elevated example case can be traced to the framework obligations it touches — grouped by regulatory framework. Every mapping here is fixed sample data for illustration, reviewed by a person, and is not a compliance determination.
AML Frameworks
AMLA 2027 · AMLR · AMLD6Anti-Money Laundering Authority — Direct Supervision Framework
AMLA is the new EU-level anti-money-laundering authority. It is to directly supervise a limited set of selected obliged entities and coordinate national supervisors, which remain responsible for most firms. (Illustrative summary — not legal advice.)
Illustrative: obliged entities are expected to keep CDD controls and beneficial ownership information current and to cooperate with their supervisor. Confirm specific duties with counsel.
In this sample, the fixed example cases are tagged with AMLA-related CDD obligations and an illustrative readiness figure. It shows the concept only; it is not an evidence package or a supervisory assessment.
Illustrates how readiness gaps could be surfaced for human review ahead of supervisory change.
EU Anti-Money Laundering Regulation — Unified CDD & Reporting Standards
The AMLR is a directly applicable EU regulation that harmonises AML/CFT rules across all Member States without national transposition, covering customer due diligence, politically exposed persons, suspicious transaction reporting, and record retention.
All obliged entities must apply unified CDD standards, PEP screening, 5-year record retention, and STR reporting procedures directly under the AMLR without national variation.
In this sample, example alerts carry a CDD reference so you can see how a signal is linked to an obligation. The links are fixed sample mappings, reviewed by a person — not an automatic reporting determination.
Illustrates tracing a case to a named obligation for review. Using ReguShield does not by itself demonstrate AMLR compliance.
Sixth AML Directive — Criminal Liability & Predicate Offences
AMLD6 extends criminal liability for money laundering to legal persons, expands predicate offences to 22 standardised categories, and strengthens cross-border judicial cooperation and sanctions regimes across Member States.
Obliged entities must reflect AMLD6 predicate offence categories in their AML monitoring logic and ensure that corporate compliance policies cover criminal liability for legal persons.
In this sample, some example cases cite a predicate-offence category as illustrative context. It is not a legal classification.
Illustrates adding legal context to an escalation for the reviewer; it is not a defence against liability.
High-Risk Factors & Cross-Border Monitoring
In the sample scenario, cross-border flows, unusual geography, customer-declared KYC status and suspicious-pattern flags raise the illustrative risk score.
Transactions involving high-risk patterns, jurisdictions, or customer anomalies should trigger enhanced monitoring and due diligence logic.
In this sample, these fields from the example records feed a deterministic score. KYC status is a value the example data asserts; nothing here verifies identity.
Illustrates how elevated exposure could be flagged for a person to review.
Suspicious Activity Reporting Readiness
Illustrative: case facts can be organized into a readable logic trail for an internal reviewer. Nothing here is filed with, or prepared for submission to, an authority.
Suspicious activity should be documented in a form that can be escalated, reviewed, and eventually turned into official reporting packages.
In this sample, each case shows a summary, a narrative and legal-basis references. Reports in the showcase are samples; any filing is prepared and submitted by authorized people.
Illustrates a consistent structure for moving from an alert to human review.
Crypto & Digital Assets
MiCA · Travel RuleMarkets in Crypto-Assets Regulation — CASP Authorisation & Whitepaper
MiCA establishes the EU regulatory framework for crypto-asset service providers and token issuers, covering CASP authorisation, whitepaper disclosure requirements, reserve requirements for stablecoins and e-money tokens, and market abuse controls.
CASPs must obtain authorisation from national competent authorities, publish compliant whitepapers for asset-referenced and e-money tokens, maintain sufficient reserves, and implement market abuse monitoring.
In this sample, the crypto example case shows reserve and custody signals mapped to MiCA topics. It is an illustrative mapping, not reserve monitoring and not a MiCA compliance status.
Illustrates how authorisation and disclosure gaps could be listed for human review.
Travel Rule & VASP Monitoring Logic
In the sample scenario, crypto example cases reference Travel Rule and VASP-oriented controls, especially for cross-border transfers.
Crypto transfers should be assessed with sender/receiver identity controls, route visibility, and operational integrity expectations.
In this sample, Travel Rule references appear on the crypto example case. This is an illustrative mapping on fixed data; nothing is monitored.
Illustrates the same obligation chain applied to a crypto example.
FATF Travel Rule (EU TFR) — Originator & Beneficiary Data
The FATF Travel Rule, implemented in the EU via the Funds Transfer Regulation (TFR), requires VASPs and PSPs to collect, verify, and transmit originator and beneficiary identification data on transfers above EUR 1,000, including unhosted wallet screening obligations.
Originator and beneficiary data must accompany transfers, VASP counterparty due diligence must be conducted, and unhosted wallet transfers must be screened for ML/TF risk.
In this sample, Travel Rule gaps on the example data appear as illustrative alerts. Nothing here tracks real transfers.
Illustrates how originator and beneficiary data gaps could be surfaced for review.
AI Governance
EU AI ActArticle 13 — Transparency & Explainability
In this sample, every elevated-risk example shows the deterministic reasons behind its score, with narrative and legal references, rather than an opaque number.
Users and regulators should be able to understand why an AI-supported compliance classification was produced and which factors materially influenced the result.
In this sample, the dashboard shows a summary, a narrative, deterministic reasoning and legal-basis references for each example case.
Illustrates explainable output that a reviewer can check.
Article 14 — Human Oversight
ReguShield is decision support, not an autonomous enforcement engine. In this sample, critical and high-risk example cases are marked for human review.
High-risk AI systems must preserve meaningful human control over consequential decisions.
In this sample, critical example cases show recommended actions and a human-review expectation; nothing is closed automatically.
Keeps the final judgment with a compliance officer.
Article 15 — Robustness, Accuracy & Traceability
In this sample, each example case can be traced back to its data points, the deterministic logic applied and the recommended actions.
A high-risk AI system should be technically robust, sufficiently accurate for its use case, and capable of post-event traceability.
In this sample, the audit trail and the case, evidence and report pages show the traceability chain on fixed example data.
Illustrates reconstructing why an example case was scored the way it was.
Operational Resilience
DORADigital Operational Resilience Act — ICT Risk & Incident Reporting
DORA (effective January 2025) requires all in-scope financial entities to implement an ICT risk management framework, report major ICT-related incidents within 4 hours, conduct Threat-Led Penetration Testing (TLPT) at least every three years, and manage ICT third-party concentration risk.
Entities must maintain a documented ICT risk management policy (Article 5), classify and report major incidents to competent authorities, and ensure third-party ICT contracts include DORA-required resilience clauses.
In this sample, DORA topics appear as illustrative mappings on the example data. ICT incident management is not currently available in the customer workspace.
Illustrates how ICT resilience obligations could be listed for review.