This is in fact quite common, but I don’t believe there is a general guideline, as the details depend upon each situation. But there is at least a couple of key points to remember.
There are two kinds of impersonation, in production and in development. In a complex environment, where you have multiple user roles and abilities, impersonation in development is very close to being a requirement IMO. If you have dozens or hundreds of things that one user can do but another can’t, developers and testers need to be able to “be” a particular user with all of their permissions and nothing more. Even if the only distinguishing features between users is their data, it’s still useful in development as it’s a quick and easy way to get at just the data that is relevant.
In production there are 2 key things to keep in mind, accountability and data privacy.
Impersonation doesn’t have to conflict with accountability, just because you allow someone to do everything that someone else does, doesn’t mean that you can’t record who actually did it. Auditing data might show E, E on behalf of U or finally just U. The last should be avoided as it does muddle accountability. Given your bank example, it would be fine if the bank records show that Employee555 transferred money from your account to another, and totally unacceptable for the record to show that flipdoubt did the transfer.
Data privacy, your impersonator should be someone that already has the ability to look at the data anyway. The ability to impersonate shouldn’t be something that all employee’s should have. This should be kept in mind when determining what internal roles are going to be doing the impersonating. In your development environment, any necessary data obfuscated should be done regardless of impersonation. If you don’t want developers to see it in development, it shouldn’t make it to your development environment.
I will note that my bank does give what could be considered an “impersonation” it uses OAuth (I believe) to allow me to give a 3rd party site read only permission to my account. So do several of my credit card accounts. I mention this not only because of your bank reference but because it provides another model to consider : access but only with permission.