1.0 Introduction
This article provides examples of FPE schemas for the predefined datatypes used in the Fortanix DSM REST APIs.
NOTE
Fortanix recommends using
format_v2for all new tokenization operations.
2.0 Definitions
For more information on the tokenization format_v2 definitions, refer to the Security Objects Tokenization Quickstart (Format_V2) guide.
3.0 General Category
3.1 Credit Card Number
The following format_v2 credit card schema introduces advanced capabilities such as preserving the original input length and retaining unknown characters, such as hyphens, in their original positions:
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"checksum": "luhn",
"groups": [
{
"codes": [
{
"min_repetitions": 13,
"max_repetitions": 19,
"words": {
"integer_ranges": {
"ranges": [[ 0, 9 ]],
"padding_required": true
}
}
}
]
}
]
}
]
}
]
}This encrypted format defines a credit card number where the tokenized value preserves the original length of the input, even if the input includes non-numeric characters such as spaces or hyphens. These characters are retained in their original positions. The format accepts between 13 and 19 digits and requires the numeric portion of the input to pass the Luhn checksum validation. Only digits (0–9) are considered valid for tokenization, and all other characters are left unchanged.
Example:
Successful Tokenization
Set 1
Input: 4920733931413160
Token: 9413994401086778
Decrypted: 4920733931413160
Set 2
Input: 4920-7339-3141-3160
Token: 9413-9944-0108-6778
Decrypted: 4920-7339-3141-3160
Rejected Tokenization
Input: 0000 - less than 13 digits
Input: 5377996127064477 - fails Luhn checksum
3.2 IPv4 Address
The following format_v2 schema provides advanced features, including support for repeated patterns, preservation of input length, and retention of non-numeric characters (such as . and :) in their original positions.
"format_v2": {
"variants": [
{
"sections": [
{
"groups": [
{
"min_repetitions": 3,
"max_repetitions": 3,
"codes": [
{
"words": {
"integer_ranges": {
"ranges": [
[
0,
255
]
],
"padding_required": false
}
}
},
{
"words": {
"custom": {
"list": ["."]
}
}
}
]
},
{
"codes": [
{
"words": {
"integer_ranges": {
"ranges": [
[
0,
255
]
],
"padding_required": false
}
}
},
{
"words": {
"custom": {
"list": [":"]
}
}
},
{
"words": {
"integer_ranges": {
"ranges": [
[
0,
65535
]
],
"padding_required": false
}
}
}
]
}
]
}
]
}
]
}This encrypted format represents a network address comprising an IPv4 address followed by a port number.
The IPv4 address consists of four groups of digits separated by periods (
.).Each integer in the IPv4 address must be in the range 0 to 255, with optional padding.
The IPv4 address is followed by a colon (
:) and a port number.The port number must be between 0 and 65535, and optional padding is also supported.
Example:
The following matches the schema:
1.1.1.1:80
001.001.001.001:80
192.168.1.254:443
The following does not match the schema:
1.1.1.1. is rejected because it has an extra period at the end.
256.1.1.1:80 is rejected because 256 exceeds the maximum allowed value of 255.
255.1.1.1 is rejected because it is missing a port number.
255.1.1.1:99999 is rejected because the port number exceeds the allowed range of 0–65535.
1234 is rejected because it does not follow the standard format.
B4DF00d is rejected because it contains invalid non-numeric characters.
3.3 Account Number
The following format_v2 schema defines a generic account number tokenization format. It preserves the original input length and retains unknown characters (such as spaces or hyphens) in their original positions:
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"integer_ranges": {
"ranges": [[0, 9]],
"padding_required": true
}
},
"min_repetitions": 6,
"max_repetitions": 2000
}
]
}
]
}
]
}
]
}
Tokenizes numeric digits (0–9).
Requires at least 6 digits, with no fixed upper structure.
Preserves formatting characters such as spaces, hyphens, and prefixes.
Non-numeric characters are passed through unchanged.
Example:
The following matches the schema:
1111-1234-1234
1111 1234 1234
The following does not match the schema:
11111-1234-1234 is rejected because it exceeds the minimum digit count.
3.4 PAN Formats
3.4.1 PAN with Luhn Checksum
The following format_v2 schema enforces Luhn checksum validation and preserves specific leading and trailing digits:
"format_v2": {
"mode": "preserve_format",
"input_processing": "strip_unknown",
"variants": [
{
"sections": [
{
"checksum": "luhn",
"groups": [
{
"codes": [
{
"words": {
"integer_ranges": {
"ranges": [[0, 9]],
"padding_required": true
}
},
"min_repetitions": 13,
"max_repetitions": 19
}
],
"preserve": [2, 2]
}
]
}
]
}
]
}Accepts 13–19 digits.
Enforces Luhn checksum.
Preserves the first and last two digits.
Unknown characters are stripped before processing.
Example:
The following matches the schema:
1234 5678-1234-5670
1234567812345670
The following does not match the schema:
1234567812345671 is rejected because it fails Luhn validation.
3.4.2 PAN SST (No Fixed Preserve)
The following format_v2 schema tokenizes all digits in the PAN while preserving formatting characters.
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"integer_ranges": {
"ranges": [[0, 9]],
"padding_required": true
}
},
"min_repetitions": 12,
"max_repetitions": 19
}
]
}
]
}
]
}
]
}Tokenizes all digits in the PAN.
Preserves separators such as spaces, hyphens, and prefixes.
No digits are excluded from encryption.
Example:
The following matches the schema:
1111-1234-1234
1111-2222-3333-4444
The following does not match the schema:
aaaabbbbcccc
3.4.3 PAN SST c6p6c4
The following format_v2 schema preserves the first 6 digits and the last 4 digits, encrypting the remaining digits.
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"integer_ranges": {
"ranges": [[0, 9]],
"padding_required": true
}
},
"min_repetitions": 12,
"max_repetitions": 19
}
],
"preserve": [6, 4]
}
]
}
]
}
]
}Preserves:
First 6 digits
Last 4 digits
Encrypts all middle digits.
Retains formatting characters.
Example:
The following matches the schema:
1111-1234-5678-9999
1111 2222 3333 4444
The following does not match the schema:
111122223333 (insufficient structure)
#12-345 6388-1234
3.4.4 PAN SST c8p6c2
The following format_v2 schema preserves the first 8 digits and the last 2 digits, encrypting the middle portion.
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"integer_ranges": {
"ranges": [[0, 9]],
"padding_required": true
}
},
"min_repetitions": 12,
"max_repetitions": 19
}
],
"preserve": [8, 2]
}
]
}
]
}
]
}Preserves:
First 8 digits
Last 2 digits
Encrypts all remaining digits.
Formatting characters remain unchanged.
Example:
The following matches the schema:
1111-2222-3333-4444
1111 2222 3333 4444
The following does not match the schema:
111122223333 (insufficient structure)
#12-345 6388-1234
3.5 Phone Number
The following format_v2 schema defines a flexible phone number tokenization format that supports international prefixes and preserves separators:
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"integer_ranges": {
"ranges": [[0, 9]],
"padding_required": true
}
},
"min_repetitions": 6,
"max_repetitions": 2000
}
]
}
]
}
]
}
]
}Requires at least 6 digits.
Preserves formatting symbols like
(,),+, spaces, and hyphens.Additional text is passed through unchanged.
Example:
The following matches the schema:
(202)123-1234
+00 1234 1234 abc
The following does not match the schema:
122223333 (insufficient structure)
3.6 Email Address
The following format_v2 schema defines a flexible email tokenization while preserving its original length and structure:
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"alphabet": [
[
"a",
"z"
],
[
"A",
"Z"
],
[
"0",
"9"
],
[
"!",
"!"
],
[
"#",
"#"
],
[
"$",
"$"
],
[
"%",
"%"
],
[
"&",
"&"
],
[
"\"",
"\""
],
[
"*",
"*"
],
[
"+",
"+"
],
[
"-",
"-"
],
[
"/",
"/"
],
[
"=",
"="
],
[
"?",
"?"
],
[
"^",
"^"
],
[
"_",
"_"
],
[
"`",
"`"
],
[
"{",
"{"
],
[
"|",
"|"
],
[
"}",
"}"
],
[
"~",
"~"
],
[
".",
"."
]
]
},
"min_repetitions": 6,
"max_repetitions": 2000
}
]
}
]
}
]
}
]
}Preserves the original length of the input.
Tokenizes characters from a broad alphabet including:
Uppercase and lowercase letters (A–Z, a–z)
Digits (0–9)
Common email and special characters (such as
.,+,-,_,@, and others)
Requires a minimum of 6 characters and supports up to 2000 characters.
Unknown or unsupported characters are passed through unchanged and remain in their original positions.
Does not enforce strict email syntax, allowing tokenization of partially formed or extended email-like strings.
Example:
The following matches the schema:
testingaddress@testingdomain.com
testingaddress@domain.com@@
The following does not match the schema:
tests (input shorter than 6 characters)
4.0 Location and Address
4.1 Street Address
The following format_v2 schema defines a free-form street address tokenization format. It is designed to securely tokenize postal and street address data while preserving the original length, spacing, and punctuation.
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"alphabet": [
[
"a",
"z"
],
[
"A",
"Z"
],
[
"0",
"9"
],
[
"!",
"!"
],
[
"#",
"#"
],
[
"$",
"$"
],
[
"%",
"%"
],
[
"&",
"&"
],
[
"\"",
"\""
],
[
"*",
"*"
],
[
"+",
"+"
],
[
"-",
"-"
],
[
"/",
"/"
],
[
"=",
"="
],
[
"?",
"?"
],
[
"^",
"^"
],
[
"_",
"_"
],
[
"`",
"`"
],
[
"{",
"{"
],
[
"|",
"|"
],
[
"}",
"}"
],
[
"~",
"~"
],
[
".",
"."
],
[
",",
","
],
[
"@",
"@"
]
]
},
"min_repetitions": 4,
"max_repetitions": 2000
}
]
}
]
}
]
}
]
}Preserves the original length of the input.
Tokenizes characters from a broad alphabet, including:
Uppercase and lowercase letters
Digits
Common punctuation and separators such as spaces, commas, periods, and hyphens
Requires a minimum of 4 characters and supports up to 2000 characters.
Unknown or unsupported characters are passed through unchanged and remain in their original positions.
Does not enforce address validation rules (such as postal codes or country formats).
Example:
The following matches the schema:
1951 Grandview,
Apt F,
Bder, CO - 90130
The following does not match the schema:
Apt (input shorter than 4 characters)
4.2 Geo Location
The following format_v2 schema is designed to tokenize geographic coordinate data and related free-form location strings. It supports numeric values, cardinal directions, and symbols commonly found in latitude and longitude representations.
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"custom": {
"list": [
"0",
"1",
"2",
"3",
"4",
"5",
"6",
"7",
"8",
"9",
"n",
"N",
"s",
"S",
"e",
"E",
"w",
"W"
]
}
},
"min_repetitions": 5,
"max_repetitions": 2000
}
]
}
]
}
]
}
]
}Preserves original formatting and length.
Supports:
Digits
Decimal points
Cardinal direction indicators (
N,S,E,W)
Retains degree symbols, spaces, and punctuation.
Does not enforce coordinate range validation.
Example:
The following matches the schema:
9.55349N
- 104.99445S
5.5555° W
The following does not match the schema:
444 (input shorter than 5 characters)
5.0 Identification and Government Identifiers
5.1 Personally Identifiable Information (PII)
The following format_v2 schema tokenizes general personally identifiable information that may contain a mix of letters, numbers, and special characters. It is suitable for free-form PII fields that do not follow a single, well-defined structure.
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"alphabet": [
[
"a",
"z"
],
[
"A",
"Z"
],
[
"0",
"9"
],
[
"!",
"!"
],
[
"#",
"#"
],
[
"$",
"$"
],
[
"%",
"%"
],
[
"&",
"&"
],
[
"\"",
"\""
],
[
"*",
"*"
],
[
"+",
"+"
],
[
"-",
"-"
],
[
"/",
"/"
],
[
"=",
"="
],
[
"?",
"?"
],
[
"^",
"^"
],
[
"_",
"_"
],
[
"`",
"`"
],
[
"{",
"{"
],
[
"|",
"|"
],
[
"}",
"}"
],
[
"~",
"~"
],
[
".",
"."
],
[
",",
","
],
[
"@",
"@"
]
]
},
"min_repetitions": 4,
"max_repetitions": 2000
}
]
}
]
}
]
}
]
}Preserves the original length and appearance of the input.
Supports alphanumeric characters and common punctuation.
Accepts a minimum of 4 characters.
Does not enforce validation rules for specific identifier types.
Example:
The following matches the schema:
Bder, CO - 90130
01-47-87441,
The following does not match the schema:
444 (input shorter than 4 characters)
5.2 PII-Derived Identifiers (PIID)
The following format_v2 schema is a specialization for PII-derived identifiers (PIID). These identifiers often resemble structured IDs but vary widely in format across systems and jurisdictions.
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"alphabet": [
[
"a",
"z"
],
[
"A",
"Z"
],
[
"0",
"9"
],
[
"!",
"!"
],
[
"#",
"#"
],
[
"$",
"$"
],
[
"%",
"%"
],
[
"&",
"&"
],
[
"\"",
"\""
],
[
"*",
"*"
],
[
"+",
"+"
],
[
"-",
"-"
],
[
"/",
"/"
],
[
"=",
"="
],
[
"?",
"?"
],
[
"^",
"^"
],
[
"_",
"_"
],
[
"`",
"`"
],
[
"{",
"{"
],
[
"|",
"|"
],
[
"}",
"}"
],
[
"~",
"~"
],
[
".",
"."
],
[
",",
","
],
[
"@",
"@"
],
[
" ",
" "
]
]
},
"min_repetitions": 4,
"max_repetitions": 2000
}
]
}
]
}
]
}
]
}Preserves length, spacing, and punctuation
Supports alphanumeric characters and common delimiters
Example:
The following matches the schema:
01-47-87441,
1951 Grandview
Apt F
Bder, CO - 90130
The following does not match the schema:
act (input shorter than 4 characters)
5.3 Government ID
The following format_v2 schema tokenizes government-issued identification numbers that vary widely in format across countries, regions, and issuing authorities. These identifiers often contain a combination of letters, digits, spaces, and punctuation and do not follow a single universal structure.
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"alphabet": [
[
"a",
"z"
],
[
"A",
"Z"
],
[
"0",
"9"
],
[
"!",
"!"
],
[
"#",
"#"
],
[
"$",
"$"
],
[
"%",
"%"
],
[
"&",
"&"
],
[
"\"",
"\""
],
[
"*",
"*"
],
[
"+",
"+"
],
[
"-",
"-"
],
[
"/",
"/"
],
[
"=",
"="
],
[
"?",
"?"
],
[
"^",
"^"
],
[
"_",
"_"
],
[
"`",
"`"
],
[
"{",
"{"
],
[
"|",
"|"
],
[
"}",
"}"
],
[
"~",
"~"
],
[
".",
"."
],
[
"@",
"@"
]
]
},
"min_repetitions": 4,
"max_repetitions": 2000
}
]
}
]
}
]
}
]
}Preserves the original length and format of the input.
Supports:
Uppercase and lowercase letters
Digits
Common separators and symbols (spaces, hyphens, punctuation)
Retains all formatting characters in their original positions
Does not enforce country-specific or identifier-specific validation rules.
Example:
The following matches the schema:
01-22-33333
ABC 123-456-7777
The following does not match the schema:
012 (input shorter than 4 characters)
5.4 Social Security Number (SSN)
In the United States, a Social Security Number has the general format AAA-GG-SSSS, where AAA, GG, and SSSS are groups of decimal digits, separated by hyphens. Furthermore, the AAA group must be less than 900, and cannot be equal to 0 or 666. The other two digit groups also cannot be equal to 0.
This can be expressed through a Concat that consists of the AAA section, a hyphen, the GG section, another hyphen, and the SSSS section.
The following format_v2 schema defines a structured numeric pattern similar to a SSN format, with specific allowed numeric ranges for each section and a fixed separator (-):
"format_v2": {
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"integer_ranges": {
"ranges": [
[
1,
665
],
[
667,
899
]
],
"padding_required": true
}
}
},
{
"words": {
"custom": {
"list": [
"-"
]
}
}
},
{
"words": {
"integer_ranges": {
"ranges": [
[
1,
99
]
],
"padding_required": true
}
}
},
{
"words": {
"custom": {
"list": [
"-"
]
}
}
},
{
"words": {
"integer_ranges": {
"ranges": [
[
1,
9999
]
],
"padding_required": true
}
}
}
]
}
]
}
]
}
]
} The tokenized value follows the pattern XXX-XX-XXXX, consisting of three numeric sections separated by hyphens.
The first section must be between 001–665 or 667–899 (with 666 and 000 disallowed) and always zero‑padded to three digits.
The second section must be between 01–99 (00 not allowed) and zero‑padded to two digits.
The third section must be between 0001–9999 (0000 not allowed) and zero‑padded to four digits.
Hyphens remain fixed between sections and are preserved exactly during tokenization and detokenization.
Example:
The following matches the schema:
123-45-6789
578-65-4321
The following does not match the schema:
12-345-6789 is rejected because it has only two digits in the first section.
123456789 is rejected because hyphens are missed.
ABC-DE-FGHI is rejected because it contains non-numeric characters in numeric positions.
6.0 Security Questions and Answers
The following format_v2 schema tokenizes security questions and answers used for identity verification, account recovery, and authentication workflows. These contain free-form natural language text, mixed with numbers and punctuation, and often vary significantly in length and structure.
"format_v2": {
"mode": "preserve_length",
"input_processing": "passthrough_unknown",
"variants": [
{
"sections": [
{
"groups": [
{
"codes": [
{
"words": {
"alphabet": [
[
"a",
"z"
],
[
"A",
"Z"
],
[
"0",
"9"
],
[
"!",
"!"
],
[
"#",
"#"
],
[
"$",
"$"
],
[
"%",
"%"
],
[
"&",
"&"
],
[
"\"",
"\""
],
[
"*",
"*"
],
[
"+",
"+"
],
[
"-",
"-"
],
[
"/",
"/"
],
[
"=",
"="
],
[
"?",
"?"
],
[
"^",
"^"
],
[
"_",
"_"
],
[
"`",
"`"
],
[
"{",
"{"
],
[
"|",
"|"
],
[
"}",
"}"
],
[
"~",
"~"
],
[
".",
"."
],
[
",",
","
],
[
"@",
"@"
]
]
},
"min_repetitions": 6,
"max_repetitions": 2000
}
]
}
]
}
]
}
]
}Preserves the original length and formatting of the input.
Supports:
Uppercase and lowercase letters
Digits
Common punctuation and symbols
Retains spaces, commas, question marks, and separators.
Does not enforce linguistic or semantic validation.
Suitable for both questions and answers.
Example:
The following matches the schema:
What was the name of your first pet?
Favorite color: 555666777
The following does not match the schema:
test (less than 6 characters)