Why does this mapping exclude most of the original 2019 Guidelines?

The EBA amended EBA/GL/2019/04 after DORA introduced a harmonised ICT risk framework. Its report says only payment service user relationship management remains and the other parts were repealed. A current mapping should preserve those residual requirements and place broader ICT controls under DORA.

Is section 3.8 an AI regulation?

The remaining section governs payment service user relationship management rather than AI as a technology. AI becomes relevant when a provider uses an LLM to deliver security guidance, explain an update, assist with payment-control workflows, or receive security support requests. The mapped control objective stays grounded in the payment service.

What is the difference between partial and adjacent coverage?

Partial coverage means the named control performs a defined part of the objective, such as governing an AI explanation of a transaction alert. Adjacent coverage means another system performs and proves the control, such as the notification service delivering that alert. The distinction prevents duplicated credit and missing evidence.

Should DORA controls appear in the same matrix?

They can appear in the same workbook if each row names its source and scope. Keep separate views for DORA's ICT framework and the amended EBA payment-user requirements. This lets owners see shared evidence without suggesting that one instrument replaces every obligation in the other.

Which controls can an HTTP AI gateway fully cover?

A gateway can fully cover only a narrowly stated runtime objective, such as enforcing an approved model route or recording a policy decision on a routed request. It can support customer-facing guidance, communication, and triage, but cannot execute payment settings, detect transaction events, deliver notifications, approve source content, or resolve support cases.

EBA ICT Guidelines AI Controls Mapping After DORA

An EBA ICT Guidelines AI controls mapping built against the original 2019 text now starts from the wrong control universe. DORA has applied since 17 January 2025. The EBA's final amendment report says most of EBA/GL/2019/04 became obsolete in substance and retains payment service user relationship management. Its map begins at paragraph 92 and names the owner and AI participation for each customer-facing control.

I would reject any control matrix that gives an LLM gateway credit for sending a transaction alert. A model can explain the alert. The payment and notification stack must produce it.

TL;DR

Use DORA and its related technical standards for the broad ICT risk framework. Use amended EBA/GL/2019/04 for the remaining payment service user relationship requirements.
Map paragraphs 92 through 98 to a control objective, accountable owner, AI implementation point, test and evidence, plus a gap and coverage verdict.
AI can deliver approved security guidance and communicate updates. It can also explain customer options and triage security support when the workflow is controlled.
Payment-function disabling, limit changes, transaction-event detection, alert delivery, and case resolution need adjacent systems. HTTP AI enforcement provides partial evidence rather than full control coverage.

The current source map has two layers

The EBA notice from 11 February 2025 places the broad ICT duties under DORA. That framework covers management of technology exposure, incident reporting, third-party oversight, and testing. The amended Guidelines applied by 20 May 2025 and complement DORA in the customer relationship area.

That distinction creates two workbooks. DORA covers the running financial entity and its ICT dependencies; the residual EBA workbook covers what payment service users receive and can do. The DORA AI inference controls map addresses the first layer. This map addresses the second, limited to customer-facing language and routed model interactions.

Paragraphs 92 and 93 map to governed security guidance

Objective: Give payment service users assistance and guidance on payment-security risks, then update that guidance as threats and vulnerabilities change.

Owner: Fraud operations or security communications owns the content and customer operations manages delivery. The AI governance function approves model use.

Implementation: Put approved guidance in a versioned source and restrict retrieval to that source. Require escalation when the user's question exceeds its scope. A policy at the AI request boundary can block prohibited data and unapproved model routes.

Test and evidence: Select interactions under the old and new content versions. Trace the threat-change ticket through approval and deployment, then verify the customer-facing response. Preserve the model route, source version, policy decision, output delivered, and timestamp. The control is partially covered at the gateway because content approval and threat assessment happen elsewhere.

Paragraphs 94 and 95 map to customer-controlled payment settings

Objective: Allow users to disable eligible payment functionality where the product permits it and adjust agreed spending limits up to the applicable maximum.

Owner: Payment product owns the option. The IAM team handles step-up authentication and the payment platform executes the change. AI governance owns the accuracy of the explanation and handoff.

Implementation: An assistant may explain available settings or start an authenticated workflow. The application should pass a narrow action and verified identity to the payment service, then return the authoritative result. The LLM should never invent a successful state change.

Test and evidence: Attempt an allowed change and a change above the agreed maximum. Separately test an action by an unauthorized caller. Correlate the AI conversation with authorization and backend events. Gateway coverage is limited to the LLM request and response. The payment platform supplies the decisive execution record.

Paragraph 96 maps to transaction alerts

Objective: Give payment service users the option to receive alerts on initiated or failed attempts to initiate payment transactions, helping them detect fraudulent or malicious use.

Owner: Fraud engineering detects the event, notification operations delivers the alert, and customer product manages preferences. AI may explain the event after delivery.

Implementation: Trigger the alert from the transaction stream. Keep the control independent of chatbot availability and model behavior. If AI drafts explanatory text, constrain it to the transaction facts and approved remediation steps.

Test and evidence: Generate a qualifying initiated or failed attempt, inspect the preference decision, confirm the delivery event, and test failure handling. Then sample any linked AI explanation. An LLM record earns partial coverage. Transaction and notification records prove the control.

Paragraph 97 maps to security procedure communications

Objective: Keep payment service users informed about security procedure updates that affect payment services.

Owner: Security sets the procedure, then legal and communications approve the notice. Channel operations manages delivery, while AI governance controls any generated or interactive explanation.

Implementation: Bind every explanation to the approved notice version and block the model from presenting an unpublished procedure as active. Give customers a stable route to the authoritative notice rather than relying on a generated answer alone.

Test and evidence: Trace one procedure change through approval and recipient selection. Verify delivery and the customer interaction. Compare the generated explanation with the approved notice. The AI audit trail requirements provide a reusable event shape for the model portion, while the communications platform proves delivery.

Paragraph 98 maps to security assistance and anomaly intake

Objective: Provide assistance for security questions and support requests, including anomaly notifications. Tell users how to obtain that assistance.

Owner: Customer security operations owns intake and resolution. AI may classify the request and provide approved first-line guidance. It may also prepare a case summary.

Implementation: Publish the available support channels. Route high-risk terms and disputed transactions to a human queue. Do the same for suspected compromise and uncertain answers. Pass a stable transcript or interaction reference into the case so an investigator can reconstruct the handoff.

Test and evidence: Submit a routine question and a suspected-fraud report. Separately submit an unsupported request. Confirm the correct response, escalation, case creation, and acknowledgement. Review the associated action lineage record. Gateway coverage ends at the routed AI decision. Case handling and resolution stay with support systems.

The mapping record needs an honest coverage verdict

For each row, store the source paragraph, objective, owner, implementation, test procedure, evidence reference, result, gap, and remediation date. Add one coverage value: full, partial, adjacent, or out of scope. Full means the named control point can enforce and evidence the objective. Partial covers one defined step. Adjacent means the proof comes from another system.

This vocabulary keeps the control room honest. A green spreadsheet cell has little value if the evidence behind it belongs to a different transaction. Internal audit should sample the joins, especially conversation-to-payment and conversation-to-case correlations.

DeepInspect

DeepInspect can enforce and record routed HTTP AI traffic. When an authenticated customer or support agent request reaches an LLM through the gateway, DeepInspect evaluates application-supplied identity and policy context. It can apply permit-or-deny decisions and redact the request. The resulting event records the model route, policy version, data treatment, outcome, and timestamp.

This produces partial evidence for guidance delivery, procedure explanations, and security-support triage. Payment settings, limit enforcement, transaction detection, notification delivery, content approval, and case resolution remain adjacent controls. Direct or opaque vendor model calls sit outside the gateway until routed through it. Book a demo today.