The AML Audit Trail as Operating Standard: What Switzerland’s Record-Keeping Regime Now Demands | OwnMore

When practitioners speak of AML compliance in Switzerland, conversation tends to focus on the entry gate: who was identified, who is the beneficial owner, and where does the money come from. That gate matters, and the companion explainer on KYC and AML onboarding for Swiss private-market investments addresses it in detail. But the GwG and its associated ordinances impose an obligation that stretches far beyond the initial check. The intermediary must keep records throughout the relationship, monitor it over time, refresh its assessments when material circumstances change, and be able to demonstrate — if a regulator or auditor asks, perhaps years after the fact — that all of this was done, in the right order, with appropriate documentation.

This is the record-keeping dimension of the AML obligation, and it is where many practitioners underinvest. Entry checks are visible and calendar-bound; the ongoing record is invisible until someone asks for it. The practical effect of the tightening AML regime — which, through LETA and the amended GwG, extends greater attention to beneficial-ownership transparency, to the role of intermediaries in real estate, and to transaction monitoring — is to raise the cost of that invisibility. The question a defensible process has to answer is not only "did we do the checks?" but "can we prove it, in sequence, against the actual documents used, at any point the regulator chooses?" For matters of Swiss law, specific obligations and timelines, always consult qualified Swiss counsel and the primary federal texts.

A companion article on provenance and audit trails as a private-market requirement explains why provenance matters structurally across the investment lifecycle. This article approaches the same concept from the AML record-keeping angle: what does a defensible record actually need to contain? The answer is an ordered, reconstructable chain of events. For each material action — a client identification, a beneficial-ownership determination, a source-of-funds assessment, an offer, a reservation, a signed subscription, a settlement — the record must capture who performed the action, in what capacity, at what precise time, and against which specific version of the document or data.

Version specificity matters more than it might appear. An audit conducted under the AML regime is not a check of the current state of affairs; it is a reconstruction of what was done, with what information, at the time it was done. If the identity documents, the UBO declaration, the subscription agreement and the settlement confirmation existed across different file revisions, the question a regulator will ask is: "What version did the responsible party actually see and act on?" A record that logs only the latest version of a document, without anchoring each action to the version in use at that moment, cannot answer that question. The operational requirement is therefore not merely to keep records, but to keep timestamped, version-locked records — an ordered log, not a filing cabinet.

Most intermediaries and advisors do not set out to keep inadequate records. The failure mode is structural, not intentional. When records live across email threads, shared drives, PDF folders and spreadsheets — each updated informally by whoever is handling the file at that moment — the record is implicitly assumed to be "good enough" because it was assembled in good faith. The problem is that good faith is not the same as reconstructability. A regulator conducting an audit does not ask whether the right people tried to keep good records; they ask whether the record is complete, coherent and verifiable.

The structural weaknesses are predictable. Email gives no reliable audit trail of what was sent, when it was read, or what version of an attachment was acted on. Shared drives overwrite files without capturing the prior state. Spreadsheets record outcomes without capturing who made a change and when. PDF folders accumulate documents without recording the actions taken against them. None of these tools produce an ordered, timestamped, tamper-evident chain. And the gap tends to surface at precisely the moments when it is most costly: when a transaction is being signed and a question arises about whether onboarding was complete at the time of reservation; when a settlement is delayed and someone needs to reconstruct the authorisation chain; or when, years later, a regulator asks for the complete file. Building the record after the fact, against a standard of reconstruction rather than real-time capture, is orders of magnitude harder than maintaining it in sequence.

The technical answer to the record-keeping problem is an append-only, hash-linked audit log. The principle is straightforward: each event — an identity check, a UBO confirmation, a document signature, a status change — is written to the log as a new entry that cannot be altered or deleted. Each entry carries a cryptographic hash (SHA-256) of its own content together with the hash of the entry that preceded it. This means the entries form a chain: altering any earlier entry changes its hash, which breaks its link to every subsequent entry, making the alteration immediately detectable. The result is a record that is, by construction, append-only and tamper-evident.

For the AML record-keeping standard, this property matters in two ways. First, the log can be presented to a regulator with a verifiable claim that it has not been altered since the events were recorded: the chain integrity speaks for itself without relying on assertions by the custodian. Second, because each entry is linked to its predecessor, the log is inherently ordered: there is no way to insert a back-dated entry into the middle of the chain without breaking every subsequent link. This enforces exactly the sequence discipline the AML framework requires — onboarding before commitment, identification before settlement — at the level of the operating infrastructure, not by relying on process adherence alone. This is a description of a technical architecture and its properties; it is not legal advice, and intermediaries should take qualified counsel on their own obligations.

OwnMore is a compliance-native operating model for Swiss private-market real estate transactions. Each material action — investor classification, KYC onboarding, document execution, reservation, subscription, settlement confirmation — is sealed into an append-only SHA-256 audit chain as it occurs. The effect is that the ordered, version-locked evidence the AML record-keeping standard requires is produced as a byproduct of ordinary platform operation, not assembled after the fact from scattered files. Qualified investors and project developers or intermediaries who want to understand how the platform’s approach to record-keeping fits their own processes are invited to request access.

Four clarifications are necessary, and they are stated plainly. First, OwnMore operationalises the Swiss AML and record-keeping framework — it does not set the rules. The specific obligations, retention periods, monitoring requirements and reporting duties are matters of Swiss law (the GwG and its ordinances, under the competence of the relevant Swiss authorities); for your own situation, consult qualified Swiss counsel and the primary federal sources. Second, OwnMore does not make any third party legally compliant; the obligation rests with the obliged party and their counsel. Third, the audit chain is a capability of the platform, not evidence of past transactions: OwnMore is pre-launch, the chain currently records zero historical transactions, and no fabricated hashes, block numbers, client names, AUM, returns or deal counts are published here. Fourth, OwnMore is Swiss private-market investment infrastructure, operated by BloomDigital GmbH in Switzerland — a financial-infrastructure company, not a nutrition, wellness, supplement or multi-level-marketing brand; OwnMore is not FINMA-licensed, not an SRO member, and makes no claim to be a regulated broker or law firm.