Format-Preserving Encryption Explained: Securing Card Data Without Breaking Your Systems

One of the quiet headaches of securing legacy payment systems is that traditional encryption changes the shape of your data. A 16-digit card number encrypted with AES becomes a long block of binary that will not fit into a database column expecting numeric characters. Format-preserving encryption (FPE) was designed to solve exactly this problem, and it has become a practical tool for organizations that cannot rip out decades-old infrastructure just to add cryptographic protection.

What Format-Preserving Encryption Does

FPE encrypts data so that the ciphertext has the same format as the plaintext. A 16-digit PAN becomes another 16-digit number. A nine-character field stays nine characters. This means encrypted values can flow through systems, forms, and database schemas that were never designed to handle raw ciphertext, avoiding costly re-engineering of downstream applications.

The Standard Behind It

NIST Special Publication 800-38G defines two approved modes for format-preserving encryption, known as FF1 and FF3-1. These modes are built on the AES block cipher and provide a standardized, publicly reviewed approach rather than a homegrown scheme. Using a recognized standard matters because cryptography that has not been openly analyzed frequently contains subtle, exploitable flaws.

Rule of thumb: if a vendor claims format-preserving encryption but cannot tell you which NIST mode they implement, treat that as a warning sign.

Where FPE Helps in Payments

• Legacy databases: Protect PANs without altering column types or record lengths across mainframe and ERP systems.
• Preserving partial visibility: Many FPE implementations can leave the last four digits in the clear for customer service and receipts while encrypting the rest.
• Test and analytics environments: Generate realistic, correctly formatted data that behaves like production without exposing real cards.

FPE Versus Tokenization

FPE and tokenization can look similar because both produce an output that resembles a card number. The difference is reversibility and dependency. FPE is genuine encryption, so the original value can be recovered anywhere the key is available. Tokenization relies on a vault lookup and produces values with no mathematical link to the original. FPE avoids the need to run and scale a central vault, but it reintroduces the full weight of key management as the price of that convenience.

Watch the Limitations

FPE has real caveats. Small input spaces, such as short numeric fields, offer attackers fewer possibilities to guess, which can weaken security. The FF3 mode was revised to FF3-1 after researchers found weaknesses, a reminder that even standardized cryptography evolves over time. Always confirm you are running current, patched implementations rather than an outdated library.

There is also a scope consideration that teams frequently overlook. Because FPE is reversible encryption rather than tokenization, systems that hold the key, or can request decryption, still handle recoverable card data and generally remain within PCI DSS assessment scope. FPE reduces the risk of stored data, but it does not automatically carve systems out of scope the way a well-isolated token vault can. Plan your key access boundaries with that reality in mind.

Conclusion

Format-preserving encryption is a pragmatic bridge for environments that cannot absorb the disruption of traditional ciphertext. Used with a NIST-approved mode and disciplined key management, it lets you protect card data while keeping the surrounding systems intact. Just remember it is a tool for compatibility, not a universal replacement for tokenization or P2PE, and weigh its scope implications before treating it as a complete solution.