@SravaniC1503

Here’s the quick fix path. First, don’t double-Base64 the keys: use the ASCII-armored outputs from GnuPG directly and paste the full BEGIN/END blocks into Enable data protection on the File Data Set; ASCII armor is already Base64. Second, export the actual encryption subkey, not just the primary key: gpg --export -a <KEYID> > public.asc and gpg --export-secret-subkeys -a <KEYID> > private.asc; then supply the passphrase in Pega if the key is protected. Third, use OpenPGP/PGP (not X.509/SSH) and RSA 2048+; avoid ECC unless your Pega version explicitly lists it as supported. Fourth, keep manifest, data, and token in the same repository folder; the manifest’s file paths must be relative to the repo root, and the token file is what triggers the job. Fifth, validate the manifest fields and record count; mismatches or a missing token commonly cause “data job” failures. Sixth, test decryption outside Pega on the same files with gpg --decrypt to rule out key or passphrase issues. Finally, if it still fails, switch to a single-subkey keypair (no extra subkeys), re-export armored keys, and retry—this aligns with Pega’s import job encryption expectations and known troubleshooting for token/manifest jobs