Record keeping review: what the decision maker looks at
A record keeping review checks whether an obliged entity can produce the client file, the transaction trail and the risk assessment behind it, on request and within the window given. The decision maker looks at completeness, chronology and whether the file actually supports the decisions it claims to support — not just whether a folder exists.
What the reviewer actually checks
The review starts from a request: a supervisor's letter, an internal audit trigger, or a client's own pre-transaction check. The reviewer does not read the file for style. They read it for three things: does the identification record match the person who transacted, does the transaction history reconcile without gaps, and does the risk assessment explain why the entity accepted or escalated the relationship at the time it was made, not with hindsight.
A file that is complete but undated is treated the same as a file that is missing — the reviewer cannot show when a judgement was reached, so the judgement cannot be defended. Retrieval speed matters almost as much as content: a record that exists but takes weeks to locate fails the same test as a record that was never created.
| What is checked | Pass condition | Typical failure |
|---|---|---|
| Client identification | Matches the counterparty on the transaction | Name mismatch, stale document |
| Transaction history | Reconciles without unexplained gaps | Missing legs, unlogged reversals |
| Risk assessment | Dated at the time of the decision | Written or backdated after the fact |
| Retrieval | Produced within the window set by the request | File located but assembled too slowly |
Practical consequence
Once a gap is found, the timeline changes. A minor gap usually invites a short follow-up request with a fixed deadline. A pattern of gaps — several files, the same missing field — moves the matter from a spot check to a scoped review of the whole client book, which takes longer and draws more attention internally. The point of no return is the moment the reviewer stops asking for individual documents and starts asking for the policy that was supposed to produce them; after that, the conversation is about the control, not the file.
What to do
- Assign one named owner for the response — split ownership is the most common cause of missed deadlines.
- Pull the full client file before answering any question about a single document; partial answers invite follow-up requests.
- Reconcile the transaction history against the ledger before submission, not after the reviewer flags a gap.
- Log every gap found internally, even ones the reviewer has not asked about — a self-reported gap reads differently from a discovered one.
- Submit an index with the file, not just the documents — reviewers move faster through indexed submissions and ask fewer clarifying questions.
- Keep a record of what was sent, when, and to whom; this becomes the evidence that the response itself was timely.
Who decides
The first decision maker is usually the reviewer assigned to the file — an internal compliance officer, an external auditor, or a supervisory examiner, depending on who triggered the check. Their finding goes to a second layer: internal reviews escalate to senior management or the compliance function head; supervisory reviews escalate within the authority's own case-handling structure. A contested finding is not argued with the first reviewer directly — it is answered in writing, addressed to whoever the escalation path names, within the deadline the request states.
Common branching points
If the missing record is a promotional message that a supervisor later treats as a binding offer rather than marketing, the record review folds into a separate question about when A promotion is treated as an offer authorisation who decides and on what basis.
If a document in the file is a software licence that has become disputed because the counterparty entered insolvency proceedings, the record review pauses until the separate question of When a licence survives insolvency, or does not is settled.
If the gap traces back to a patent dispute where a competitor has already launched a close variant of the protected product, the file review runs alongside the separate track covering When a rival launches an obvious workaround.
If the transaction trail breaks because a connected system stopped logging events after a security incident, the record gap is often downstream of the situation covered in When an integration partner leaks credentials.
Limits
This page describes how a record keeping review is run and what a reviewer checks. It does not set the exact deadline that applies to any single request — that is stated in the request itself and varies by who is asking. It does not cover the fee, if any, charged for a review, and it does not decide whether a specific document satisfies a specific rule; that judgement depends on facts this page cannot see.
Related publications
The training programme runs on a similar review logic and is worth reading alongside this page: Training programme step by step.
Verified
Reviewed 14 August 2025. This page reflects internal file-handling practice observed across supervised entities and is updated when that practice changes; it does not cite external legal sources because none applies to the procedural detail described here.
FAQ
How long does record keeping review take in practice?
Most reviews close within a few weeks once the file is complete and indexed. The exact window is set by the request itself rather than by a fixed rule, so the deadline stated in the request is the one that governs.
Which documents are needed to start?
The client identification record, the full transaction history for the period in question, and the risk assessment dated at the time the relationship was accepted or reviewed. Any prior correspondence with a supervisor about the same client should be attached from the start.
What happens if the other side does not respond?
The reviewer usually sends one further reminder with a final deadline, then escalates. In a supervisory review, non-response is often treated as an adverse signal in itself and can trigger a wider check of the client book rather than a single-file follow-up.