Skip to main content
Baobyte AML Suite

Internal audit

Evidence you retrieved yourself, from a record you can verify

The structural problem with auditing an AML function is that almost everything you review was prepared by the function you are reviewing. Independent retrieval and a verifiable record change what your opinion is actually based on — and they are the only two things on this page that matter.

  • Read-only by construction
  • Append-only hash-chained audit
  • Deterministic replay
  • Your own sampling

What you are measured on

What the third line is actually assessed against

Whether you can obtain evidence without the audited function preparing it
The single structural weakness of most AML audits. If the sample, the export and the formatting all come from the second line, the work is a review of what you were given rather than an independent test.
Whether the evidence can be shown to be complete and unaltered
A spreadsheet of audit events proves nothing about what is missing from it. What you need is a record whose integrity is testable — where you can verify the chain rather than trust the extract.
Whether you can test a control or only read its description
Reviewing a policy that says four-eyes applies is not testing that four-eyes applies. Testing means attempting the prohibited action and evidencing the refusal.
Whether your sample is genuinely yours
Random selection from the full population, drawn by you, is a different assurance proposition from a sample assembled on request — and the difference is exactly what a regulator will probe about your work.
Whether findings can be re-tested at follow-up
A finding closed on the basis of a screenshot cannot be re-tested. One closed on the basis of a repeatable retrieval can be, by whoever does the follow-up two years later.
Whether your own access is controlled and evidenced
Independence cuts both ways. An audit function with unrestricted read access to customer data is itself an unmanaged risk, and your access should appear in the same sensitive-read record as everyone else's.

Testing

Six audit questions, and what answering them looks like

The middle column is what most institutions can offer today. The right-hand column is what changes when the evidence is a system property rather than an export.

Standard audit requests, the usual answer, and the independently retrievable one
RequestUsual answerWhat you can do directly
Show me twenty closed alertsCompliance exports a spreadsheetYou draw your own sample from the full population, read-only, with the rule version and reasoning attached to each
Prove the audit log has not been alteredNot answerable from a database tableVerify the per-tenant hash chain and its anchors; a gap or an alteration breaks verification rather than hiding
Prove four-eyes is enforcedRead the policy documentInspect the same-actor denial results and the immutable approval history for a real proposal
Prove this rule did what it was supposed toAsk the person who wrote itReplay the rule version deterministically against the same input and compare the result
Show me who saw this customer's identifiersNot usually recordedSensitive-read events with actor, reason and timestamp, sampled directly and including denied attempts
Prove data that should have been purged was purgedAn assertion from operationsRetention reconciliation output, plus the refusal record where a legal hold prevented a purge

Integrity

Why the chain matters more than the log

Evidence

What you can retrieve without asking the second line

  • Chain verification output for the tenant's audit record, with the anchor evidence behind it.
  • Your own randomly drawn samples from the full alert, case, screening and report populations.
  • Maker-checker history for any governed change, including the same-actor approval attempts that were refused.
  • Deterministic replay results for a monitoring decision, tied to the rule version in force at the time.
  • Sensitive-read events and denied access attempts, including your own.
  • Retention and legal-hold reconciliation, including purge refusals and the hold that caused them.
  • The control register itself: each objective, its owner, the evidence required and its current status.

Proof

Independent assurance over the platform itself

Distinct from the controls above: this is about assurance over the vendor, and it is the section a third line will ask for first.

Placeholder — no third-party attestation or certification over the platform has been completed or approved for publication. Replace with sourced, approved content before this page is made public.

Third-party attestation — position not yet publishable

Report type, scope, covered period, auditing firm and issue date belong here. Displaying a standard's name before the work is complete is the exact misrepresentation an internal auditor is paid to catch, so this stays empty until there is a report to reference.

—

Attestation type

Awaiting a completed engagement and its scope.

—

Coverage period

Awaiting a defined period with an issue date.

—

Penetration test

Awaiting a summary approved for external release.

Questions

What internal audit asks first

What can the auditor grant actually do?
Read audit records, the chain, retention state and the AML evidence you have been granted. It cannot mutate an operational record or activate a policy — the read-only boundary is a property of the grant rather than a convention, and the negative case is covered by the release test suite.
How is the audit record protected from the people who run the platform?
The record is append-only and hash-chained per tenant with verifiable anchors, and object evidence is write-once ciphertext with an explicit no-delete test. Separately, a platform operator has no routine access to tenant content and can only obtain it through an approved, time-bound support session that is itself recorded.
Which controls are not yet accepted?
Several, and the register names them rather than colouring them green. Retention and legal-hold enforcement is recorded as pending a legal decision; regulatory filing is pending the authoritative regulator artefacts; backup, restore and recovery targets are pending an operational drill; incident response is pending an exercise; and several controls depend on external providers. Those statuses are the honest ones for a platform your institution has not yet tested in its own environment.
Can we test the controls ourselves during evaluation?
That is the intended use of the control register: each row states the evidence required to accept it, which is also a workable audit programme. Attempting the prohibited actions — same-actor approval, cross-tenant access, service-account content reads — and evidencing the refusals is a better evaluation than any demonstration.

Start the conversation

Ask for the control register, not the demo

The most useful artefact we can put in front of a third line is the control register itself — every objective, its owner, the evidence required to accept it, and its honest current status, including the rows that are still pending.