Isn't this almost necessarily true for any system which needs an auditable history?

Just thinking out loud, of course cascading deletes will fail, so I guess you could avoid using true foreign keys to the user table for things which are truly related, and then you'd know what the user did but presumably no PII... Seems insanely sketchy though. Way cleaner to soft delete if you ever need to recover history, which the fintech context amongs many obviously requires

You don't need to delete the rows from the database. Just replace user's name, address and phone with random data.

Regulated financial services must also store the documentation and results for how they verified a user's identity, too. This involves talking to third parties that can tell you if a given user's name matches their tax identifiers, street addresses, phone number, et cetera.

Anyone competent is storing both their requests to those external APIs, as well as those responses, for the entirety of the recordkeeping requirement period.

The company needs 7 to 10 years of audit info. Of course they cannot 'delete' any account.