This article is a complete, worked Fundamental Rights Impact Assessment for a fictional mid-sized EU bank deploying an AI agent that triages anti-money-laundering (AML) transaction-monitoring alerts. It fills in every section of our FRIA template: deployer context and purpose, duration and frequency, categories of affected persons, a right-by-right risk register, human-oversight measures, measures if risks materialise, and a review cadence with concrete update triggers. One scope finding is stated up front and documented inside the assessment: AML alert triage is not an Annex III point 5(b) or 5(c) use under Article 27 of the EU AI Act, so a private commercial bank typically completes this FRIA as governance practice rather than under a mandatory duty. Every institution and figure in the example is fictional. You can download the completed example as Markdown, or draft your own assessment with the free FRIA generator.
Does Article 27 bind an AML alert-triage deployer?
Start with the honest scope answer, because a defensible FRIA records it. Article 27(1) requires a fundamental rights impact assessment from two groups of deployers: public bodies and private entities providing public services deploying Annex III high-risk systems, and every deployer of the systems in Annex III points 5(b) and 5(c): creditworthiness or credit scoring, and life and health insurance pricing. Point 5(b) also expressly excepts AI used to detect financial fraud.
An AML alert-triage agent at a private commercial bank fits neither group. Triage of transaction-monitoring alerts is absent from the Annex III list, and a commercial bank is neither a public body nor, on the prevailing reading, a private entity providing public services. The mandatory duty, where it applies, follows the Annex III high-risk date of 2 December 2027, set by the Digital Omnibus on AI (Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026).
The fictional bank in this worked example completes the assessment anyway, for three recorded reasons. Its group AI policy applies the Article 27(1) structure to every high-impact agent deployment, because the structure is the most complete rights-analysis instrument EU law currently offers. The bank owes a GDPR Article 35 DPIA for the processing in any case, and the FRIA extends that DPIA to Charter rights a DPIA leaves out, mirroring the complement mechanism in Article 27(4). And the classification is not static: reclassification guidance, a change in the agent’s role, or deployment by a group entity that is a public body would each pull the system into mandatory scope, so the bank keeps the document current rather than starting from zero later.
| Question | Finding |
|---|---|
| High-risk under Article 6(2) / Annex III? | Not on the current classification. AML alert triage is absent from Annex III; point 5(b) covers creditworthiness and excepts fraud detection. |
| Public body or private entity providing public services? | No. The deployer is a private commercial bank. |
| FRIA mandatory under Article 27? | Not on this classification. Performed under group AI policy using the Article 27(1) structure; revisited on any classification change. |
| GDPR Article 35 DPIA required? | Yes: systematic evaluation of personal aspects of customers at scale. This FRIA complements it. |
Section 1: Deployer context and intended purpose (Art 27(1)(a))
The deployer is a fictional mid-sized EU retail and commercial bank with about 1.8 million customers across three member states. The system is the "Triage Assist" alert-triage agent, v1.4, from the fictional vendor Meridian Analytics GmbH, running inside the bank’s governed agent-execution platform.
Its intended purpose is narrow and written down: enrich each transaction-monitoring alert with KYC, transaction-history, screening, and adverse-media context; summarise the case; propose one of three dispositions (close as non-suspicious, request information, escalate for investigation); and draft the escalation rationale for the analyst. The agent sits between the rules-based monitoring engine that raises alerts and the human analyst who decides them.
The purpose statement also fixes what the agent may never do, and the deployment enforces those limits at runtime rather than in prose. 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, enforced by a runtime policy engine whose four outcomes are allow, warn, require_approval, and block, with every action written to a sealed evidence record. The full control design for this workflow, including the permitted-action and escalation tables, is in AML alert-triage agents: controls and evidence.
Section 2: Duration and frequency of use (Art 27(1)(b))
The assessment records production use from 1 October 2026 after a 12-week supervised pilot, for an indefinite duration subject to the review cadence in the final section. Use is continuous: the agent processes each alert on arrival, roughly 4,200 alerts a week and about 220,000 a year, across the bank’s three EU markets, with all processing inside the bank’s EU data boundary.
Volume is a rights fact, and it belongs in this section. At 220,000 alerts a year, a bias that shifts escalation rates by a single percentage point touches thousands of customers, which is why the risk register in Section 4 rates discrimination harms by scale as well as severity.
Section 3: Categories of affected persons (Art 27(1)(c))
The primary affected group is alert subjects: retail and SME customers whose transactions trip the monitoring engine. Counterparties named in transaction data, including people who are not the bank’s customers, form a second group.
The assessment gives particular attention to customers whose ordinary 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 together with their family members. These are the groups on which AML de-risking pressure historically concentrates, so they are the groups a triage agent is most likely to over-escalate.
Two further groups round out the section. Triage analysts are affected persons too: the agent shapes their work and produces metrics about it, so automation bias, deskilling, and workload surveillance are assessed. And joint account holders and dependants are indirectly affected when an account is restricted or exited following escalation.
Section 4: The risk register, right by right (Art 27(1)(d))
Section 4 carries the weight of the assessment. Each row names the fundamental right at stake, a specific harm scenario, a likelihood and severity rating from a consistent matrix, the mitigation, and the residual risk after mitigation. Rights are assessed one by one; a benefit to one right never offsets a harm to another. The ratings below are the fictional bank’s sample assessment: they illustrate a defensible method, and no regulator prescribes the specific values.
| 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; remittance-heavy customers are escalated at disproportionate rates, feeding account reviews, restrictions, and de-risking exits. | Possible | Major | High | Quarterly disparate-impact testing of escalation and restriction rates by corridor and segment; proxy-feature audit; rationales citing only origin-linked features are policy-blocked; maker-checker on every escalation. | Medium |
| Personal data (Charter Art 8) | The agent aggregates transaction, KYC, adverse-media, and screening data; over-collection or unverified adverse-media matches contaminate the case record. | Possible | Moderate | Medium | Least-privilege data scope per tool; field-level retrieval logging in evidence records; adverse-media matches marked unverified until analyst confirmation; DPIA integration. | Low |
| Private and family life (Charter Art 7) | An erroneous escalation triggers intrusive information requests or restrictions that disrupt salary, rent, and family remittance payments. | Unlikely | Major | Medium | No customer-impacting step without second-analyst approval; restrictions stay with the financial-crime committee, are time-bound, and carry a documented reinstatement path. | Low |
| Effective remedy (Charter Art 47) | The customer cannot learn of or contest the pattern behind repeated friction; tipping-off rules limit what the bank may disclose about suspicion. | Possible | Moderate | Medium | Independent complaints route; every agent contribution to a disposition reconstructable from sealed evidence records for internal review, the DPO, and supervisors. | Medium |
| Presumption of innocence (Charter Art 48) | Agent summaries frame ambiguous activity as suspicious; automation bias turns a proposed escalation into the default outcome. | Possible | Moderate | Medium | Summaries separate observed facts from inference with sources; analysts record independent rationales; agreement-rate monitoring; blind re-review of samples. | Low |
| Rights of the child (Charter Art 24) | Minor-linked accounts enter triage; restrictions affect funds a child depends on. | Rare | Major | Medium | Minor-linked alerts always route to a senior analyst; the only permitted proposal is escalation for human review. | Low |
Scoring the register: likelihood × severity
The risk levels come from the same likelihood-by-severity matrix the FRIA template uses, applied consistently across the whole document. Record the matrix and the reasoning behind each rating; the method matters to a reviewer as much as the conclusions.
| Likelihood / Severity | Negligible | Minor | Moderate | Major | Catastrophic |
|---|---|---|---|---|---|
| Rare | Low | Low | Low | Medium | Medium |
| Unlikely | Low | Low | Medium | Medium | High |
| Possible | Low | Medium | Medium | High | High |
| Likely | Medium | Medium | High | High | Critical |
| Almost certain | Medium | High | High | Critical | Critical |
Section 5: Human oversight through runtime controls (Art 27(1)(e))
The oversight section names its owner: the Head of Financial Crime Operations, deputised to two senior AML officers. What makes this section credible is that each oversight promise corresponds to a control that executes when the agent acts.
Maker-checker approval. Every escalation, information request, and restriction proposal requires approval by a second qualified analyst. The runtime policy engine returns a require_approval decision for these actions, and the evidence record captures the approver, timestamp, and rationale. A FRIA that lists maker-checker as a mitigation is testable in one query against those records.
Escalation thresholds. Alerts above the high-risk score threshold, or involving politically exposed persons, prior suspicious-activity history, or high-risk corridors, are barred from any close proposal and routed to senior review. The threshold values live in a versioned policy pack, so the FRIA can cite the exact rule in force.
Intervention and the kill switch. Analysts can override any proposal. The oversight owner can suspend the agent instantly, reverting the process to the pre-agent manual procedure. Analysts complete training on the agent’s capabilities, failure modes, and automation bias before access, refreshed annually.
Oversight of oversight. Override rates, agreement rates, and time-per-alert are reviewed monthly to catch rubber-stamping and workload pressure, the two quiet ways human oversight decays.
Section 6: Measures if risks materialise (Art 27(1)(f))
A disparate-impact breach or a blind re-review finding opens a model-risk incident; the financial-crime committee decides between threshold changes, feature removal, retraining, and suspension. Customer complaints touching triaged alerts are flagged to the DPO and the oversight owner, and the sealed evidence record for the case is pulled for review.
Rollback is concrete because everything is versioned: agent version, prompts, and policy pack. Alerts triaged under a defective version are identifiable from evidence records and re-reviewed. Wrongly applied restrictions are lifted with documented reinstatement, and fees plus demonstrable direct losses are refunded under the bank’s existing redress policy.
On notification: an in-scope deployer must notify the market surveillance authority of FRIA results under Article 27(3). The fictional bank sits outside that duty, so it reports material incidents through its existing supervisory channels and keeps the FRIA available to supervisors on request.
Section 7: Review cadence and update triggers
Article 27(2) requires an in-scope deployer to update the assessment when any assessed element changes or is no longer current, and the fictional bank adopts the same discipline. The scheduled review runs every 12 months and at every annual model validation of the monitoring engine.
Event triggers force an earlier review: a new agent version or policy-pack release, an alert-volume change above 25%, entry into a new market or segment, a disparate-impact test breach, a supervisory finding, reclassification guidance affecting AML systems, and publication of the Article 27(5) AI Office template, at which point the assessment is restated on the official template. Each review appends to the document, and superseded versions are retained under the bank’s retention schedule.
Download the completed example and build your own
The completed example is a single Markdown document carrying everything above in full: the Section 0 applicability analysis, all six Article 27(1)-structure sections, the unabridged risk register, and a fictional sign-off block. It pairs with the blank FRIA template from the template guide.
To draft an assessment for your own deployment, the free FRIA generator fills the same structure in your browser and exports Markdown or JSON. French deployers should read it alongside the CNIL guidance walkthrough; credit-scoring and insurance deployers, who carry the mandatory Article 27 duty, have their own worked examples in the credit-scoring FRIA and the insurance FRIA.
The reason this FRIA reads as verifiable is that its oversight section describes controls that run at execution time: policy decisions with four outcomes, maker-checker approvals, and sealed evidence records. That runtime layer is what KLA provides, and the AML alert-triage controls guide documents it end to end.
Frequently Asked Questions
Is a FRIA mandatory for an AML alert-triage agent?
Typically no, for a private commercial bank. Article 27 binds public bodies and private entities providing public services deploying Annex III high-risk systems, plus all deployers of Annex III point 5(b) credit-scoring and 5(c) life and health insurance pricing systems. AML alert triage appears in none of those categories, and point 5(b) expressly excepts AI used to detect financial fraud. Many banks complete the assessment anyway under internal AI governance policy, and the worked example records exactly that scope analysis in its Section 0.
Why complete a FRIA that the law does not require?
Three recorded reasons in the example: the Article 27(1) structure is the most complete rights-analysis instrument available for an agent deployment; the bank owes a GDPR Article 35 DPIA for the processing anyway, and the FRIA extends it to Charter rights a DPIA leaves out; and the classification can change through guidance, a changed agent role, or deployment by an in-scope group entity, at which point a current assessment already exists.
Which fundamental rights does an AML triage agent put at stake?
The worked register assesses non-discrimination (Charter Article 21, the dominant risk, driven by corridor and occupation proxies and de-risking), protection of personal data (Article 8), private and family life (Article 7), effective remedy (Article 47), the presumption of innocence (Article 48), and rights of the child (Article 24). Each right is assessed independently, and no positive impact on one right offsets a harm to another.
What runtime controls does the example rely on as mitigations?
Maker-checker approval on every escalation, information request, and restriction proposal; policy-enforced escalation thresholds for high scores, politically exposed persons, prior suspicious-activity history, and high-risk corridors; a block on close proposals for those alerts; an instant kill switch; and sealed evidence records that capture every agent action, policy decision, approver, and rationale so each mitigation is testable against the record.
How often is the assessment reviewed?
Every 12 months and at every annual model validation, plus event triggers: a new agent version or policy-pack release, an alert-volume change above 25%, a new market or segment, a disparate-impact breach, a supervisory finding, reclassification guidance, and publication of the official Article 27(5) template.
Is the bank in the example real?
No. The bank, the vendor, the system name, the volumes, and the sign-off are all fictional, constructed to make the worked example concrete. The legal analysis cites the real EU AI Act provisions, and the download states its fictional status on the first page.
When does the mandatory FRIA duty apply for in-scope deployers?
From 2 December 2027 for stand-alone Annex III high-risk systems. The Digital Omnibus on AI, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force since 27 July 2026, moved that date from 2 August 2026. The content of the Article 27 obligation is unchanged.
Can this example be reused for a fraud-detection or sanctions-screening agent?
The structure transfers directly: applicability analysis, the six Article 27(1)-style sections, a right-by-right register, and runtime-control mitigations. The scope analysis differs per use: point 5(b) expressly excepts fraud detection from the credit-scoring category, and each use needs its own affected-person mapping and register. The FRIA generator drafts the structure for any system description.
Key Takeaways
A completed FRIA for an AML alert-triage agent looks like this: an honest applicability analysis first, six filled sections in the Article 27(1) structure, a right-by-right risk register dominated by non-discrimination and de-risking harm, oversight measures that name owners and execute as runtime controls, concrete measures for when risks materialise, and a review cadence with event triggers. Download the completed example, start from the blank template, or draft your own with the free FRIA generator. This article is for general information only and is not legal advice; the deployer, vendor, and figures in the example are fictional; confirm your obligations under Article 27 with qualified counsel, and re-check the regulatory status before relying on any deadline.