DORA Register Information CSV — check register data before submission

Twenty-four findings — nineteen errors and five warnings — on ten of eleven rows. That is what an eleven-row sample DORA Register of Information gives up the first time a compliance engineer at an EU payment institution checks the file before filing it.

The register is the list Article 28(3) of Regulation (EU) 2022/2554 asks a financial entity to maintain: every contractual arrangement with an ICT third-party provider, the function it supports, whether that function is critical, where it is provided, what it costs. An export job produces it, and its errors are not spelling mistakes. They are arithmetic, and arithmetic is invisible to the person doing the final read-through.

Start with the identifier. An LEI is twenty characters (ISO 17442) and the last two are check digits computed over the other eighteen with ISO 7064 MOD 97-10. Row two of the sample carried 549300ZBWZJMTEDVDS68. The check digits should be 67. One character is off — a transposition, a paste that lost a keystroke — and nothing about the value looks wrong. A spreadsheet will not catch it. A generic CSV validator will not catch it, because the field is twenty alphanumeric characters and that is all a schema knows to ask. The lint recomputes the digits and prints the two it expected.

Then the dates. 01/04/2024 is the first of April where it was typed and the fourth of January where it is read; the sample carries one. 2026-02-30 is a date that does not exist. One row ends before it starts. And one arrangement ended on 2026-06-30 while the file is being filed as of 2026-09-13 — a contract that terminated in June, still listed as live in September. That last check depends entirely on the reference date, which you set: move the date and the finding moves with it.

Then the links. A register is a graph, not a list. ARR-2026-003 appears as the reference on two different rows, so the supervisor cannot tell which arrangement is which. Another row points at overarching arrangement ARR-2026-009, which no row in the file declares. One row names itself as its own parent. One row is filed twice, field for field.

And the dull ones that bounce a file just as hard: fourteen fields where the header has thirteen, because a provider name held an unescaped comma; Crédit where Crédit was meant, UTF-8 read as Latin-1; 412.000,00 in a numeric column; the word Critical in a yes/no column; Norway where an ISO 3166-1 alpha-2 code belongs; eur in lower case.

Twenty-four checks, all computed from the file itself. None of them gives legal advice or tells you whether the register is complete — they tell you whether what you wrote down survives being read by a machine that is not yours.

Why not hand the file to an assistant? Because the register is the map of who holds your data and which functions stop without them — the one file you cannot paste into a hosted chat window. And because ISO 7064 is arithmetic: a model either runs it or guesses. This runs on the file where it sits, and so does the same engine in the browser.

Checking the file open in your editor is free: every row, all twenty-four checks, no key and no account, findings in the Problems panel and a written summary in the output channel. The licence covers a different job — sweeping every register CSV in the workspace at once and writing one dated report file for the audit trail. By hand the same pass over an 800-row register is 24 × 800 = 19,200 comparisons, and the check digits cannot be done by eye at all; one hour of the analyst who would do it costs more than the licence.

Same engine, byte for byte, in the browser: https://getreadystack.com/tools/dora-register-lint