Tokenisation Mapping Redaction with anonym.plus

Finance Solution · Payments & Cards · PCI DSS v4.0 Req. 3.5

Requirement 3.5 protects the keys and data that guard a stored card number, and Req. 3.5.1 goes further: the PAN must be rendered unreadable wherever it sits, whether by a keyed one-way hash, truncation, an index token, or strong cryptography — with an explicit warning that a hashed value and a truncated one, kept together, can let someone reconstruct the original number. The token itself usually follows the EMVCo Payment Tokenisation industry specification, the technical standard behind how a token stands in for a real card number in the first place. anonym.plus marks each true value on your device, so the alias stays while the digits go.

When this applies

A vault export pairs each alias with the real number it stands for. You strip those values under Requirement 3.5 before the map is shared.

How anonym.plus handles it

1. Open the mapping file in anonym.plus on your device.
2. The tool flags the sensitive number field.
3. It keeps the alias field untouched.
4. Confirm no real number remains in any row.
5. Apply Redact or Mask to those values.
6. Save the clean map locally.

What you need to provide

• The token map (CSV, JSON, or TXT).
• An operator (Redact removes the real value).
• Optional allow-list for the alias field.

PII & financial identifiers detected

Compliance achieved

• Guards the token map per PCI DSS v4.0 Req. 3.5.
• Renders the PAN unreadable wherever it is kept, as Req. 3.5.1 requires, and avoids leaving both a hashed and a truncated copy of the same value in the same file.
• Recognises the token itself as an EMVCo Payment Tokenisation-style alias, distinct from the real card number it stands in for.
• Offline handling keeps the real numbers off any server.

Limitations & cautions

An alias by itself is safe only while the vault that reverses it stays protected. The tool removes the sensitive field; it does not secure your vault keys, which you must manage separately.