The EU's Digital Operational Resilience Act has applied to financial entities since 17 January 2025. It places the obligations squarely on the institution: the bank, lender, payment or investment firm remains accountable for its ICT risk even when the technology is run by a vendor. This page sets out how DORA's pillars intersect with AI-operated banking workflows, and what a risk committee should ask of any core platform provider, ours included. It is orientation for risk, compliance and technology leaders, not legal advice.
DORA consolidates the EU's digital-resilience expectations for financial entities into one regulation, applied proportionately to the entity's size and risk profile. Every pillar below is an obligation the institution holds; vendors can support the work, but they cannot take it over. For how DORA sits alongside MiCA and PSD3 in a wider implementation programme, see the regulatory implementation playbook; this page goes deeper on DORA itself and on what changes when AI agents operate banking workflows.
DORA requires financial entities to maintain a documented ICT risk-management framework: identified critical functions, mapped ICT assets and dependencies, protective controls, detection capability and tested recovery, owned by the management body.
DORA requires financial entities to detect, classify and report major ICT-related incidents to their competent authority within defined timelines, and to keep the evidence that supports the classification.
DORA requires financial entities to test their ICT resilience on a regular cycle, from vulnerability assessments and scenario testing up to threat-led penetration testing for entities that meet the relevant criteria.
DORA requires financial entities to manage the risk of ICT services bought from third parties: due diligence before contracting, defined contractual provisions, a register of information covering ICT providers, concentration-risk assessment and documented exit strategies.
DORA encourages financial entities to participate in arrangements for sharing cyber-threat information and intelligence, so that what one institution learns can harden the others.
In every pillar, the regulated financial entity is the accountable party. Outsourcing an ICT function does not outsource the obligation. That principle shapes everything else on this page, including how to read a vendor's claims.
When an AI agent prepares onboarding cases, drafts credit decisions or proposes payments, the institution has added an ICT dependency whose behaviour, not just whose availability, must be governed. The resilience question stops being only "is the system up?" and becomes "is the system doing what it is authorised to do, can we see what it did, and can we stop it?"
A model that is online but acting outside its scope is an operational incident in the making. Scoped permissions, transaction limits and policy gates that run before any side effect turn agent behaviour into something the ICT risk framework can actually assess. See how governed AI workflows are structured on CoreFi.
Incident classification and reporting depend on reconstruction: what triggered the workflow, what the model received, what it proposed, which policy decided, who approved. An append-only audit record per workflow is what makes an AI incident reportable rather than unexplainable.
Resilience testing must cover the AI layer: what happens when a model provider degrades, a policy gate fails closed, or the reviewer queue backs up. These are scenarios to rehearse, not edge cases to discover in production.
Human-in-the-loop approval is usually discussed as AI governance. Under a resilience lens it is also the fallback path: when policy routes a case to a human, the institution has a tested degradation mode instead of a hard stop.
The practical consequence: runtime policy gates, audit records and human escalation belong in the institution's resilience documentation, not only in its AI-governance policy. For the second-line view of these controls, see CoreFi for compliance and risk officers.
A core banking platform is, for most institutions, a critical or important function's ICT dependency. That places the provider, and the provider's own sub-processors and model providers, inside the institution's third-party risk framework: due diligence, contractual provisions, the register of information, concentration assessment and exit planning. Separately, the EU framework allows certain critical ICT providers to be designated for direct European-level oversight; whether a given provider is designated is a supervisory decision, not a vendor claim. Below is what an institution should expect to be able to ask for. CoreFi's own posture against each item is summarised in the Trust Center, with the detailed documentation available on request under NDA.
Ask for service descriptions, availability commitments, data-location terms, incident-notification commitments and sub-processor change notification in the contract, not in marketing material. CoreFi documents these in the service agreement and the Data Processing Agreement.
Ask for the right to audit, the documentation set that supports it and audit-log extracts on request. CoreFi supports customer audits and supervisory requests with documentation and extracts from the append-only audit record.
Ask how customer, account, ledger and audit data leave the platform, in what formats, and what the off-boarding terms are. CoreFi's adoption paths each carry a defined exit posture, with data exportable in standard formats.
Ask who detects, who notifies, on what severity scale and with what evidence. CoreFi detects, notifies and remediates at the platform layer; the customer classifies and reports at the regulatory layer, with hand-off points defined in the DPA.
Ask whether the provider will participate in your testing programme. CoreFi documents business-continuity and disaster-recovery procedures in the trust pack, and participation in a customer's resilience-testing exercises, including scenario walkthroughs of platform failure modes, is available on request.
Ask for the sub-processor chain, including model providers, with regions and roles. CoreFi publishes the categories publicly and shares named vendors in the evidence pack; the audit log records which model produced each agent action.
A working translation for risk-committee use: what each pillar means once AI agents operate banking workflows, and the question that separates a substantive vendor answer from a slogan.
No vendor answer makes the institution compliant; DORA's obligations stay with the financial entity. The table is a due-diligence aid, not a compliance checklist.
CoreFi is the platform vendor; our customers remain the regulated entities and hold the DORA obligations. CoreFi does not claim DORA certification, and no such certification exists. What the platform provides is control surfaces and evidence: scoped permissions, policy gates and environment isolation that an ICT risk framework can assess; severity classification, notification commitments and post-incident evidence that feed the customer's reporting; documented continuity and recovery procedures with testing participation available on request; a published sub-processor model with contractual notification of changes; and an append-only audit record behind all of it. The platform this describes runs in production today: 20+ deployments, 200k+ end-customer accounts, six geographies (Italy, Spain, France, Argentina, Chile, Bolivia) and 99.9% platform uptime against operational SLOs.
The responsibility model, sub-processor summary, residency posture and the pillar-level operational-resilience mapping, with the detailed control mapping in the trust pack on request. Visit the Trust Center.
Encryption, access control, audit, AI governance and the exact status of independent attestations: what is in place, what is in progress, what is plug-in ready. Read the overview.
The institution-versus-platform topology: where the boundary sits, which controls run on which side, and how the audit layer spans both. See the architecture.
A readiness conversation walks through your third-party framework, the questions in the table above and the documentation CoreFi makes available on request under NDA. We describe how the platform supports the posture your institution has to defend; we do not give legal or regulatory advice.
Browse every buyer-education resource in the Knowledge Hub, or continue with two adjacent guides: AI governance in banking operations, on how policy gates, human approval and audit records govern agents in day-to-day operations, and MiCA and tokenized-asset infrastructure, on what MiCA expects of the platform layer beneath a licensed issuer.