When the money laundering logs are kept by the people under suspicion

Someone with admin rights can edit a log. In a quiet moment, a line disappears. A timestamp shifts by a few hours. By the time anyone asks, the trail looks clean.

That's the problem when money laundering networks move billions, as Svenska Dagbladet reports they are suspected of doing in Sweden ^[1]. The networks are under investigation. The amounts are large. And somewhere in the middle of it all, a bank's transaction monitoring system either flagged suspicious activity or it didn't.

If it flagged it, there's a log. If it didn't, the question is why not. Either way, the people who run the monitoring system are also the people who keep its logs.

The regulator's question

When Finansinspektionen, Sweden's financial supervisory authority, reviews a case like this, the logs are the starting point. They show which transactions were screened, which rules fired, which ones were escalated and which reports went out. If a report should have been filed within 24 hours of suspicion arising, the log is meant to show when that clock started.

But if the log can be edited afterwards, it becomes a story rather than a record. The regulator's question is how you know it hasn't been.

Think of it like the register at a corner shop. At the end of the day, the till roll shows what was sold. But if the shopkeeper can go back and change the entries before the accountant turns up, the roll isn't evidence. It's a draft.

What DORA says about logs

DORA, the Digital Operational Resilience Act, has applied to financial firms across the EU since 17 January 2025 ^[2]. The technical standard on ICT risk management, in Article 12(2)(d), says logging procedures must protect log systems and logged information against tampering, deletion and unauthorised access ^[2].

It doesn't say how. It says the logs must be protected, and it gives financial firms the job of working out what that means for their own systems.

Access controls are the foundation: role-based permissions, approval workflows and monitoring for unusual activity. But access controls have a limit. They stop people who shouldn't have access. They don't stop people who do have access and decide to use it.

That's where the question gets harder. If someone with legitimate admin rights changes a log entry, the access control sees nothing wrong. The change looks like normal work.

The evidence question

In a money laundering investigation, proving what your system did is as important as proving what you did. If a transaction should have triggered an alert and didn't, the log is meant to show why. If it did trigger an alert, the log is meant to show when, and what happened next.

But logs live in the same systems they describe, kept by the same organisation whose actions are being questioned. When someone asks whether a log has been changed, the answer can't just be "trust us".

Courts, regulators and auditors don't work that way. They want something they can check themselves.

What this means for you

If you run transaction monitoring, screening or case management for a financial firm, here are the questions worth asking now:

• Could you show a supervisor that your transaction monitoring logs are exactly what was written at the time, even if someone with admin rights had wanted to change them?
• If an incident happened six months ago, and someone questions your timeline, do you have a record of when alerts fired and when reports went out that nobody can quietly rewrite?
• Does your logging setup meet DORA's requirement to protect logs against tampering, deletion and unauthorised access, and can you show that it does?

The answers don't have to be perfect. They have to be checkable.

How a digital witness fits here

When a bank's transaction monitoring system flags suspicious activity, the thing to seal is the log entry as it's written: the transaction reference, the rule that fired, the risk score, the timestamp and who reviewed it.

Sealing takes a fingerprint of that entry, not the entry itself, so the log stays in your own systems. The fingerprint is sent to WitniumChain ^[3], which seals it on a chain where any later change would show, even one made by us. You get a witness ID back.

If the log entry is questioned later, anyone you share the record with can calculate the fingerprint again and compare it with the sealed one. If it matches, the entry is exactly what was written at the time. Change a single character and it won't match.

That's what makes it checkable. A regulator, an auditor or a court can verify the record without having to trust whoever kept it.

Your system sends the fingerprint through the REST API, the SDK or the MCP server ^[4]. To check, anyone you share the record with calculates the fingerprint again and compares it with the sealed one. The first 2,000 witnesses a month are free.

How it would work

1. Your transaction monitoring system writes a log entry and sends a fingerprint of it to WitniumChain.
2. WitniumChain seals the fingerprint and returns a witness ID.
3. When the log is questioned, you share the entry and the witness ID. The recipient calculates the fingerprint and checks it against the sealed one.

What a digital witness shows: that the log entry existed at that time and hasn't changed since it was sealed.

What it doesn't show: it doesn't show that the monitoring system worked correctly, that the right rules were in place or that reports were filed on time. It shows that the record of what the system did is unchanged.

What to watch

DORA's technical standards are now in force, and Finansinspektionen has published guidance on operational resilience for Swedish financial firms ^[5]. FI's supervisory approach to DORA will become clearer through 2025 and 2026 as reviews and inspections begin.

For firms in scope, the question to settle now is how logs are protected and how you can show that they are.