PII (verified_data)

The verified_data field in a GET /verifications/{id}/result response contains verified personal data, or personally identifiable information (PII). This page explains how to handle it in compliance with the law.

GET/api/v1/verifications/{id}/result→Complete result contract, including the verified_data field with personal data.Full contract in the API Reference

verified_data structure

The content of verified_data depends on the verification provider. Typical fields include:

Field	Type	Availability
first_name	string	All providers
last_name	string	All providers
pesel	string	mObywatel and, in some cases, bank_transfer
id_document_number	string	mObywatel
id_document_type	string	mObywatel (id_card, passport)
date_of_birth	string (date)	mObywatel
nationality	string (ISO 3166)	mObywatel
iban	string	bank_transfer
bank_name	string	bank_transfer

Example - bank_transfer

{
  "first_name": "Jan",
  "last_name": "Kowalski",
  "iban": "PL61109010140000071219812874",
  "bank_name": "Santander Bank Polska"
}

Example - mObywatel

{
  "first_name": "Jan",
  "last_name": "Kowalski",
  "pesel": "90010112345",
  "id_document_number": "ABC123456",
  "id_document_type": "id_card",
  "date_of_birth": "1990-01-01",
  "nationality": "PL"
}

HUB-side security

DPay Web EID stores every verified_data field encrypted in the database:

• Algorithm: AES-256-GCM, symmetric authenticated encryption
• Key management: keys are rotated regularly and stored in an HSM/KMS
• Access: only through the API with Bearer token authentication

GDPR requirements

GDPR compliance

When you receive and store PII, you become a data controller within the meaning of the GDPR. You must meet the applicable legal requirements:

What you must provide

1. Legal basis for processing - customer consent, a contract or legitimate interest
2. Privacy notice - tell the customer which data you collect, why you collect it and how long you retain it
3. Purpose limitation - collect only the data that is necessary (data minimization)
4. Secure storage - use encryption at rest and in transit in your systems
5. Retention - delete data when the processing purpose no longer applies
6. Right to be forgotten - allow the customer to have their data deleted
7. Right of access - allow the customer to retrieve their data
8. Audit log - record who accessed the data, when and for what purpose
9. DPIA (Data Protection Impact Assessment) - for high-risk processing operations
10. Breach notification - report an incident to the competent data protection authority within 72 hours

Best practices

• Encryption at rest - store verified_data encrypted in your database, for example with PostgreSQL pgcrypto or MySQL AES_ENCRYPT
• Pseudonymization - where possible, use hashes or masking instead of complete values, for example a salted SHA-256 hash of PESEL
• Minimization - do not retain verified_data after KYC is complete; keep only the verification outcome
• Tokenization - generate an internal customer_id token instead of operating on PESEL
• Access control - restrict PII access to authorized employees through RBAC
• Audit log - log every access to customer data with user_id, timestamp and IP

Example - secure storage in PHP

<?php
function storeVerifiedData(string $sessionId, array $verifiedData): void
{
    $key = base64_decode(getenv('PII_ENCRYPTION_KEY')); // 32 bytes
    $iv = random_bytes(12); // GCM nonce

    $plaintext = json_encode($verifiedData, JSON_THROW_ON_ERROR);

    $tag = '';
    $ciphertext = openssl_encrypt(
        $plaintext,
        'aes-256-gcm',
        $key,
        OPENSSL_RAW_DATA,
        $iv,
        $tag
    );

    $stored = base64_encode($iv . $tag . $ciphertext);

    $stmt = $pdo->prepare(
        'INSERT INTO kyc_results (session_id, encrypted_data, created_at)
         VALUES (?, ?, NOW())'
    );
    $stmt->execute([$sessionId, $stored]);

    // Audit log
    auditLog('store_pii', ['session_id' => $sessionId, 'user' => currentUser()]);
}

Data retention

Recommended retention periods for verified_data in your systems:

Purpose	Retention period	Basis
Statutory KYC for banks and fintech companies	5 years after the relationship ends	AML Act
Basic KYC for premium e-commerce	2 years	Evidentiary purposes
One-time verification	Until the session is complete	Data minimization principle

When the retention period expires, delete the data or anonymize it irreversibly.