Evidence, Notes and Record Retention

A financial-crime investigation is only as defensible as the evidence that survives it. An analyst may make the right judgement today, but months or years later a quality reviewer, auditor, supervisor, financial intelligence unit or law-enforcement agency may need to understand what the bank knew at the time, which records were considered, which information was missing, why the decision was reasonable and whether the underlying material can still be retrieved. That is why evidence, notes and retention are not administrative tasks at the end of an investigation. They are part of the control itself.

The practical mental model is capture, explain, preserve, retrieve and dispose. Capture the information that materially supports the review. Explain the analyst's reasoning without turning opinion into fact. Preserve the relevant version of data and decision history for the period required by applicable law and policy. Retrieve it accurately when an authorised request arrives. Dispose of it when the lawful retention purpose ends, unless a valid hold or another lawful basis requires continued preservation.

This sounds simple until a bank operates across many countries, payment rails, products and systems. A transaction-monitoring case may reference customer due diligence held in one platform, payment messages held in another, sanctions-screening results from a vendor, device intelligence from a fraud service, historical account entries from a data lake, emails from a relationship manager and an external news article that later changes or disappears. If the case record only says "reviewed activity and no concern found", the reviewer has almost nothing to reconstruct. If the bank keeps everything forever without classification, it creates a different problem: uncontrolled personal data, inconsistent legal obligations, excessive discovery exposure and archives that are difficult to search.

The objective is therefore not maximum documentation. It is sufficient, accurate, attributable and retrievable evidence with a controlled lifecycle.

What counts as evidence in a bank investigation

Evidence in financial-crime operations is broader than a scanned document. It can include account transactions, payment-message fields, KYC records, beneficial-ownership information, sanctions-screening outputs, transaction-monitoring alerts, customer communications, trade documents, digital-channel signals, adverse-media findings, prior cases, internal referrals and information received through lawful external channels. The evidential value of each item depends on what it proves, how reliable the source is, when it was obtained and whether the bank can show that the record has not silently changed since the decision.

A useful distinction is between a source record, a derived record and an analyst assertion. A source record is information produced by the system or party closest to the event, such as the original payment instruction or customer-identification document. A derived record is created by transforming source information, for example a transaction-monitoring aggregation, risk score, entity-resolution link or investigator-generated transaction summary. An analyst assertion is a statement made during the review, such as "the transfers are inconsistent with the customer's stated business activity". All three may be legitimate, but they should not be confused.

Derived information needs lineage. If an investigator relies on a chart showing that EUR 430,000 moved through five accounts in two days, the bank should be able to explain which transactions were included, how reversals and internal transfers were treated, which exchange rates were used if currencies were normalised, and what time window was applied. Otherwise the chart looks persuasive while remaining difficult to reproduce.

Analyst assertions need supporting facts. A sentence such as "customer appears to be a money mule" is weak unless the note explains the observed behaviour: incoming credits from unrelated victims or counterparties, rapid onward transfers, cash withdrawals, newly added beneficiaries, device changes, or other relevant indicators. The investigator should also record plausible innocent explanations that were checked and either supported or contradicted by evidence. That discipline makes the file useful to a second reviewer rather than merely recording the first analyst's conclusion.

The bank should also distinguish financial-crime case evidence from formal criminal-forensic chain-of-custody requirements. Internal AML files should preserve provenance, integrity, authorship and access history, but not every bank case needs the same evidential procedure used by a police digital-forensics laboratory. If litigation, law enforcement or another legal process creates stricter preservation requirements, the bank should follow those requirements explicitly rather than pretending that ordinary case-management controls are universally equivalent to forensic custody.

Why screenshots alone are often not enough

Screenshots are useful because they show what a human saw, but they are fragile evidence when used alone. They can omit hidden fields, filters, pagination, timestamps, system version or data that sits outside the visible frame. They are difficult to query, and they may not prove whether the underlying record changed later. A screenshot of a sanctions hit, for example, is much more useful when the case also preserves the screening event identifier, screened party data, list source and version, match score or matching attributes where relevant, decision timestamp and reviewer identity.

Where systems permit it, a strong evidence package keeps the underlying structured record or a stable reference to it and uses screenshots as supplementary visual context. If the source system cannot retain historical states, the case-management platform may need a controlled snapshot of the relevant values. The implementation choice depends on architecture, privacy, storage and legal requirements, but the principle remains the same: a reviewer should be able to reproduce the material facts, not merely admire a picture of them.

This becomes particularly important when data is dynamic. Customer risk ratings change. Beneficial ownership changes. Sanctions lists change. Adverse-media pages are edited. Transaction-monitoring scenarios are tuned. A case reviewed in March may look different if opened in September against current data. The file therefore needs a point-in-time view of the material information that drove the original decision.

Point-in-time evidence: what did the bank know then?

One of the most common investigation errors is applying today's information to yesterday's decision. Suppose a corporate customer is now owned by Company B, but during the period under investigation it was owned by Company A. If the analyst sees only the current ownership graph, a historic counterparty relationship may be misunderstood. The same issue appears with addresses, directors, expected activity, PEP status, sanctions designations, risk scores and product entitlements.

For important evidence, a bank should be able to answer four questions: what was the value, when was it effective, where did it come from and when did the bank receive or process it? Those are not always the same dates. A beneficial-owner change may be legally effective on one date, reported to the bank later and loaded into the KYC platform later still. A sanctions designation may have an official effective time, a list-provider ingestion time and a bank-screening deployment time. Investigation systems that store only a current value lose this chronology.

Payment evidence has similar challenges. A pacs.008, MT103 or domestic clearing record can exist in several representations across channel capture, payment hub, screening, clearing gateway, correspondent interface and archive. The investigation needs the representation relevant to the question. If the concern is whether a sanctions control saw an intermediary name, the analyst may need the exact version passed to the screening engine, not a later enriched reporting view. If the concern is customer intent, the original customer instruction may be more relevant than an internally repaired message.

Good architecture therefore does not simply copy every record into the case. It provides stable identifiers and reconstructable lineage: customer ID, account ID, payment ID, UETR or other rail identifier where applicable, alert ID, screening-event ID, case ID, source-system record ID, event timestamp, extraction timestamp and version or effective dates. These links allow a later reviewer to move from the case narrative back to the authoritative record.

Case notes: separate fact, interpretation and decision

A case note should make reasoning visible without becoming a diary of every click. Strong notes usually have three layers.

The first layer is fact. It records what the bank observed and the source. Examples include transaction amounts and dates, customer occupation or business activity, counterparties, jurisdictions, account age, payment references, prior alerts, documentation supplied and external information checked. Facts should be specific enough that another person can verify them.

The second layer is analysis. It explains why the facts matter. An analyst might note that the transaction pattern is inconsistent with the expected profile, resembles rapid pass-through behaviour, or is partially explained by a documented acquisition. Analysis can include hypotheses, but hypotheses should be labelled as such. "The customer may be acting for an undisclosed third party" is very different from "the customer is acting for an undisclosed third party".

The third layer is decision and action. It records the conclusion, approval where required, and what happens next: close with no further action, escalate, request more information, restrict a service, refer to sanctions or fraud teams, file a suspicious report under applicable local rules, or continue monitoring. The decision should connect back to the evidence rather than appear as a disconnected status code.

Contradictory evidence deserves explicit treatment. A mature investigation file does not hide facts that weaken the initial suspicion. If the customer provides a credible invoice, audited financial statement or contract that explains part of the activity, the analyst should record it and assess its reliability. A good case can still reach an escalation decision while acknowledging uncertainty. That is stronger than a narrative written backwards to justify a predetermined outcome.

Case notes should also avoid unnecessary sensitive commentary. They are professional records, potentially reviewable by supervisors, auditors, legal teams or courts. Personal speculation, humour, emotional language and unsupported allegations do not belong in them. Nor should analysts copy large amounts of personal data simply because it is available. The note should preserve what is necessary to explain the decision and link to controlled evidence where more detail is required.

A defensible case-note structure

The exact screen design varies, but a practical note can answer these questions in sequence: What triggered the review? What customer or relationship was in scope? What period was examined? What material evidence was reviewed? What behaviour or risk indicators were present? What explanations or mitigating facts were considered? What gaps remained? What conclusion was reached? Who approved it if approval was required? What follow-up action was taken?

That sequence is valuable for business analysts because it can be translated into requirements. For example, the case platform can require a review period, provide structured links to customer and transaction records, distinguish evidence attachments from analyst text, capture decision reason codes, require an approval for specified outcomes, preserve revisions and prevent silent overwriting of closed-case rationale.

Structured fields and narrative should complement each other. Structured fields enable search, MI and consistent control logic. Narrative explains context that a code cannot capture. A closure reason of EXPECTED_ACTIVITY is useful for reporting, but the narrative should still explain why the observed activity was consistent with the customer profile. Conversely, a five-paragraph note with no structured decision code makes population-level quality analysis difficult.

Global standards and why retention periods differ

The Financial Action Task Force provides the global baseline. FATF Recommendation 11 expects financial institutions to maintain necessary transaction records for at least five years and to keep relevant customer-due-diligence material, account files, business correspondence and analysis results for at least five years after the business relationship ends or the occasional transaction is completed. The records should be sufficient to reconstruct individual transactions and should be available to competent authorities.

That is a global standard, not a universal instruction to configure every bank record for exactly five years. Domestic and regional rules determine the legal obligation that applies to a particular entity, record class and event. A global bank therefore needs a retention schedule that maps legal entities, jurisdictions, products and record types rather than a single hard-coded number.

The United States provides one clear example. FinCEN guidance for Suspicious Activity Reports requires covered financial institutions to retain a copy of a filed SAR and the original or business-record equivalent of supporting documentation for five years from the filing date and to make supporting documentation available to appropriate authorities on request. That is a specific US BSA/SAR requirement. It should not be presented as a global SAR rule.

The United Kingdom's Money Laundering Regulations contain their own record-keeping framework. UK government guidance describes a five-year period linked to the end of a business relationship or completion of an occasional transaction for relevant records, subject to the detailed conditions in the legislation and other lawful retention requirements. UK implementation also demonstrates why over-retention matters: records collected for AML purposes are not simply meant to be held indefinitely because storage is cheap.

Australia illustrates the danger of assuming five years everywhere. Current AUSTRAC guidance under the Australian AML/CTF framework describes seven-year retention periods for important categories of customer-due-diligence and transaction records, with the trigger depending on the record type. A bank operating in Australia therefore cannot safely inherit a global default of five years without local legal mapping.

The European Union is also changing. Regulation (EU) 2024/1624, the new AML Regulation, contains Article 77 on record retention, including CDD information, transaction evidence, records of suspicious-activity assessments and certain information-sharing records. Its main application date is 10 July 2027, so in September 2026 it must be described as a future directly applicable framework rather than as if every EU institution is already operating under Article 77. Current national implementing law remains relevant until the new regime applies, and transition must be managed carefully.

This jurisdictional comparison teaches an important design lesson: store the reason for a retention rule, not only the expiry date. If a record is tagged retain_until = 2033-04-12 with no legal basis or trigger, future teams cannot confidently recalculate the date when laws, relationships or case status change.

Build a retention schedule, not a single retention period

A retention schedule connects a record class to its legal and operational lifecycle. It should identify the type of record, owning function, jurisdiction or legal entity, lawful basis, start trigger, normal retention period, possible extensions, hold conditions, approved storage locations, access restrictions and disposal method.

Typical financial-crime record classes include KYC/CDD evidence, screening events, transaction-monitoring alerts, investigation cases, SAR/STR records, sanctions decisions, customer communications, transaction records, quality-assurance samples, model or scenario versions, training and governance evidence, and records received from law enforcement or regulators. Their retention requirements may differ.

The trigger is as important as the duration. "Five years" means little unless the bank knows whether the clock starts at transaction completion, business-relationship termination, report filing, case closure, document creation or another legally defined event. Some records have more than one relevant trigger. A long-standing customer relationship can mean that CDD information must remain available long after the document was first collected.

Retention rules should be versioned. If law changes on a specified date, the bank may need different treatment for records created before and after that date, or a migration plan for existing populations. The legal interpretation should be approved by the responsible function and translated into configuration through controlled change management, not entered informally by a developer who reads a regulation in isolation.

Legal holds and preservation: when the normal clock must stop

A legal hold is a controlled instruction to preserve records that would otherwise be eligible for disposal. It may arise from litigation, regulatory examination, law-enforcement request, internal investigation, enforcement matter or another legally recognised reason. Terminology and authority vary, but the operational principle is consistent: the retention engine must not delete relevant records simply because the normal date has arrived while a valid preservation obligation remains in force.

A hold needs scope. It may apply to a customer, account, employee, product, time period, case population or document category. Overly narrow holds risk deletion of relevant material. Overly broad holds can preserve vast amounts of data indefinitely. Legal, compliance, records-management and technology teams therefore need a controlled way to define the population, apply the hold, test that it is effective, update it when scope changes and release it when authorised.

The hold should be auditable. The bank should know who authorised it, when it began, what records were included, whether any records were already past their scheduled expiry, which systems received the hold instruction, and when the hold was released. A release is not merely a flag change; systems may need to re-evaluate each record against the current retention schedule before disposal.

Backups complicate the issue. A bank may not be able to delete one customer record instantly from every immutable backup. The retention design should document how backup lifecycle, restoration and subsequent deletion work under applicable law and policy. It should not promise impossible real-time erasure if the architecture does not support it, but it must still have a defensible and tested process.

Immutability, versions and audit history

A case-management system should not allow a material decision to be silently rewritten after closure. Corrections are sometimes necessary, but they should create an audit trail: original value, corrected value, author, timestamp, reason and approval where required. This is especially important for narratives, decision codes, filing indicators and links to evidence.

"Immutable" does not always require a specialised blockchain or write-once storage technology. It means the record cannot be changed without the change being detectable and attributable under the bank's control model. Append-only event history, controlled versions, write-once archives, content hashes, database audit logs and segregated permissions can all contribute. A cryptographic hash can help detect alteration, but a hash alone does not prove that the original record was accurate or legally admissible. It is one integrity mechanism, not a complete evidence strategy.

The same principle applies to configuration evidence. If an investigation relies on a transaction-monitoring alert, the bank should be able to identify the scenario or model version that produced it. If a sanctions decision relied on a list match, the list version and screening configuration may matter. Control configuration can itself become evidence.

Access control and confidentiality

Financial-crime files routinely contain sensitive personal, commercial and law-enforcement-related information. SAR or STR material can be subject to strict confidentiality restrictions. Access therefore needs to be based on role, purpose and local law rather than broad operational convenience.

Least-privilege design should separate investigators, quality reviewers, relationship managers, system administrators and other users according to what they genuinely need. Privileged administrators may require technical access to maintain systems, but that does not automatically justify business-level visibility of suspicious-report content. Sensitive exports and bulk downloads need particular attention because they can bypass the controls present in the case screen.

Access itself should be logged. A bank facing an insider-risk event may need to know who viewed or exported a case. Monitoring should focus on meaningful indicators such as unusual access volumes, access to unrelated high-profile customers, repeated exports or attempts to reach restricted report data.

Confidentiality also shapes customer communication. A case note may contain material that should never appear in customer-facing channels. Architecture should prevent internal financial-crime narratives from being copied automatically into payment-rejection messages, CRM notes visible to front-line staff, customer statements or complaint responses without appropriate review.

Retrieval is part of retention

Keeping a record that cannot be found is not effective retention. Regulatory and law-enforcement requests can require the bank to locate historic material quickly across systems that may have been replaced since the original event. Retrieval therefore needs service ownership, search keys, archive indexes and tested restoration procedures.

A mature archive supports more than a customer name. Names change and may be transliterated differently. Useful retrieval keys can include customer identifiers, account numbers, payment identifiers, case and alert IDs, report reference numbers, legal-entity identifiers and date ranges. Search permissions must still respect confidentiality.

Migration is a major risk. When a case platform is retired, teams often focus on moving open cases and underestimate closed-case evidence. A successful migration must preserve attachment links, notes, authorship, timestamps, decision history, source identifiers, retention metadata, holds and access restrictions. If historic records are converted to a new format, the bank should preserve enough metadata to prove what was migrated and whether anything failed.

Archive testing should include restoration, not merely confirmation that files exist. A backup that has never been restored is an assumption. Testers should select old cases, retrieve the complete evidence package, verify readability and metadata, and confirm that access controls still operate.

Data minimisation and the danger of keeping everything

Financial-crime teams sometimes respond to retention uncertainty by keeping everything forever. That is not a mature solution. Retaining unnecessary personal data creates privacy, cyber-security, discovery and operational risk. It also makes important evidence harder to distinguish from noise.

A well-designed case captures enough information to support the control purpose and required legal obligations. It does not need uncontrolled copies of every customer document in every downstream system. Where stable references to an authoritative archive are reliable and immediately retrievable, references may be preferable to duplicates. Where the authoritative source can change or be deleted before the financial-crime retention period ends, a controlled snapshot may be necessary.

Deletion also needs evidence. A record should not simply disappear with no trace of the disposition process. Records-management systems may maintain non-content metadata showing that a class of records reached expiry, was checked for holds, was approved for disposal and was deleted according to policy. The bank needs enough evidence to show that disposal was controlled without retaining the personal content it was required to delete.

Operational failure modes

Several failures recur across banks. The first is narrative without evidence: analysts write persuasive conclusions but cannot reproduce the facts. The second is evidence without narrative: dozens of attachments are stored but nobody explains which ones mattered. The third is current-state substitution: a later KYC or sanctions status is mistaken for the state that existed when the transaction occurred. The fourth is silent overwrite: case notes or decision codes change without history. The fifth is unmapped retention: all records inherit a global default despite different legal triggers. The sixth is archive without retrieval: data exists but cannot be restored within a useful time. The seventh is hold failure: automated deletion continues even though a preservation instruction exists. The eighth is over-retention: data remains indefinitely because nobody owns disposal.

Another important failure is evidential fragmentation. A case may contain a transaction spreadsheet, an email from the relationship manager and a screening screenshot, while the original payment record remains in a separate archive with no stable link. Years later, the spreadsheet cannot be reconciled because transaction IDs were removed during export. This is why evidence identifiers and lineage should be designed into the workflow rather than added during an examination.

Capacity pressure can also damage evidence quality. When alert backlogs grow, analysts may copy previous notes, use vague closure language or skip source citations. Quality metrics should therefore look beyond throughput. Repeat-note patterns, missing evidence links, unusually short reviews, post-closure edits and inconsistent decision reasons can indicate process weakness.

BA and architecture considerations

A business analyst should treat evidence and retention as cross-functional requirements. Compliance defines the control objective and local obligations. Legal and records-management teams interpret retention and preservation requirements. Data owners define authoritative sources. Architects design lineage, archive and access. Developers implement workflow and controls. Operations use the system. Quality assurance and internal audit test whether the result remains defensible.

Requirements should be testable. "Keep sufficient evidence" is not enough. Better requirements define mandatory identifiers, supported evidence types, point-in-time fields, version history, maximum attachment size, source-system links, timestamp standard, access roles, retention classification, hold behaviour, archive retrieval and disposal evidence.

Time is a technical requirement. Systems should use consistent timestamps with clear time-zone handling. Daylight-saving changes, local midnight boundaries and delayed batch loads can alter a chronology. Store event time and processing time separately where both matter. Preserve the source timezone or use an agreed normalised standard while retaining enough metadata to reconstruct local context.

Identity is another requirement. Customer IDs can merge or split during data-quality remediation. Accounts can migrate between platforms. A stable enterprise identifier or cross-reference table is needed so historic cases do not lose their subject when source-system identifiers change.

Data lineage should include transformations. If a monitoring engine converts currencies, aggregates accounts or excludes internal transfers, the case should be able to identify the logic or version that produced the alert. This does not mean attaching source code to every case; it means maintaining controlled configuration and traceability outside the case so that a reviewer can reconstruct the process when necessary.

Testing the evidence lifecycle

Testing should prove both preservation and controlled deletion. Positive tests confirm that a closed case remains retrievable throughout its retention period, that notes and attachments retain authorship and timestamps, and that a legal hold prevents scheduled disposal. Negative tests confirm that unauthorised users cannot view restricted content and that an expired record with no valid hold is actually disposed according to policy.

Historical replay is especially valuable. Create a test case using a known past state, then change customer data, scenario configuration or ownership. Reopen the case and verify that the original evidence remains understandable. This catches current-state substitution defects before they appear in a real investigation.

Migration tests should compare source and target populations, metadata counts, attachment hashes where appropriate, decision codes, timestamps, note versions and hold flags. Sampling alone may miss systematic omissions, so reconciliation totals and exception reports are important. Any failed record should enter a controlled remediation queue rather than vanish from the migration summary.

Access-control tests should include ordinary users, supervisors, quality reviewers, system administrators and users from other legal entities. Test bulk export as well as screen access. A user who cannot open a SAR in the application but can query the underlying warehouse has not been effectively restricted.

Retrieval tests should simulate an authorised regulator or law-enforcement request. Can the bank locate the relationship, relevant transactions, case decision and supporting material for an old period? Can it explain gaps? Can it export records without exposing unrelated sensitive customers? Can it prove who fulfilled the request and what was disclosed?

Practical mini case: the case that returned four years later

A small import company triggers a monitoring alert after receiving several high-value incoming transfers from counterparties in different countries and sending most of the value to a new supplier within forty-eight hours. The investigator reviews the customer's KYC profile, historic payment activity, invoices supplied by the customer, the payment-message data and a prior screening alert that had been resolved as a false positive. The company explains that it has started acting as a procurement intermediary for a larger group.

The analyst finds that the new activity is unusual but commercially plausible. Two counterparties are consistent with the invoices, one payment is unrelated, and the customer cannot immediately explain it. The case is escalated for additional review. After further evidence is obtained, the bank reaches the reporting decision required under its local framework and applies separate relationship-management actions. The case file records the transaction population, original payment identifiers, customer profile as it existed during the period, documents received, contradictory facts, escalation chronology, decision approval and references to any report filed. Sensitive reporting details remain restricted.

Four years later, an authorised law-enforcement request asks for information about one of the counterparties. The bank's current customer profile is very different: ownership changed, the business moved address and the original investigator left the bank. Because the case retained point-in-time KYC data, source transaction identifiers and versioned notes, the new investigator can reconstruct the old decision. The archive retrieves the relevant payment records and supporting documents. Access logs show who viewed the restricted material. The response team can provide authorised records without exposing unrelated case content.

The scenario demonstrates why retention is not simply storage. If the bank had retained only the final case status, the historic reasoning would be lost. If it had retained only screenshots, the transaction population might be impossible to reproduce. If it had overwritten the customer's old profile, the later reviewer might reach a different conclusion using facts that did not exist at the time. If it had no retrieval index, the records could technically exist and still be operationally useless.

Governance and ownership

The first line usually owns correct creation and handling of investigation records. Financial-crime compliance defines minimum evidence and decision standards and challenges weaknesses. Records-management and legal functions own or advise on retention schedules, preservation holds and lawful disposal. Technology owns the reliable operation of case, archive and access-control platforms. Data owners maintain authoritative sources and lineage. Quality assurance tests files. Internal audit independently assesses whether governance and controls are designed and operating effectively.

Senior governance should see more than the number of archived cases. Useful management information includes evidence-quality defects, missing attachments, inaccessible archives, post-closure changes, hold failures, overdue disposals, retrieval times, migration exceptions, access anomalies and recurring QA findings. These metrics reveal whether the bank could defend decisions, not merely whether a retention job ran overnight.

Policy should also make exceptions explicit. If a source system cannot preserve historic values, the bank needs a compensating snapshot or archive. If a jurisdiction requires longer retention, the global platform needs a local override. If a regulator requires preservation beyond normal expiry, the hold process must work across all relevant systems. Exceptions should have owners, risk acceptance where appropriate, remediation dates and evidence of closure.

What good looks like

A strong evidence and retention environment is almost invisible during an ordinary investigation. Analysts can see the relevant customer and transaction context without hunting across uncontrolled folders. Evidence links carry stable identifiers. Notes distinguish facts from judgement. Decisions preserve approvals and prior versions. Sensitive reports are appropriately restricted. Retention dates are calculated from a documented rule and trigger. Legal holds override disposal. Archived records can be restored. Expired material is deleted through a controlled process.

The real test comes later, when someone who was not part of the original case asks a difficult question. If that person can reconstruct what the bank knew, why it acted, which records supported the decision, and whether those records were preserved and disclosed lawfully, the control has done its job.

Key takeaways

Evidence quality, case-note quality and record retention are one connected control. A bank should preserve material facts and provenance, not just screenshots or conclusions. Historic decisions need point-in-time context. Retention periods and triggers vary by jurisdiction and record type; FATF's five-year benchmark is not a universal configuration value. Legal holds must be able to suspend normal disposal. Access to sensitive investigations and SAR/STR information should be tightly controlled and logged. Retrieval, migration and disposal must be tested just as seriously as storage. For delivery teams, the most important question is simple: could an authorised reviewer reconstruct this decision accurately years later without guessing?

References and further reading

The detailed source list used for this chapter is maintained in the companion references section loaded with this topic. It prioritises FATF, official EU law, FinCEN and FFIEC material, UK government guidance and AUSTRAC guidance, and clearly distinguishes global standards from jurisdiction-specific requirements.

Operational deep dive: building a reconstructable investigation record

The base chapter explains the evidence lifecycle. This deep dive moves closer to the operating model: how records are selected, how point-in-time context is preserved, how notes become reproducible analysis and how a bank avoids discovering years later that its archive contains files but not an intelligible decision.

Start with the control question, not the attachment folder

Investigators can easily over-collect. A case begins with one alert and finishes with dozens of screenshots, spreadsheets, emails and downloaded documents, many of which were never used in the decision. This creates the appearance of thoroughness without improving evidential quality. A better approach begins with the control question.

If the question is whether a customer's activity is consistent with its expected business, the evidence should establish the customer profile, the transaction population, material counterparties and relevant explanations. If the question is whether a payment involved a sanctioned party, the evidence should show the screened data, list source and version, match attributes, ownership or control analysis where applicable, payment state and legal decision. If the question is whether suspicious reporting is warranted, the file needs the facts and reasoning that support or weaken suspicion under the applicable local framework.

The case should therefore have an evidence inventory rather than a random attachment pile. Each material item can be associated with a category, source, date or effective period, source identifier, case relevance and any limitation. The inventory does not need to be presented to the user as a complex table, but the underlying metadata should be available to the workflow.

This discipline also helps with data minimisation. Teams collect what is relevant to the investigation and preserve references to controlled source repositories where appropriate instead of copying whole customer files into every downstream case.

Evidence provenance and confidence

Provenance answers where the information came from and what happened to it before the analyst used it. It matters because two records that appear identical on screen can have very different reliability.

Consider an ownership percentage. One value may come directly from a verified corporate register, another from customer self-declaration, another from a commercial data provider, and another from an analyst's manual calculation across several entities. Each can be useful, but the reviewer should know the source and date. If an analyst combines ownership paths to assess sanctions exposure, the derived result should identify the underlying entities and percentages rather than replacing them with a bare conclusion.

Provenance should also capture transformation. Transaction-monitoring platforms frequently aggregate or normalise data. Amounts may be converted to a base currency. Transactions can be grouped by counterparty. Internal transfers may be excluded. Customer IDs can be mapped from several source systems into one enterprise identifier. The case does not need every technical transformation in the narrative, but the bank needs controlled lineage so the output can be reproduced.

A useful architecture separates three layers:

1. Source evidence such as the original transaction, message, CDD document or screening event.
2. Derived evidence such as aggregates, risk scores, network links, peer comparisons or transaction summaries.
3. Human judgement such as the analyst's interpretation, suspicion assessment or recommended outcome.

The layers should be linked but not blended. When derived evidence is later recalculated by a newer model or scenario version, the original result that informed the decision should remain recoverable.

Point-in-time reconstruction in changing systems

Historic reconstruction requires more than retention of documents. It requires temporal data design.

Customer information is particularly difficult. A KYC system often exposes the latest value because that is what onboarding and servicing teams need. Investigation and audit use cases are different: they may need to know the value that was effective during a past transaction period and the value the bank actually knew at the time of the review. Those dates can diverge.

For important attributes, consider storing or making retrievable:

• the value;
• effective-from and effective-to dates where available;
• date received by the bank;
• date loaded or approved;
• source and verification status;
• record version;
• user or process that changed it.

This does not mean duplicating the entire KYC platform inside the case system. A temporal source system or data warehouse may already provide history. The case needs stable references and, for material decision facts, a snapshot or evidence package that survives the source's normal lifecycle.

Sanctions and PEP screening have their own point-in-time needs. Lists change frequently. A current re-screen can answer whether a party is listed today; it cannot prove what the screening engine saw on the original payment date. Where the decision depends on list state, the bank should preserve list-provider version or effective date, screened values, match result and disposition. Similar logic applies to transaction-monitoring scenarios and models: scenario version, threshold or model release may be important when explaining why an alert did or did not occur.

Payments can be transformed across a chain. The customer instruction, enriched payment hub representation, screening payload, clearing message and reporting warehouse record may differ. When an investigation concerns a specific field or screening outcome, evidence should identify the representation relied upon. A generic data-lake extract is not always a substitute for the exact payload that the control consumed.

Notes that survive challenge

A case note should allow a competent reviewer to reach the analyst's logic without having to infer missing steps. This does not require a long essay for every low-risk alert. It requires enough specificity to show what was checked and why the conclusion follows.

A practical note can use a simple reasoning sequence:

Trigger. Why was the activity reviewed? Identify the alert, referral, screening event, law-enforcement information or other trigger.

Scope. What period, accounts, products, counterparties and transactions were reviewed? State exclusions if they matter.

Material facts. Summarise relevant evidence with source references. Avoid copying every transaction into prose when a controlled transaction schedule is available.

Analysis. Explain why the pattern is or is not consistent with known activity and what typologies or risk factors are relevant. Distinguish observation from inference.

Contrary information. Record credible explanations, documentation or facts that weaken the concern. If evidence is unreliable, explain why.

Gaps. Identify unresolved information and whether the gap changes the decision.

Decision. State the conclusion under the applicable policy and local rules, including approval where required.

Actions. Capture follow-up such as enhanced due diligence, monitoring, sanctions escalation, fraud referral, suspicious reporting, relationship review or no further action.

This format discourages two poor habits: writing an unstructured diary of every click and writing a conclusion so brief that nobody can reproduce it.

Notes should not claim legal certainty unless the responsible function has made a legal determination. An AML investigator might write that behaviour is suspicious or unexplained; they should not casually label a customer a criminal. Likewise, a sanctions analyst should distinguish a name match from a confirmed designated-party exposure and from a legal conclusion about whether a prohibition applies.

Corrections after case closure

Financial-crime records sometimes need correction. An investigator may discover a wrong transaction amount, a misspelled customer name or an incorrect disposition code. The solution is not to prohibit all changes; it is to make changes traceable.

Closed-case changes should preserve the prior value, new value, author, time, reason and approval according to risk. Material changes may require the case to be reopened or re-approved. If a correction affects a regulatory report already filed, the reporting team should assess whether the jurisdiction requires an amendment, supplemental filing or other action. That decision belongs to the applicable local reporting framework, not a universal workflow assumption.

A technical updated_at timestamp is not enough if the prior narrative is lost. Version history should allow a reviewer to see what was originally recorded. This is especially important when the later correction follows a complaint, regulator query or law-enforcement request; otherwise the bank can appear to have rewritten history.

SAR and STR supporting records

Suspicious reporting creates additional sensitivity. The precise documents that must be retained, retention period, disclosure restrictions and authority access rights vary by jurisdiction. A global bank should keep those rules in local legal and policy mapping rather than assuming every FIU uses the same approach.

The United States provides a clear example. FinCEN guidance states that a covered financial institution filing a SAR must retain a copy of the SAR and the original or business-record equivalent of supporting documentation for five years from filing and make supporting material available to FinCEN and appropriate law-enforcement or supervisory agencies on request. The supporting material consists of records that helped the institution reach the reporting determination. This is a US-specific requirement under the Bank Secrecy Act framework.

Operationally, this means the case platform should know which evidence is considered supporting documentation for the filing, even if the material is not transmitted with the SAR. A supporting_evidence = true classification, controlled report-to-case link or equivalent design can prevent the bank from losing the connection after case closure.

Other jurisdictions use different terminology and processes. Some FIUs expect supporting information to be supplied through separate channels or follow-up requests. Some reporting regimes have different confidentiality rules. The bank should preserve the link between the internal decision, external report reference and supporting file while restricting visibility to authorised roles.

Retention clocks need event logic

A retention engine is effectively a rules engine. A duration alone cannot calculate an expiry date without a trigger.

Consider four different records:

• A transaction record may have a clock tied to transaction completion or record creation.
• CDD records may have a clock tied to the end of the business relationship.
• A SAR supporting record may have a clock tied to filing under a particular jurisdiction's rule.
• A training record may have a separate corporate or regulatory schedule.

The same case can therefore contain records with different normal retention dates. If the bank simply assigns the case closure date to everything, it can delete some records too early and retain others longer than necessary.

Retention configuration should identify the legal entity, jurisdiction, record class, rule version, event trigger, period and exceptions. The system should calculate the date only when the relevant trigger is known. If a relationship is still active, the CDD retention clock that starts on termination should not be guessed.

Rules change over time. The configuration needs effective dates so historic records can be treated correctly. A change process should determine whether a new rule applies only prospectively or also to existing populations. This is a legal interpretation and records-management decision, not merely a database setting.

Global examples show why one number is unsafe

FATF Recommendation 11 establishes the international expectation that transaction and relevant CDD records be kept for at least five years and be sufficient to reconstruct transactions and respond to competent authorities. That benchmark shapes national frameworks but does not erase local differences.

UK government guidance under the Money Laundering Regulations describes five-year retention from the end of a business relationship or completion of the relevant transaction for specified records, with statutory qualifications and data-protection obligations. HMRC's current supervision material also emphasises that keeping regulated records longer than permitted without a lawful reason can itself be a problem.

Australian AUSTRAC guidance, updated in 2026 for the changing AML/CTF framework, describes seven-year periods for important CDD and transaction record classes, with different triggers. This is a concrete reason why a global platform should not encode AML_RETENTION = 5 YEARS as a universal rule.

The EU's new Regulation (EU) 2024/1624 contains a detailed Article 77 record-retention regime, including records of assessments whether or not a suspicious report was ultimately filed. However, its main application date is 10 July 2027. In September 2026, implementation programmes can prepare for it, but current obligations must still be derived from the law that presently applies to the institution and jurisdiction.

The common design lesson is more valuable than memorising a number: retention is a legal mapping problem expressed through data and workflow.

Legal hold design across distributed platforms

A legal or regulatory hold can be technically difficult because a financial-crime case may reference records in many platforms. Marking the case on_hold does not automatically stop deletion in a payment archive, email platform, data lake or third-party vendor system.

A robust hold process first identifies the systems and record classes in scope. It then sends a controlled preservation instruction, receives confirmation and monitors exceptions. If a system cannot implement a granular hold, the bank needs an approved compensating approach such as an export to a preservation repository or broader temporary retention.

Holds need unique identifiers and lifecycle status. Useful fields include hold ID, authority or reason, request owner, scope, effective date, related matter or case, systems notified, acknowledgement status and release authority. Sensitive legal details may be restricted while the technical system still receives enough information to preserve the correct records.

Testing should deliberately place a record near expiry, apply a hold and verify that deletion does not occur. After authorised release, the system should recalculate the normal schedule rather than automatically delete everything immediately. A record may now fall under a newer or different retention requirement.

Vendor contracts matter. If a case platform or screening provider stores evidential data, contracts and technical design should address retention configuration, export, legal hold, deletion, audit evidence, subcontractors and service exit. The bank remains responsible for understanding whether its records can be preserved and retrieved even when the storage is outsourced.

Archive retrieval and evidential completeness

An archive should be designed around retrieval use cases. A regulator may ask for records relating to a named customer. Law enforcement may provide account numbers or transaction references. Internal audit may select cases by scenario and date. Legal teams may identify a set of employees or counterparties. The archive index should support appropriate keys without weakening access control.

Retrieval should produce a complete but scoped evidence package. It should not expose every unrelated case for the same customer if the request does not authorise that disclosure. This is where case segmentation, record classification and export controls matter.

The bank should know the difference between data unavailable because it was lawfully disposed and data unavailable because the archive failed. An authorised disposition log can explain the former. A missing archive index or corrupt attachment is a control failure.

Operational service levels should reflect the legal and supervisory environment. There is no universal number of hours that every authority allows, so the chapter does not invent one. Instead, each jurisdiction and request type should map to required or internally approved response timelines, with escalation if retrieval cannot be completed.

Migration and decommissioning: the hidden retention project

System migrations are among the highest-risk moments for historic evidence. Project plans often emphasise open cases because they affect current operations. Closed cases can be treated as low priority even though regulators and law enforcement may request them years later.

Migration acceptance criteria should cover more than row counts. A complete financial-crime migration can include:

• case and alert identifiers;
• subject and account relationships;
• notes with authorship and timestamps;
• attachments and source references;
• decision history and approvals;
• report links and confidentiality classification;
• retention rule, trigger and expiry metadata;
• legal holds;
• access entitlements;
• audit logs where required;
• integrity checks for migrated files.

Population reconciliation should identify missing, duplicate and unreadable records. A failed attachment should not be counted as a successful case migration merely because the case header arrived.

If historic cases remain in a read-only legacy archive rather than being migrated, the bank still needs ownership, access, backup, security patching, retrieval testing and a decommissioning plan. "Read only" is not the same as "risk free".

Evidence quality assurance

Quality assurance should test whether the file can be reconstructed, not only whether mandatory fields are populated. A note can technically contain text in every field and still be meaningless.

A practical QA review asks: Is the trigger clear? Is the scope defined? Can the transaction population be reproduced? Are source references present? Are material facts distinguished from interpretation? Is contradictory evidence addressed? Does the decision follow logically from the analysis? Are approvals visible? Are sensitive records appropriately restricted? Is retention classification correct? Can attachments be opened?

QA findings should be coded so the bank can identify systemic issues. Repeated missing source identifiers may point to a UI defect. Weak rationale may indicate training or capacity pressure. Historic-data errors may reveal a data-model gap. Incorrect retention tags may indicate configuration or legal-mapping issues.

The feedback loop should reach the responsible owner. Evidence-quality defects are not only investigator performance problems. They can be caused by missing source data, badly designed screens, broken links, unclear procedures or unrealistic workload expectations.

A second practical example: sanctions decision evidence

A corporate payment creates a possible sanctions match on an intermediary name. The screening analyst uses the payment payload, customer information, the sanctions-list record, ownership information and additional identifiers to determine whether the match is false or requires escalation.

The evidence record should preserve the screened string, relevant payment fields, list source and version, matched entity identifiers, attributes used to distinguish the party, analyst rationale, any legal or specialist escalation and final payment action. If the payment is released, the file should explain why the possible match was not the listed party or why the applicable restriction did not prohibit the transaction. If the payment is blocked, rejected or otherwise restricted, the required evidence and reports depend on the sanctions regime and local implementation.

Years later the list record may contain additional aliases and identifiers. Re-screening today's data cannot replace the historic evidence. The bank needs the original screening context to explain the old decision fairly. This is point-in-time reconstruction in practice.

Operating principles to carry into delivery

The strongest implementation follows a small number of durable principles. Preserve provenance. Keep point-in-time context. Link source records through stable identifiers. Separate fact from judgement. Make corrections visible. Configure retention by record class, jurisdiction and event trigger. Allow legitimate holds to stop disposal. Test archive retrieval. Restrict sensitive records by role and purpose. Delete records through a controlled process when no lawful retention reason remains.

Those principles make the case file useful not only to compliance. They give architects clear data requirements, developers concrete workflow behaviour, testers meaningful scenarios, records teams auditable lifecycle controls and investigators a practical standard for professional judgement.

Advanced practice: assurance, architecture and change control

Evidence and retention controls become difficult when they intersect with real technology estates: multiple legal entities, shared platforms, cloud archives, outsourced services, payment migrations, evolving sanctions lists and changing privacy rules. Advanced practice is less about writing another policy and more about proving that the complete evidence lifecycle continues to work when the environment changes.

Convert legal obligations into a retention rule model

A global bank usually begins with legal interpretation and records policy, but technology needs a rule model. The model should be explicit enough that a business analyst can trace each configured behaviour back to an approved requirement.

A practical retention rule contains at least these concepts:

Record class. What is being retained: transaction evidence, CDD evidence, screening result, investigation case, suspicious-report record, quality review, model evidence or another defined class.

Legal entity and jurisdiction. Which bank entity created or controls the record and which rules apply. Customer residence alone is not necessarily the determining factor.

Legal or policy basis. The approved source of the requirement, not merely a number copied into configuration.

Trigger. The event that starts the clock: transaction completion, relationship termination, report filing, case closure, record creation or another event.

Duration. The normal retention period after the trigger.

Extension conditions. Circumstances in which a regulator, law-enforcement authority, court, legal hold or another lawful requirement changes normal disposal.

Effective dates. When the rule begins and, if replaced, when it stops applying.

Disposition method. What happens at expiry: deletion, destruction, anonymisation or another approved process.

This data model matters because laws evolve. If the bank stores only an expiry date, it loses the reasoning needed to recalculate populations after change. If it stores rule ID, version and trigger, change impact can be analysed systematically.

The rule engine should not manufacture a trigger that has not occurred. A CDD record whose clock begins when a business relationship ends cannot receive a valid expiry date while the relationship remains active unless policy uses another lawful basis. Requirements should identify how open-ended records are represented and how the end event is received from source systems.

Jurisdiction-aware examples without false universality

FATF Recommendation 11 provides the international baseline of at least five years for necessary transaction records and relevant CDD material, with enough information to reconstruct transactions and respond to competent authorities. It does not mean every implementation has the same trigger or period.

In the United States, FinCEN's SAR framework requires retention of the SAR and supporting documentation for five years from filing. That is a specialised filing-related rule.

Current UK government guidance under the Money Laundering Regulations describes five-year retention for specified CDD and transaction records from the relevant statutory trigger, while also addressing circumstances in which continued retention may or may not be lawful. The detailed rule must be taken from the applicable UK legislation and approved policy.

AUSTRAC's 2026 guidance demonstrates a different pattern: important Australian CDD and transaction record classes can carry seven-year periods, and their start points differ. A multi-country platform therefore needs local configuration rather than a global constant.

The EU's Regulation (EU) 2024/1624 will add a directly applicable Article 77 record-retention regime from 10 July 2027. Implementation teams in 2026 may build toward that future state, but production requirements today should still be based on the law presently applicable to each institution. This temporal distinction should appear in change requirements so a future rule does not accidentally go live early.

The evidence object: design for traceability

A reusable evidence object can make investigations more consistent across products. It does not need to force every source into the same payload, but it can standardise metadata around the item.

Useful metadata includes evidence ID, case ID, source system, source record ID, evidence category, subject or transaction relationship, event date, effective date if relevant, capture date, original format, content location, checksum or integrity value where used, classification, access restriction, retention rule ID, hold status and version.

This object should not become a duplication engine. The content may live in an approved source archive while the case stores the reference and critical snapshot metadata. Where the source cannot guarantee historic availability or immutability for the required period, the evidence service may need to preserve a controlled copy.

Architecture should make broken links visible. A source reference that returns 404 or permission failure years later is a retention defect, not a harmless user-interface issue. Scheduled integrity checks can sample or validate evidence locations before an examination reveals the problem.

Preserve raw and derived evidence differently

Raw and derived evidence have different lifecycle needs. A payment message is a source event. A transaction-flow graph is generated from many source events. A model score is an output of a particular model version. A narrative summary is human-created analysis.

For derived evidence, preservation should include enough information to understand the transformation. A model score without model version, a graph without source transaction IDs or a currency-normalised total without the conversion basis can become uninterpretable.

This is especially important with machine learning and network analytics. Re-running the model years later can produce a different result because training data, features or code changed. The case should preserve the result used at the time and the model or configuration identifier that generated it. The broader model-governance repository can retain technical documentation; the case need only maintain a reliable link.

Case-note usability requirements

A technically perfect archive can still fail if notes are poorly designed. User experience influences evidential quality.

Free-text fields should encourage structured reasoning without forcing investigators into repetitive boilerplate. Templates can provide prompts such as trigger, scope, material findings, explanations considered, unresolved gaps and decision rationale. The system should not automatically generate generic sentences that analysts accept without thinking; that produces uniform-looking files with little actual reasoning.

Evidence citation should be easy. If an analyst must manually copy a long transaction identifier into prose, citations will be skipped. The case interface can allow the reviewer to select a transaction, document or screening event and insert a stable evidence reference. The narrative remains readable while the evidence is one click away for authorised users.

The interface should also preserve draft versus final status. A partial note written during research should not be mistaken for the final conclusion. Finalisation can lock or version the narrative, capture approval and record the effective decision time.

Testing requirements for business analysts and QA teams

Evidence and retention controls need scenario-based testing. The following tests provide strong coverage.

Point-in-time customer change

Create a case using customer ownership, address and risk rating version A. Close the case. Change those values to version B. Reopen or retrieve the old case and confirm the investigator can still see or reconstruct the material version-A evidence. Fail the test if the case silently displays only current values without indicating the historical state.

Sanctions-list version change

Create a screening event against a controlled list version. Add an alias or modify the list record later. Confirm the old case retains the original screened data, list reference and disposition context. A current re-screen may be shown separately but must not overwrite the original event.

Retention trigger test

Create records for an active relationship and an occasional transaction. Confirm that the configured clocks start from the correct trigger. Change the relationship to terminated and verify that the expiry date is calculated from the approved event date. Test leap years and time-zone boundaries where date arithmetic could matter.

Legal-hold test

Place a record within days of normal expiry. Apply a hold that covers the record. Run the disposition process and verify that the record is not deleted. Release the hold through an authorised workflow and confirm the record is re-evaluated against the current rule rather than bypassing normal controls.

Access and confidentiality test

Use investigator, supervisor, front-office, administrator and cross-entity test accounts. Verify that each role can see only appropriate evidence. Test API access, exports, reporting warehouses and search indexes as well as the user interface. Restricted SAR or STR information should not become visible simply because a user has technical reporting access.

Archive restoration test

Retrieve a closed case several years old or an equivalent test archive. Verify notes, attachments, source identifiers, timestamps, decisions and hold metadata. Confirm file formats can still be opened. An archive that returns an unreadable proprietary format has not met the practical objective.

Disposal test

Create an eligible expired record with no hold and confirm it is removed according to the configured process. Confirm disposition evidence remains without retaining the substantive personal content that should have been deleted. Also test the negative case: a not-yet-expired record must not be deleted.

Migration test

Move a controlled population to a new platform. Reconcile record counts, attachments, notes, versions, report links, retention metadata and holds. Inject a failed attachment deliberately and ensure the migration produces an exception rather than marking the case complete.

Data-quality controls for evidence systems

Evidence-quality data checks should include completeness, uniqueness, validity, timeliness and referential integrity.

Completeness asks whether mandatory metadata exists. Uniqueness ensures evidence IDs do not collide. Validity checks dates, formats and allowed classifications. Timeliness identifies delayed source feeds that can make a case appear complete before all relevant information arrives. Referential integrity confirms that a case-to-evidence link points to a real and accessible object.

Duplicate evidence should be controlled. The same document may arrive from several systems, but multiple copies can diverge over time. Content fingerprints can help detect exact duplicates, while business logic decides whether separate instances still need to be retained for provenance.

Time-zone quality deserves special attention in cross-border banks. An alert created at 23:58 UTC may be dated the next day in a local operating centre. Payment value date, booking date, event time and processing time can all differ. Evidence records should name the timestamp semantics rather than expose an unlabeled date field.

Management information that shows control health

Traditional retention MI counts terabytes stored or records deleted. Those numbers say little about whether financial-crime evidence is defensible.

Better MI includes the proportion of cases with complete evidence references, broken archive links, failed restorations, overdue hold acknowledgements, records approaching expiry without a valid trigger, disposal exceptions, unauthorised-access alerts, migration exceptions and recurring QA findings. These measures show whether the lifecycle works.

Case-note analytics can also identify quality risks. Exact duplicate narratives across many cases, abnormally short notes, high rates of post-closure edits or frequent missing evidence references may justify targeted QA. The purpose is not to score analyst writing mechanically; it is to identify populations where human review can find systemic weaknesses.

Management information should preserve context. A spike in archive failures after a platform migration is different from a long-running control deficiency. Root-cause categories and accountable owners turn metrics into action.

Change control for new products and rails

New payment products often introduce evidence gaps because delivery teams focus on transaction processing first. Financial-crime non-functional requirements should be included before launch.

For a new instant-payment rail, ask which message representation is retained, how long source and enriched payloads remain available, how screening and fraud decisions are linked, whether the rail identifier can be searched later and what happens when payment data is enriched after settlement. For an API or embedded-finance channel, identify which party owns original customer instructions and whether the bank can retrieve them if a regulator asks.

For virtual assets, evidence may include wallet addresses, transaction hashes, blockchain-analytics results and VASP information. The bank should preserve the analytics result and provider/version context used in the decision because later attribution can change. On-chain data may remain public, but the bank's interpretation at the time is not automatically preserved by the blockchain.

For trade finance, evidence can span invoices, bills of lading, sanctions screening, goods descriptions, vessel data and correspondent messages. Large documents and external provider data increase storage and licensing complexity. Contracts should permit retention and supervisory retrieval where required.

Cloud and third-party service controls

Cloud storage can improve resilience and search, but responsibility does not disappear. The bank should know where records are stored, how encryption keys and access are controlled, how deletion is executed, how backups age out, how holds are applied and what happens if the provider relationship ends.

A provider may offer an immutable-storage feature with a fixed retention period. That can create a compliance problem if the bank later needs to delete data earlier under an applicable rule or extend preservation under a hold. Architecture should reconcile technical immutability with legal lifecycle requirements before choosing the feature.

Exit planning is essential. The bank should be able to export evidence and metadata in usable formats, validate completeness, maintain access restrictions during transition and obtain appropriate deletion confirmation from the outgoing provider. A proprietary export that loses timestamps or note authorship is not an adequate exit mechanism.

Security incidents and evidential integrity

A cyber incident can affect confidence in investigation records. If an attacker obtained privileged access to a case platform, the bank may need to determine whether records were altered or exfiltrated.

Audit logs, database history, object-versioning and integrity checks can help. A content hash can indicate that a file changed, but it does not by itself explain who changed it or whether the original was trustworthy. Security architecture should combine integrity controls with identity, access and event logging.

Incident response should preserve relevant logs before normal retention processes remove them. This is another reason legal and investigation holds need interfaces with security data, not only business documents.

Practical delivery artefacts

A well-run implementation normally produces several artefacts that are valuable long after the project closes: a record-class catalogue, jurisdiction and legal-entity mapping, retention-rule matrix, evidence metadata model, source-to-case lineage map, role-access model, hold workflow, archive-retrieval procedure, disposal-control specification, migration reconciliation design and test pack.

These artefacts should be version-controlled and linked to approved legal or policy interpretations. They give future change teams a starting point. Without them, every system migration rediscovers the same questions from scratch.

Advanced case study: replacing the investigation platform

A bank decides to retire a fifteen-year-old AML case platform. The system contains open cases, closed cases, SAR-linked records, attachments stored on a network share, notes with local timestamps and several hundred preservation holds applied through spreadsheets maintained by legal teams.

The initial technology proposal migrates only five years of closed cases because the project assumes five years is the universal AML retention period. Compliance challenges the assumption. Records management identifies Australian populations with longer applicable periods, active relationships whose CDD triggers have not yet started, US SAR supporting records with filing-based clocks, and cases under legal hold that must be preserved regardless of normal expiry.

The project builds a population model before migration. Each case is classified by legal entity, record type, trigger, rule version and hold status. Attachments receive stable evidence IDs. Old timestamps are normalised while the original timezone is preserved. SAR-linked cases receive restricted access. The migration reconciles case headers, notes, attachments, decisions, users and hold metadata separately.

Testing finds that a subset of historic notes were stored as HTML containing links to an obsolete document repository. The case rows migrated successfully, but the evidence links would have failed after decommissioning. The team copies only the in-scope referenced documents into the controlled archive, preserves source metadata, updates evidence links and records the migration mapping.

After migration, legal releases a sample hold. The new platform recalculates retention rather than deleting the case immediately. QA retrieves a six-year-old Australian case, an old US SAR support file and an active-relationship KYC record to confirm different rule behaviour. Internal audit can then trace each decision to the approved rule matrix and migration evidence.

The case demonstrates the real meaning of retention governance: the hard part is not storing bytes. It is preserving the legal reason, evidence relationships and decision history through change.

Final advanced-practice standard

A mature bank can answer five questions for any important financial-crime record: What is it? Why do we have it? Which rule controls its lifecycle? Can we prove it has remained reliable? Can an authorised person retrieve it when needed?

If one answer depends on individual memory, a spreadsheet nobody owns or a legacy system that cannot be restored, the control is not yet mature. The objective of advanced practice is to turn those questions into explicit data, workflow, architecture and assurance so the answer remains dependable even after staff, systems and laws change.

References and further reading

These sources support the chapter's global baseline and jurisdiction-specific examples. Retention periods, trigger events, confidentiality rules, preservation duties and disposal requirements must always be mapped to the law and approved policy applicable to the bank entity and record type.

Global standard

• FATF Recommendations — Recommendation 11 establishes the international record-keeping baseline for transaction records and relevant customer-due-diligence material.
• FATF Assessment Methodology 2022, updated edition — criteria 11.1 to 11.4 set out the five-year minimum, transaction-reconstruction expectation and availability to competent authorities.

United States

• FinCEN: Suspicious Activity Report Supporting Documentation — explains the US BSA requirement to retain a filed SAR and its original or business-record-equivalent supporting documentation for five years from filing and make supporting material available to specified authorities on request.
• FFIEC BSA/AML Examination Manual — US interagency examination guidance covering BSA/AML programme, reporting, recordkeeping and control expectations.

United Kingdom

• GOV.UK: Your responsibilities under money laundering supervision — describes UK AML record-keeping responsibilities and the five-year triggers for relevant CDD and transaction records.
• HMRC Economic Crime Supervision Handbook: ECSH33520 Record keeping — current supervisory guidance illustrating retention, deletion and the interaction with other lawful record-keeping requirements.

European Union

• Regulation (EU) 2024/1624, Article 77 — the new EU AML Regulation's record-retention framework. Its main application date is 10 July 2027, so it is treated in this chapter as a future directly applicable framework rather than as a universal current rule in September 2026.

Australia

• AUSTRAC: Record keeping overview — current Australian guidance on AML/CTF record classes, retention periods and record-specific trigger events, including seven-year requirements for important categories.