# Completed FRIA — AML Alert-Triage Agent (Worked Example)

**Version:** 1.0
**Last updated:** 2026-08-13
**Legal basis:** EU AI Act (Regulation (EU) 2024/1689), Article 27, as amended by Regulation (EU) 2026/1744
**Source:** KLA Digital (kla.digital/tools/fria-generator)

---

## About this document

This is a completed **Fundamental Rights Impact Assessment (FRIA)** for a **fictional** mid-sized EU bank deploying an AI agent that triages anti-money-laundering (AML) transaction-monitoring alerts. Every institution, person, system name, and figure in it is invented. It follows the six-section structure of **Article 27(1)(a)–(f)** of the EU AI Act and the blank template published at kla.digital/downloads/fria-template.md.

Scope note before reuse: an AML alert-triage system is not listed in Annex III point 5(b) (creditworthiness) or 5(c) (life and health insurance pricing), so a private commercial bank deploying one is typically outside the mandatory Article 27 duty. The fictional bank in this example completes the assessment under its own group AI policy, which applies the Article 27(1) structure to every high-impact agent deployment, and to extend the GDPR Article 35 DPIA it owes in any case. Section 0 records that scope analysis. This document is for information only and is **not legal advice**.

---

## Section 0 — Applicability analysis (recorded before the assessment)

| Question | Finding |
| --- | --- |
| Is the system high-risk under Article 6(2) / Annex III? | Not on the current classification. AML alert triage is not an Annex III listed use; Annex III 5(b) covers creditworthiness and expressly excepts fraud detection. |
| Is the deployer a public body or a private entity providing public services? | No. The deployer is a private commercial bank. |
| Is a FRIA mandatory under Article 27? | Not on this classification. The assessment is performed under group AI policy AI-POL-004, using the Article 27(1) structure, and is reviewed if the classification or guidance changes. |
| Is a GDPR Article 35 DPIA required? | Yes. Systematic evaluation of personal aspects of customers at scale. DPIA ref: DPIA-2026-031. This FRIA complements it (mirroring Article 27(4)). |

---

## Section 1 — System description and intended purpose (Art 27(1)(a))

- **AI system:** "Triage Assist" alert-triage agent, v1.4, supplied by the fictional vendor Meridian Analytics GmbH; deployed inside the bank's governed agent-execution platform.
- **Deployer:** a fictional mid-sized EU retail and commercial bank ("the bank"), ~1.8 million customers, operating in three EU member states.
- **Intended purpose:** enrich transaction-monitoring alerts, summarise case context, propose a disposition (close as non-suspicious, request information, or escalate for investigation), and draft escalation rationales for human analysts.
- **Process:** the AML transaction-monitoring alert-triage process in Financial Crime Operations. The agent acts after the rules-based monitoring engine raises an alert and before an analyst disposition.
- **Decision authority:** the agent holds no authority to close an alert, file or suppress a suspicious activity report, or contact a customer. Alert closure requires an analyst decision; escalations and any customer-impacting step require maker-checker approval by a second analyst. These boundaries are enforced at runtime by policy (allow / warn / require_approval / block) and every action is written to an evidence record.

## Section 2 — Duration and frequency of use (Art 27(1)(b))

- **Start:** production from 1 October 2026, after a 12-week supervised pilot.
- **Duration:** indefinite, subject to the review cadence in Section 7.
- **Frequency:** continuous; the agent processes each new alert on arrival.
- **Volume:** ~4,200 alerts per week (~220,000 per year) across the bank's three EU markets.
- **Geography:** EU only; processing within the bank's existing EU data boundary.

## Section 3 — Categories of affected persons (Art 27(1)(c))

- **Alert subjects:** retail and SME customers whose transactions raise alerts; the primary affected group.
- **Counterparties:** natural persons named in transaction data who are not the bank's customers.
- **Groups needing particular attention:** customers whose transaction patterns diverge from model norms for structural reasons — recent migrants and cross-border workers who remit money regularly, refugees, customers in cash-intensive occupations, customers transacting with lower-income corridor countries, and politically exposed persons and their family members.
- **Analysts:** triage analysts whose work is shaped and monitored through the agent (automation bias, deskilling, workload surveillance).
- **Indirectly affected:** joint account holders and dependants of customers whose accounts are restricted or exited following escalation.

## Section 4 — Specific risks to fundamental rights (Art 27(1)(d))

Ratings use a likelihood × severity matrix (Rare → Almost certain; Negligible → Catastrophic).

| Fundamental right | Harm scenario | Likelihood | Severity | Risk | Mitigation | Residual |
| --- | --- | --- | --- | --- | --- | --- |
| Non-discrimination (Charter Art 21) | Corridor-, nationality-, and occupation-linked features act as proxies for ethnicity or origin; alerts on remittance-heavy customers are escalated at disproportionate rates, leading to disproportionate account reviews, restrictions, and exits (de-risking). | Possible | Major | **High** | Quarterly disparate-impact testing of escalation and account-restriction rates by corridor and customer segment; proxy-feature audit of the enrichment model; escalation rationales must cite conduct, and rationales citing only origin-linked features are policy-blocked; maker-checker on every escalation. | Medium |
| Protection of personal data (Charter Art 8) | The agent aggregates transaction, KYC, adverse-media, and screening data; over-collection, retention beyond need, or inaccurate adverse-media matches contaminate the case record. | Possible | Moderate | **Medium** | Data scope pinned per tool with least-privilege connectors; retrieval logged field-by-field in evidence records; adverse-media matches marked unverified until analyst confirmation; retention per record class reconciled with legal holds; DPIA-2026-031 integration. | Low |
| Private and family life (Charter Art 7) | An erroneous escalation triggers intrusive information requests or account restrictions that disrupt salary, rent, and family remittance payments. | Unlikely | Major | **Medium** | No customer-impacting step without a second-analyst approval; restriction decisions stay with the bank's existing financial-crime committee; time-bound restrictions with automatic review; documented reinstatement path. | Low |
| Effective remedy (Charter Art 47) | The customer cannot learn of or contest the pattern behind repeated friction, and tipping-off rules limit what the bank may disclose about suspicion itself. | Possible | Moderate | **Medium** | Complaints route independent of Financial Crime Operations; every agent contribution to a disposition is reconstructable from sealed evidence records for internal review, the DPO, and supervisors; remedy operates through review of the full decision record even where AML secrecy limits disclosure to the customer. | Medium |
| Presumption of innocence / fair process (Charter Art 48) | Agent summaries frame ambiguous activity as suspicious; automation bias turns a proposed escalation into a default outcome. | Possible | Moderate | **Medium** | Summaries must separate observed facts from inference with source references; analysts record their own rationale to close or escalate; agreement-rate monitoring flags analysts who rubber-stamp; periodic blind re-review of a sample of closed and escalated alerts. | Low |
| Rights of the child (Charter Art 24) | Accounts of minors (family accounts, guardianship arrangements) enter triage; restrictions affect funds a child depends on. | Rare | Major | **Medium** | Alerts touching minor-linked accounts are always routed to a senior analyst; no automated proposal beyond "escalate for human review". | Low |

## Section 5 — Human oversight measures (Art 27(1)(e))

- **Named oversight owner:** Head of Financial Crime Operations; deputised to two senior AML officers.
- **Maker-checker:** every escalation, information request, and restriction proposal requires approval by a second qualified analyst; the runtime policy engine enforces this with a `require_approval` decision and records the approver, timestamp, and rationale.
- **Escalation thresholds:** alerts scoring above the high-risk threshold, involving politically exposed persons, prior suspicious-activity history, or high-risk corridors are barred from any close proposal and routed to senior review.
- **Intervention:** analysts can override any agent proposal; the oversight owner can suspend the agent instantly (kill switch); suspension reverts the process to the pre-agent manual procedure.
- **Competence:** analysts complete training on the agent's capabilities, failure modes, and automation bias before access; refreshed annually.
- **Oversight of oversight:** monthly review of override rates, agreement rates, and time-per-alert to detect rubber-stamping and workload pressure.

## Section 6 — Measures if risks materialise (Art 27(1)(f))

- **Internal governance:** findings from disparate-impact testing or blind re-review open a model-risk incident; the financial-crime committee decides on threshold changes, feature removal, retraining, or suspension.
- **Complaint mechanism:** customers use the bank's standard complaints channel; complaints touching triaged alerts are flagged to the DPO and the oversight owner, and the sealed evidence record for the case is retrieved for review.
- **Rollback:** the agent version, prompts, and policy pack are versioned; any version can be rolled back; alerts triaged under a defective version are identifiable from evidence records and re-reviewed.
- **Individual redress:** wrongly applied restrictions are lifted with documented reinstatement; fees and demonstrable direct losses caused by a wrongful restriction are refunded under the bank's existing redress policy.
- **Notification:** while the bank is outside the mandatory Article 27 scope, material incidents are reported through existing supervisory channels (AML supervisor, data-protection authority where a personal-data breach is involved), and the FRIA record is available to supervisors on request.

## Section 7 — Review cadence and update triggers

- **Scheduled review:** every 12 months, and at every annual model validation of the monitoring engine.
- **Event triggers:** new agent version or prompt/policy pack release; a change in alert volume of more than 25%; entry into a new market or customer segment; disparate-impact test breach; a supervisory finding; reclassification guidance affecting AML systems under the AI Act; publication of the Article 27(5) AI Office template (the assessment is then restated on that template).
- **Record:** each review appends to this document; superseded versions are retained under the bank's retention schedule.

---

## Sign-off (fictional)

| Role | Responsibility | Date |
| --- | --- | --- |
| Head of Financial Crime Operations | Assessment owner | 2026-09-14 |
| Data Protection Officer | DPIA consistency (Art 27(4) mirror) | 2026-09-14 |
| Chief Risk Officer | Approval to deploy | 2026-09-21 |

> Draft your own assessment with the interactive FRIA generator at kla.digital/tools/fria-generator, or start from the blank template at kla.digital/downloads/fria-template.md.