23 August 2026 · 8 min read

Editing user profiles and KYC records: what should an admin change?

Editing a user profile sounds like the least risky thing an admin does. Two of the fields on that screen are the ones an attacker most wants changed, and they should not behave like the others.

Which fields are routine?

Most of the profile is ordinary correction work, and being able to fix it quickly saves your support hours.

• Display name and username, when someone mistyped it at signup
• Country or timezone, which affects when payouts appear to land
• Language preference
• Internal notes on the account, which users never see

These need no ceremony. They should still be logged, because "nothing important changed" is a judgement you want to be able to check later rather than assume.

The two fields that are not

The payout address, and the login email: Changing either one is the step that turns a compromised account into a loss, and both are usually sitting on the same screen as the display name.

They deserve different handling:

• Confirm out of band: A change requested by message should be confirmed through the channel already on the account, not the one making the request
• Cool down before withdrawal: After a payout address changes, hold withdrawals for a set period. This single rule defeats most account takeovers, because the attacker needs both the login and time
• Notify the old address: Send the alert to the previous email, not only the new one. The person who needs to know is the one being locked out
• Always manual, never automated: A withdrawal to a newly changed address should route to a person regardless of amount. That rule belongs with the rest of your payout settings, covered in manual or automatic payouts

Handling KYC documents

Whether you verify identity at all is your decision and depends on where you operate. If you do collect documents, a few things follow immediately.

Verification status and the documents are separate things: Support may need to see that an account is verified. Very few people need to open the passport scan. Those are two different permissions, and software that treats them as one is giving everybody access to the most sensitive data you hold.

Approval and rejection both need a reason: A rejected verification with no explanation produces a support conversation and a suspicious user. A short reason field ends both.

Re-verification has to be possible: Documents expire, people move, names change. If the only path is deleting the account and starting again, that is not a workflow.

What should you not be storing?

The safest identity document is the one you no longer hold. Two habits worth adopting on day one:

Delete documents once the decision is made: Keep the outcome, the date and who approved it. The scan itself is a liability sitting on your server, and its usefulness ends the moment you accept it.

Never keep documents in the same place as everything else without limits. If your admin panel lets any staff member browse uploaded identity documents, you have built a copy of every user's passport that anyone with a support login can walk away with. Role separation is the fix, and it is covered in multiple admins: who should see and do what?

A process that survives a dispute

Four steps, and they cost seconds:

1. Confirm the request came from the account owner, through a channel already on file
2. Make the change, one field at a time, so the log reads clearly
3. Type a real reason: what was asked for, by whom, and how you confirmed it
4. Tell the user it is done, on the record

Six weeks later, when someone claims they never asked for their email to be changed, that reason field is the entire answer. What the log has to capture for that to work is in what does your audit log actually have to record?

What should you check in the software?

Three questions when you are evaluating a platform. Can the payout address and the login email be changed without a second confirmation? Is viewing a KYC document a separate permission from seeing verification status? Does the log record the value before the change, or only that a change happened?

If the answer to the first is yes and the last is "only that it happened", you can still operate safely, but the discipline has to come from you rather than the software. The wider set of controls is described in inside the admin panel.

Common questions

Question this did not answer? Ask on Telegram. Reader questions get written up first.