By Yair Knijn · February 23, 2025

DORA quietly made file transfer a board-level risk. Most directors missed the memo.

Walk through any second-line DORA scoping exercise and you can predict the list before it's written: core banking, the payments rails, the cloud provider with the eight-figure contract. Those get classified, dropped into the Register of Information, and the third-party inventory is declared done. The managed file transfer platform never makes the list. Nobody on the second line treats it as a system. It is the thing that moves the files, and it has always been there.

That blind spot is the finding. The MFT layer is an ICT third-party arrangement under the Digital Operational Resilience Act, and an arrangement that supports a critical or important function is precisely what a competent authority expects to see documented, criticality-flagged, and board-approved. A Register with a hole in it is not untidy. It is non-compliant.

What the Register of Information actually demands per arrangement

The Register is not a vendor list. Commission Implementing Regulation (EU) 2024/2956 sets out the templates, and they punish hand-waving. You file per contractual arrangement, linked across templates by Legal Entity Identifier: the provider's LEI, the type of ICT service mapped to the official taxonomy, whether it supports a critical or important function, data sensitivity, storage country, substitutability, and exit-plan status. National competent authorities collected the first registers in 2025 against an end-of-April deadline, and they wanted a complete xBRL-CSV package against the ESA taxonomy, not a spreadsheet.

An absent file-transfer vendor is not an under-described one. You have asserted it does not exist. And the cross-references give you away: the linked rows for the function it supports point at nothing.

Why MFT counts as a critical or important function

Article 3 turns on whether a defect or failure in the function would materially impair financial performance, soundness, or continuity of services. Put it operationally: if the file-transfer layer stops for a day, what stops with it? Bordereaux to reinsurers. Settlement and reconciliation files to clearing partners. Regulatory reporting submissions. Payroll. KYC document exchange. None of those reroute through someone's inbox.

The payloads drive the criticality. This platform carries signed, encrypted, audited regulated data between you and your counterparties. A function that, on failure, halts settlement or blows a reporting deadline clears the materiality bar. Classify it as supporting a critical or important function, or be ready to defend in writing why it does not.

Concentration risk when one vendor moves all your partner data

DORA wants concentration risk on the table, not buried in a procurement decision from six years ago. When a single MFT vendor moves files for every partner, every line of business, and every regulated report, that is the concentration the Register is built to expose. The substitutability and reintegration-effort fields exist so the board can see how much a single point of failure costs.

• Substitutability: can the service be replaced, and how fast, before continuity breaks
• Exit plan: a documented, tested route off the provider, not a contract clause nobody has read
• Subcontracting chain: who sits behind the vendor moving your regulated data, now scoped by Delegated Regulation (EU) 2025/532

Board approval and the personal-accountability shift

Here is the structural change directors keep missing: under DORA the management body owns the ICT risk framework and cannot delegate that ownership away. The strategy on third-party ICT risk, including the arrangements in the Register, is approved at board level. An MFT platform that never reached the Register never reached the board, and that gap now lands on a named individual rather than in an audit appendix.

The fix starts with a clean inventory: every protocol endpoint, every counterparty connection, every SFTP and AS2 route, classified and attributed before filing season answers the question for you. xEvolve puts those transfers, their counterparties, and their audit trail into a single classifiable record, so the Register entry writes itself instead of becoming the finding. See how the audit model maps to your Register obligations.