EU AI Act Article 86 vs ECOA Adverse Action Notices: Explanation Duties Compared

Two explanation duties that are not equivalents

Compliance teams often group Article 86 of the EU AI Act and the ECOA adverse action requirements under one heading called AI explainability. That grouping hides real differences. Each duty answers a different question, is owed by a differently defined party, and is satisfied by different content.

Article 86 gives any affected person who is subject to a decision taken by a deployer, on the basis of the output of a high-risk AI system listed in Annex III, the right to obtain clear and meaningful explanations from the deployer. The explanation covers the role of the AI system in the decision-making procedure and the main elements of the decision taken. The decision must produce legal effects or similarly significantly affect the person in a way they consider to have an adverse impact on their health, safety or fundamental rights. Systems listed under point 2 of Annex III are excluded.

Regulation B, at 12 CFR 1002.9, implements ECOA. It requires a creditor to notify an applicant in writing of adverse action within set periods. The notice must give specific reasons or disclose the right to request them. CFPB Circulars 2022-03 and 2023-03 add that the requirements apply regardless of the technology used, and that the reasons must be specific and accurate. The regulatory status described here is as of November 2026.

Side-by-side comparison

The table sets the two duties against the dimensions compliance teams most often need to separate.

• Legal basis: Article 86 of Regulation (EU) 2024/1689, with related recitals. ECOA, implemented by Regulation B (12 CFR 1002.9), read with CFPB Circulars 2022-03 and 2023-03.
• Scope and trigger: Article 86: a deployer's decision based on the output of an Annex III high-risk system that has legal or similarly significant adverse effects. Regulation B: adverse action on an application or an existing account.
• Who owes the duty, who receives it: Article 86: the deployer owes it to the affected person. Regulation B: the creditor owes it to the applicant.
• Required content: Article 86: the role of the AI system in the decision-making procedure and the main elements of the decision. Regulation B: action taken, creditor name and address, ECOA section 701(a) statement, the administering agency, and specific reasons or the right to request them.
• Form and timing: Article 86 is framed as a right to obtain an explanation. Regulation B requires a written notice, generally within 30 days of a completed application, 30 days after adverse action on an incomplete application or existing account, and 90 days after a counteroffer that is not accepted or used.
• Exceptions and limits: Article 86 excludes systems listed under point 2 of Annex III. For Regulation B, Circular 2022-03 states there is no technology exception, and complex algorithms may not be used if specific and accurate reasons cannot be given.

Where the duties overlap and where they diverge

The overlap is practical rather than legal. Both duties apply to decisions that adversely affect an individual, both place the obligation on the organization that makes the decision, and both are hard to meet if the organization cannot reconstruct what happened in a given decision. An organization subject to both regimes may be able to reuse underlying records, but not a single explanation text.

The divergence is in what is being explained. Article 86 centres on the system's role and the main elements of the decision. Regulation B and Circular 2023-03 centre on the principal reasons, which must relate to and accurately describe the factors actually considered or scored by the creditor. A narrative about how the AI system fit into the procedure does not substitute for accurate principal reasons, and a reason code does not describe the system's role.

The delivery model also differs. The Regulation B notice is mandated and written, with required fields and fixed periods. Article 86 is a right the affected person exercises, which means a deployer needs an intake and response process, not only a template. One recital also states that deployers should inform natural persons of their right to an explanation, so awareness of the right is part of the picture.

There is a wording point to note. Recital 171 refers to decisions based mainly upon the output of certain high-risk systems, while Article 86 refers to decisions taken on the basis of that output. Teams should not assume the two phrases set the same threshold. Whether a particular credit use case falls within Annex III, and outside point 2, is a classification question to confirm with counsel before Article 86 is assumed to apply or not apply.

What each explanation depends on: records of what the AI was allowed to do and did

Neither duty lists the records an organization must keep. The evidence requirements follow from what each explanation must say.

For Regulation B, Circular 2023-03 requires reasons to match the factors actually considered or scored. Substantiating a notice therefore needs a per-decision record of those factors, not a generic reason list. The circular also says creditors may not rely on the sample-form checklist if the listed reasons do not specifically and accurately indicate the principal reasons. A reason-code review step that checks the stated reasons against the decision record is a reasonable control.

For Article 86, the explanation must describe the AI system's role. Substantiation would need records showing the system's output and how the deployer used it in the decision procedure, including whether a person or an automated step produced the final decision. This is an inference from the text, not a listed requirement.

In both cases the records need to be retrievable by decision or applicant identifier, so a notice or an explanation request can be answered in the applicable period. A useful test is whether the organization can show, for one named individual, which policies applied to the AI interaction and what the system did: what it was allowed to do, and what it actually did.

Where runtime policy enforcement fits

Trussed enforces policy in the execution path of AI interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. Because enforcement happens at runtime, not after the fact, it produces continuous audit-ready evidence of which policy applied and what the system did. That evidence is mapped to the EU AI Act, among other frameworks.

This evidence can support explanation and substantiation work, particularly the question of what an AI system was allowed to do and what it did in a specific interaction. Trussed does not generate adverse action notices or Article 86 explanations, and it does not determine adverse action reasons. Those remain decisions for the creditor or deployer, their legal advisers and their model risk owners.