Skip to main content
FXCL tokenization profiles bind format-preserving encryption parameters to a CryptoHub key store. The profile controls the algorithm, character set, preserved characters, verification length, and execution location.

What you’ll build

This guide configures:
  • A client-side FF3-1 profile with a retrievable AES key
  • A CryptoHub-backed FF1 profile with a non-retrievable, HSM-trusted AES key
  • Tokenize and detokenize calls that preserve the first four characters

Before you begin

Complete Install and authenticate FXCL. For client-side tokenization, the application endpoint must be approved to receive a retrievable key. For CryptoHub-backed tokenization, the Anchor HSM must have the required tokenization capability and license. The identity must also be able to manage token profiles and execute TOKA and TOKG. Confirm both token operations with a bounded synthetic round trip. Successful key-store or profile management does not prove token-operation access.
Server-side FF1 requires the Format-Preserving Encryption and Format-Preserving Encryption FF1 features on the Anchor HSM.

Create a client-side tokenization profile

Create a retrievable AES-256 data-encryption key store:
Configure an FF3-1 decimal profile that preserves the first four characters:
setClientSide(true) identifies a local profile. The profile’s key store must be retrievable.

Tokenize and detokenize locally

A successful operation preserves the value length and the configured leading characters. Detokenization must recover the original value exactly.

Create a CryptoHub-backed profile

Create a non-retrievable key store:
Configure the server-side profile and bind the active key explicitly:
Set the profile’s key store and active key with setKeyStore() and setKey(). A profile that sets only the key store can fail at runtime with FAILED TO RETRIEVE ENCRYPTION KEY because it has no valid active encryption key binding.
FF1 requires an HSM-trusted key. Creating an FF1 profile against a retrievable client-side store is rejected.

Tokenize and detokenize on CryptoHub

Create a new profile-only RemoteTokenizeParams object for detokenization. Do not reuse the object that completed tokenization or pass its getKey() value to the detokenization constructor. In FXCL 1.9.5, parameter reuse can return an empty detokenization response. The operation must return a same-length token and recover the original value.

Delete test profiles and stores

Delete profiles before their key stores:
Do not delete a production profile or key store until all dependent tokens completed the approved retention or migration process.

Verify it works

For client-side tokenization, require all of these results:
  • The profile can be created and retrieved.
  • The token differs from the clear value.
  • The token length matches the clear-value length.
  • Preserved characters remain unchanged.
  • Detokenization recovers the original value.
For CryptoHub-backed tokenization, require the same data checks. Also confirm that the Anchor has both required FPE features and that the operation does not return a license or key-retrieval error.

Troubleshooting

Version and scope

Client-side FF3-1 and CryptoHub-backed FF1 tokenization were validated with FXCL 1.9.5 and CryptoHub 7.2.0.7. The validated server-side configuration used a non-retrievable AES-256 key store and an Anchor with the FPE and FPE FF1 features enabled.