Eighteen months after the decision, the letter arrives. The regulator wants to know why the credit line was cut, on what figures, and who approved it. The analyst has left. The vendor has retired the model. 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 to be right. It asks who acted, on what basis, and whether that can be shown. Probability describes statements; accountability describes acts.[1] Deployments that treat logging as a compliance feature confuse the two, and find out when they are questioned.

The questions come late. An institution makes decisions with consequences over decades, but answers for them over a few years.[2] The people who took the decision move on before the consequences arrive, and whoever inherits the question inherits none of the context. Traceability is what connects the two. An institution that cannot reconstruct why it acted cannot answer for it.

For financial entities, this is now 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 decisions affecting the ledger is an ICT system, and the company that runs it for you is an ICT third party. The audit trail is where both obligations meet.

What a trail must allow

Four things. A trail that misses one is just a diary.

Name. Who approved the action, and when. A decision without a name is no one’s decision.[4]

Locate. Which data, as it stood at that moment, and which rule. Not the current value of the field: the value that was read.

Replay. Ask the same question with the same inputs today, and get the same answer. A decision that cannot be replayed is a coincidence with a timestamp.

Order. The sequence of events, fixed in a form nobody can rewrite: not the vendor, not the administrator, not the person named on it.

Our company page puts it in one line: who approved what, on which data, in an order that cannot be rewritten.[5] It is a commitment to our clients, and it is also the standard a regulator will apply.

Three kinds of log we refuse

A log the vendor keeps. When the contract ends, the trail ends with it. When the regulator asks, you have to ask the vendor, who answers on its own schedule. A trail you have to request is a third-party dependency, and DORA treats it as one.[3:1] Monarch runs inside your infrastructure and Galahad hosts none of your data, so the trail is yours from the start.[5:1]

A log that records the answer but not the path. Most logs list outputs. They say what the system said, but not which data, which rule and which reasoning produced it.[4:1] No one who will later have to justify an action can rely on an answer without its lineage.

A log that cannot be replayed. If the same question can return a different answer, the log records what happened once, not how the system behaves. We hold that the same question, asked twice, must return the same answer, word for word, and that a trail is only worth as much as its replay.[4:2]

Traceability is a defence

An organisation that cannot read its own operations cannot defend them.[6] A supplier that has captured you, a fraud that has run for years, a risk sitting between two systems that were never connected: each hides where no trail reaches. A good trail is not paperwork added to the business. It makes the business readable, first to itself, then to whoever has the right to ask.

Europe wrote the rules first. What the rest of the world will require within five years, a European vendor can offer today. Auditability is a competitive advantage, and it is wasted when treated as a compliance chore.[7]

Questions to ask a vendor

Ask them in writing, before the demonstration.

  1. Where does the trail live, and who holds it the day after the contract ends?
  2. For any past decision, can I see the data as it stood then and the rule that was applied?
  3. Can I replay that decision today, with the same inputs, and get the same answer?
  4. Whose name is on the approval, and at what time?
  5. Can anyone, including you, edit or delete an entry afterwards?
  6. What does the regulator see, and do I need you present to show it?

A vendor who answers all six from inside your network has built a real audit trail.

Monarch runs inside your infrastructure and keeps a trail that holds up: who approved what, on which data, in an order that cannot be rewritten. See it on your data.


  1. Machines of Consequence, thesis 10. Read it ↩︎

  2. Machines of Consequence, thesis 41. Read it ↩︎

  3. 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 ↩︎ ↩︎

  4. Machines of Consequence, thesis 11: provenance, determinism, reversibility, imputation. Read it ↩︎ ↩︎ ↩︎

  5. Galahad, the company. Read it ↩︎ ↩︎

  6. Machines of Consequence, thesis 16. Read it ↩︎

  7. Machines of Consequence, thesis 47. Read it ↩︎