Eighteen months after the decision, the letter arrives. The regulator wants to know why the line was cut, on what figures, and who signed. The analyst has moved on. The model has been retired by its vendor. The log holds the answer the system gave that morning, and nothing else. The bank knows what was decided. It cannot show how.
What a regulator asks
A regulator does not ask whether the answer was likely. It asks who took the act, on what, and whether it can be shown. Probability is a property of statements. Imputability is a property of acts.[1] Every deployment that filed its logs among the compliance features confused the two, and discovered the difference in the exception, at the moment of being asked.
The asking comes late. An institution decides across forty years and answers across five.[2] The mandate that took the decision ends before the consequence arrives, and the person who inherits the question inherits none of the memory. Traceability is the only bridge between the two horizons. An institution that cannot reconstruct why it did what it did has no long horizon. It has a long past it cannot read.
Financial entities now carry this in law. DORA requires them to detect, manage, record and report ICT-related incidents, and to manage the risk of the ICT third parties they depend on.[3] A system that proposes or takes a decision on the ledger is an ICT system. The company that runs it for you is an ICT third party. The trail is where both obligations meet.
What a trail must let a regulator do
Four verbs, and a trail that misses one is a diary.
Name. Who approved the act, and at what time. A decision with no name at the foot of it is weather.[4]
Locate. Which data, as it stood at that instant, and which rule. Not the current value of the field. The value that was read.
Re-run. Put the same question, with the same inputs, and obtain the same answer, today. A decision that cannot be replayed is a coincidence with a timestamp.
Order. The sequence of events, fixed, in a form nobody can rewrite afterwards. Not the vendor, not the administrator, not the person whose name is on it.
Our company page states it in one line: who approved what, on which data, in an order nobody can rewrite afterwards.[5] It is written as a promise to a customer. It reads equally well as the standard a regulator will apply.
Three logs Galahad refuses
A log the vendor keeps. When the contract ends, the trail ends with it. When the regulator asks, you ask the vendor, and the vendor answers on a schedule that suits him. A trail you must request is a third-party dependency, and DORA treats it as one.[3:1] We install inside your infrastructure and operate no hosting for your data, so the trail is yours before it is anything else.[5:1]
A log that records the answer and not the path. Most logs are a list of outputs. They say what the system said, and they are silent on which datum, which rule and which path through which model of the world produced it.[4:1] An answer without its lineage cannot be acted upon by anyone who will later be asked to justify the action. A log of such answers is a list of things you once believed.
A log nobody can re-run. If the same question can return a different answer, the log records what happened once. It does not record what the system does. A regulator examining a sampled system is examining a mood. We hold that the same question, put twice, returns the same answer, to the letter, and that a trail is worth exactly what its replay is worth.[4:2]
Legibility is a defence
An organisation that cannot be read cannot be defended.[6] The supplier who has captured you, the fraud that has run for years, the exposure sitting between two systems that were never asked to speak: each lives in the space no trail covers. A trail that holds up is not paperwork laid over the business. It is the business, made readable, first to itself and then to whoever is entitled to ask.
Europe wrote the rules. What the world will demand within five years, a European vendor can sell today, and the only way to squander the position is to keep treating it as compliance.[7] Auditability is a weapon, and the trail is the edge of it.
Questions to put to a vendor
Put these in writing, before the demonstration.
- Where does the trail live, and who holds it the day after the contract ends?
- For any past decision, can I see the data as it stood at that moment and the rule that was applied?
- Can I re-run that decision today, with the same inputs, and get the same answer?
- Whose name is on the approval, and at what time?
- Can anyone, including you, edit or delete an entry after the fact?
- What does the regulator see, and do I need you in the room to show it?
A vendor who answers all six from inside your network has built a trail. A vendor who answers with a dashboard has built a diary.
Monarch installs inside your infrastructure and leaves a trail that holds up: who approved what, on which data, in an order nobody can rewrite afterwards. See it on your data.
Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), applicable since 17 January 2025: management, classification and reporting of ICT-related incidents; management of ICT third-party risk. Source ↩︎ ↩︎
Machines of Consequence, thesis 11: provenance, determinism, reversibility, imputation. Read it ↩︎ ↩︎ ↩︎