Keeping a Secure Local Log of Your Identity Verification Documents
When you complete identity verification on an exchange, the useful information you gain is not the document itself but the story of the submission: which document type you used, on what date, through which channel, what the review status was, and what you were told when something went wrong. That story is easy to reconstruct for a week and almost impossible to reconstruct a year later, which is exactly when a support agent asks you to describe your earlier verification attempt. This guide describes a simple offline log you can keep for that purpose. The core rule is that the log records facts about the process, never the contents of the documents. No scans, no photographs, no full document numbers, no selfie images. A short written entry in a plain text file or a paper notebook is enough, and it stays useful precisely because it contains nothing that would harm you if it were read by someone else. The steps below apply whether you verified on one exchange or several, and they work the same on desktop and mobile.
Decide what belongs in the log and what never does
Start by drawing a hard line between metadata and document content. Metadata is everything you can write down safely: the date you began a verification attempt, the document type in general terms such as passport or national identity card, whether you used the web interface or the mobile app, the review status you saw, and the date that status changed. Document content is everything you must keep out: images, scans, photographs of the document, the full document number, the expiry date, your date of birth, your address, and any selfie or liveness recording. A log that contains only metadata answers almost every question a support team will ask, because those questions are about sequence and timing rather than about the document itself.
Write the rule into the first line of the file so that future you, or anyone you ask to help you, sees it before adding anything. A single sentence such as this log records submission dates and statuses only, never document images or numbers, is enough. If you keep the log in a spreadsheet, put the rule in a header row that cannot be deleted by accident, and avoid a column for document numbers entirely, because an empty column invites someone to fill it. The absence of a field is a stronger safeguard than a warning next to a field.
One more exclusion is worth stating plainly: do not paste screenshots of the verification screens into the log. A screenshot of a submission confirmation often shows a reference number, a partial document number or an account identifier. If you want a visual record, describe what the screen said in your own words instead.
Choose a storage location that is offline and durable
The log should live somewhere that does not sync to a cloud account by default and does not travel with your phone. A plain text file on a computer you control, a printed page kept with other household paperwork, or an encrypted note in a password manager are all reasonable choices. What matters is that you know where it is, that it survives a lost phone, and that opening it does not require the same device you use for trading. If you use a password manager, check whether its notes are included in any export or sharing feature before you rely on it, and keep the entry short.
If you prefer paper, use a notebook rather than loose sheets, write the date of each entry, and store it with documents you already protect, such as insurance papers. Paper has one advantage that matters here: it cannot be searched, copied or exfiltrated remotely. Its disadvantage is that it can be lost in a fire or a move, so if the log matters to you, consider a second copy in a different physical place, or a digital copy that contains no sensitive data and therefore can be stored more casually.
Whatever you choose, decide now how you will back it up and how you will restore it. A log you cannot find after replacing a laptop has no value. Test the restore path once, on a day when nothing is wrong, so that you are not learning your own system during a support conversation.
Record each submission with a consistent set of fields
Use the same small set of fields for every entry so that later comparison is easy. A workable set is: date of submission, exchange name, document type in general terms, channel used, the status shown immediately after submission, and the date you next checked. Add a free-text line for anything unusual, such as a message that the photo was unclear or a request to resubmit. Keep the wording short and factual; the log is a chronology, not a diary.
Update the entry when the status changes rather than creating a new entry, unless the exchange asked you to start a fresh submission. A single entry that reads submitted on the fifth, pending on the sixth, approved on the eighth is far more useful than three disconnected lines, because it shows the reviewer how long each stage took. If you were asked to resubmit, note that explicitly and record the new submission date as part of the same entry.
Record the channel precisely enough to be meaningful: web browser, mobile app, or a specific in-product flow such as a liveness check. Do not record session tokens, one-time codes or anything labelled as a secret. If a support agent gave you a case reference, that reference is safe to store and often speeds up a later conversation, but verify in the help centre what a reference looks like before you assume a string you copied is one.
Keep the log clean over time
Set a light maintenance habit: once or twice a year, open the log, confirm that each entry still makes sense, and remove anything that drifted into sensitive territory. If you ever pasted a document number or an image path into an entry, delete that line rather than leaving it with a note. Deleting is the correct action; there is no benefit to retaining a partial identifier.
If you stop using an exchange, keep the entry but mark it as closed with the date. Old verification records are exactly the ones you cannot reconstruct from memory, and they are also the ones most likely to be asked about if you return later. There is no need to keep anything beyond the metadata, so a closed entry can be a single line.
Finally, treat the log as a personal aid, not as proof of anything to a third party. It helps you describe your own history accurately and it helps a support team find your case faster. It does not replace the exchange's own records, and it should never be presented as an official document. If you need confirmation of a verification status, the authoritative source is the verification page inside your account, and the help centre explains how that status is displayed.
Risk boundary: Safe Crypto Signup
Digital assets are volatile and derivatives can amplify losses. This website has no login, wallet connection, deposit form or customer-support chat. A referral link only records attribution; it does not guarantee access, pricing, rewards, approval or investment results. Availability can differ by residence, legal entity and product, so no regional access is assumed from language or branding alone.
Scenario checkpoint
- Write the no-documents rule as the first line of the log before adding any entry.
- Record only date, exchange, general document type, channel, status and next check date.
- Never store scans, photos, full document numbers, expiry dates or liveness recordings.
- Keep the log offline or in an encrypted note, and test that you can restore it.
- Update one entry as the status changes instead of creating duplicate lines.
- Before contacting support, summarise the log and verify any unexpected document request against the help centre.