The most useful kinds of tokenization will "anchor" the data to a specific platform, and allow you to perform common operations without slinging plaintext aroun

The most useful kinds of tokenization will "anchor" the data to a specific platform, and allow you to perform common operations without slinging plaintext around. So it's a token and an interface, where the minimum interface is "give me the plaintext back", but richer interfaces are possible and more useful. So e.g. once you tokenize a card, you can perform billing operations on the token. The original CHD is "too liquid" and can be used anywhere in the financial system. If the token platform ensures only you can get paid with the token that can the limit the scope of badness. You can also apply auditing and enforce extra access control / policy around operations or exchange of tokens for plaintext. In a complex system this can be better than letting sensitive information propagate to different data stores or business units. It also means you can build out the auditing & controls just once instead of needing controls in N systems. It's also a decent tactic for "compliance engineering" in terms of being able to draw a box around which parts of the system you expect your auditor(s) to want to look at really closely. Things can rapidly get expensive when too much stuff comes into audit scope.