Keeping a Personal Log That Ties Bank Transfers to Your Exchange Account

If you move money from a Kenyan bank account or mobile wallet into an exchange, the hardest part usually comes weeks later. Your statement shows several outgoing transfers of similar size, on similar dates, to a payee name you may not recognise, and the exchange deposit history shows credits that look almost the same. Matching them by memory fails. The fix is not a clever app; it is a short, disciplined log that you write at the moment you send the money, plus a reconciliation pass once the deposit lands. This guide covers what to record, where to keep it, how to label entries so they remain readable months later, and how to check your work against the deposit records inside your exchange account. It applies whichever exchange you use, and it assumes you are working in Kenya with KES and a local bank or mobile money account. Nothing here replaces the official help centre of your exchange, which is the only place to confirm deposit methods, processing times and reference requirements.

What to write down before you press send

Start the entry before the transfer leaves your account, not after. Once the confirmation screen disappears you are reconstructing from memory, and that is exactly how mismatched records begin. Open your log first, create a new row, and only then complete the transfer. The few seconds this costs are the whole point of the habit.

Record the date and time you initiated the transfer, the exact amount in KES, the sending account or wallet, and the destination as your bank or wallet displays it. Copy the payee or recipient name character for character, including any abbreviation, because that string is what will appear on your statement and it is often the only thing that distinguishes one transfer from another. If the exchange asks you to include a reference, memo or account identifier with the deposit, paste the exact value you used. If you are unsure whether a reference is required, check the deposit page or the help centre before sending rather than guessing.

Add two fields that people usually skip: the exchange account you are funding, if you hold more than one, and the asset or network you intend to receive. When you later deposit into a different account or a different network, these fields stop you from merging two unrelated transactions into one confusing line. Finish the row with a status of sent, and leave the confirmation fields empty until the money actually arrives.

Labelling entries so near-identical transfers stay distinguishable

The core problem is that transfers of the same amount to the same destination look identical on a statement. Give every entry a short unique tag of your own, for example a sequence number combined with the date, and reuse that tag everywhere: in the log, in any note you can attach to the transfer, and later in the deposit record. A tag that is unique to you costs nothing and makes a statement readable at a glance.

Where your bank or wallet allows a narration, remark or reference field, use it consistently. Keep the tag short enough not to be truncated, and avoid special characters that some banking interfaces strip out. If the field has a length limit, decide in advance what you will drop first, so the tag stays recognisable even when shortened. If your bank does not offer such a field, do not fight it; rely on the timestamp plus amount plus payee string as your matching key, and note in the log that no narration was possible.

Never reuse a tag, even for a failed or reversed transfer. A cancelled attempt that later reappears, or a transfer that is returned to you, is far easier to untangle when its tag belongs to exactly one event. If you resend after a failure, create a new row with a new tag and note in the new row which earlier tag it replaces.

Where to keep the log and how to protect it

A plain spreadsheet or a simple table in a notes file is enough. What matters is that it lives somewhere you will still have access to in a year, that it is backed up, and that it is not solely inside the same account you are trying to audit. Keep one copy on your own device and one in an encrypted backup or a password manager note. Do not store exchange passwords, one-time codes or seed phrases in the same file; the log needs transaction identifiers, not credentials.

Treat the log as sensitive. It reveals your banking patterns, your balances in motion and your exchange activity. If you share a device, keep the file protected and consider whether a cloud copy is appropriate for your situation. If you have enabled two-factor authentication on your exchange account, remember that the log is separate from that protection and needs its own care.

Decide on a review rhythm you can actually keep. A short weekly pass, where you confirm that every sent entry has either arrived or is still pending, catches problems while the details are fresh. A monthly pass, where you check the log against your bank statement and your exchange deposit history together, catches the entries that slipped through.

Reconciling the log against exchange and bank records

When a deposit lands, open the deposit or transaction history in your exchange account and copy the details into the matching log row: the credited amount, the timestamp shown there, the status, and any internal identifier the exchange displays. Compare the credited amount with what you sent and write down any difference rather than rounding it away. Differences can come from network or processing charges, from the sending bank, or from the receiving side, and the official fee page and help centre are where you confirm what is expected. Do not assume a cause; record what you observe and check the documentation.

Then do the reverse check against your bank or wallet statement. Find the outgoing line, confirm the payee string and amount, and mark the row as reconciled. If a sent entry has no matching deposit after the period the help centre describes as normal, stop waiting silently and open a support request with the exchange, quoting your tag, the amount, the timestamp and the payee string. Support teams work far faster with those four items than with a screenshot alone.

Keep a short note of what you changed in the log and why, for example a corrected timestamp or a reclassified transfer. If you ever need to raise a dispute, this running note shows a consistent record rather than a file edited after the fact. Nothing in the log proves ownership or guarantees an outcome, but a clear, dated record makes the conversation with support much shorter.

Risk boundary: Kenya Crypto Guide

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

• Create the log row before sending, with date, time, amount in KES, sending account, destination payee string, and any reference the exchange requires.
• Assign a short unique tag to each transfer and reuse it in the log, in any bank narration field, and when matching the deposit record.
• Copy the credited amount, timestamp and status from the exchange deposit history into the log once the money arrives, noting any difference instead of rounding it.
• Check your bank or wallet statement for the outgoing line and mark the entry reconciled only when both sides agree.
• If a deposit does not appear within the period described in the help centre, raise a support request quoting the tag, amount, timestamp and payee string.
• Back up the log to a second location and keep credentials, one-time codes and seed phrases out of the file entirely.