Are the original 2019 EBA ICT controls still the current baseline for banks?

DORA now supplies the harmonised ICT risk framework for financial entities in its scope. The EBA's amendment report says most of EBA/GL/2019/04 became obsolete in substance and reduces the Guidelines to payment service user relationship management. A current checklist should therefore separate DORA work from the remaining section 3.8 checks.

Why is the applicability decision part of the checklist?

A control test has meaning only against the correct instrument and scope. Recording the entity, service, AI use case, and applicable text prevents auditors from grading a bank against deleted material or overlooking a residual payment-user obligation. It also creates a reviewable legal assumption that counsel can challenge.

Does every customer-service chatbot fall within section 3.8?

Focus on chatbot functions tied to security risks and payment services, such as fraud guidance, anomaly reporting, security procedure updates, and support. A general product marketing bot sits outside that control purpose. Document the use-case boundary and route ambiguous cases to the compliance owner.

What status values should the checklist use?

Use a small gradable set such as pass, partial, fail, and out of scope, with evidence and rationale for every result. Partial should name the missing component. Out of scope should cite the applicability fact. Avoid a single yes or no field that hides an untested channel or opaque vendor route.

Can DeepInspect complete the entire checklist?

DeepInspect can produce and enforce evidence at the routed HTTP AI boundary. It cannot prove that a payment limit changed, a transaction alert arrived, a notice reached the customer, or a support case was resolved. Those outcomes require records from the payment, notification, communications, and case-management systems.

EBA ICT Guidelines AI Compliance Checklist After DORA

An EBA ICT Guidelines AI compliance checklist should begin with a deletion, not a control. The Digital Operational Resilience Act has applied since 17 January 2025, and the EBA reduced EBA/GL/2019/04 because most of its earlier ICT risk content had become obsolete in substance. The amended EBA report retains Guideline 3.8 on payment service user relationship management. A checklist copied from the 2019 version can look thorough while testing the wrong current instrument.

I would make the scope decision a signed first row. Everything below it becomes simpler once compliance and audit agree on which record belongs under DORA and which belongs under the residual EBA Guidelines.

TL;DR

Confirm the entity and payment service, then the AI feature and the legal instrument, before testing a control. DORA carries the broad ICT risk framework; amended EBA/GL/2019/04 retains payment service user relationship management.
Grade each check with six fields: owner, pass condition, evidence reference, exception, remediation owner, due date.
Test customer security guidance, threat updates, eligible control settings, spending-limit options, transaction alerts, procedure notices, access to security support.
Keep runtime LLM evidence separate from execution evidence. An AI gateway can prove a routed policy decision, while payment and notification systems prove that customer-facing controls worked.

Check 1: record the current applicability fork

Owner: Legal or regulatory compliance owns the applicability decision and approval record.

Pass condition: The workpaper identifies EBA/GL/2019/04 as amended, records that the amendment applied by 20 May 2025, and explains how DORA affects the entity. The EBA's February 2025 notice states that DORA introduced harmonised ICT risk requirements and prompted the narrower Guidelines.

Evidence: entity classification, payment-service inventory, competent-authority position, link to the current consolidated text. Use the broader DORA AI compliance article as an implementation orientation, then validate each legal conclusion against primary text and counsel.

Check 2: inventory AI in the customer-security process

Owner: Payment product and AI governance jointly maintain the inventory and use-case boundaries.

Pass condition: The inventory names every LLM that drafts or delivers security guidance, explains transaction alerts, receives anomaly reports, or assists a customer with payment controls. Each entry records the channel, model route, data classes, provider, business owner, escalation path.

Evidence: architecture diagram, service catalogue entry, model inventory record, approved use case, observed route sample. Include vendor-hosted chat where the provider hides the model call, marking that route as opaque rather than assuming an enterprise gateway sees it. A complete inventory shows the white browser chat window the customer uses and the less visible API route behind it.

Check 3: control security guidance and updates

Owner: Fraud operations or security communications owns the approved guidance and update process.

Pass condition: Guidance served through AI uses approved source content and updates when threats or vulnerabilities change; paragraphs 92 and 93 of the consolidated EBA Guidelines cover assistance, guidance, and updates communicated to payment service users.

Evidence: approved content version, threat-change ticket, approval history, deployment timestamp, sample AI interactions, regression test. A response sourced from an old knowledge snapshot fails even if its grammar is perfect.

Check 4: preserve customer control options

Owner: Payment product owns the available controls and authenticated customer flow.

Pass condition: Where product functionality permits, eligible payment functions can be disabled and agreed transaction limits can be adjusted up to the maximum under the relevant arrangement. The AI assistant accurately describes the available option and routes the customer to an authenticated control flow.

Evidence: product configuration, authorization test, user-interface capture, backend event, linked AI conversation. Paragraphs 94 and 95 address the product options. The LLM should never simulate success with a confident sentence when the payment platform rejected the action.

Check 5: verify transaction alerts outside the model

Owner: Fraud platform and notification operations jointly own alert generation and delivery evidence.

Pass condition: Customers can receive alerts on initiated or failed attempts to initiate payment transactions, consistent with paragraph 96, and the control works if the chatbot is unavailable because alert generation belongs in the transaction and notification path.

Evidence: alert preference, triggering transaction event, delivery event, failure handling, customer support record. AI may explain an alert or help investigate it. The model is not the alerting control. This boundary also prevents a generic prompt log from being presented as proof of delivery.

Check 6: test security procedure notices and support access

Owner: Customer operations owns procedure notices, support access, and escalation outcomes.

Pass condition: Customers receive updates about security procedures that affect payment services and can reach assistance for questions, support requests, anomalies, or security issues; paragraphs 97 and 98 supply the test.

Evidence: notice approval, recipient population, delivery record, support-channel availability test, escalation event, case outcome. Sample an interaction where AI escalates rather than answering beyond the approved knowledge. The human queue should receive the transcript reference and security context without requiring the customer to repeat the incident.

Check 7: grade the runtime AI evidence

Owner: Security engineering maintains runtime evidence, while internal audit tests its completeness and integrity.

Pass condition: Each routed HTTP AI interaction records the authenticated principal or session, route, model endpoint, source-content version, policy version, decision, response treatment, timestamp. Denied and redacted events appear in the population, whose exported sample has an integrity check and a documented extraction query.

Evidence: per-decision records, policy repository, export manifest, access log, review sign-off. The fields align with the AI audit trail requirements, but the retention rule should follow the financial entity's applicable schedule rather than a generic web checklist.

Check 8: close gaps with named remediation

Owner: The named control owner closes each gap under compliance oversight.

Pass condition: Every failed test has a severity, an accountable owner, and a target date; the same record captures the interim measure and retest result. Exceptions identify the affected AI route and customer process. An opaque vendor route should produce a procurement and monitoring action, rather than a green status based on the vendor's general assurance report.

Evidence: gap register, risk acceptance, remediation ticket, retest sample, closure approval. My opinion is simple: a checklist without evidence references is meeting notes wearing a green badge.

DeepInspect

DeepInspect covers the runtime HTTP slice when authenticated users or agents reach an LLM through the gateway, where it can evaluate application-supplied identity and policy context before redacting or denying disallowed content. Each routed interaction gets a per-decision record. That evidence supports checks on approved AI guidance, escalation, route authorization, and data treatment.

Payment settings, spending limits, transaction-alert delivery, customer notices, and case resolution remain in their respective systems. The control file should correlate those records rather than inflate the gateway's scope. Let's talk today.