Consent Management

TrustGate helps you record and track consent for data processing activities, ensuring compliance with GDPR Articles 6 and 7.

When Consent is Needed

KYC/AML Processing

For mandatory compliance activities, consent is typically NOT the appropriate legal basis:

Activity	Lawful Basis	Why Not Consent
Identity verification	Legal obligation	Required by AML law
Sanctions screening	Legal obligation	Required by sanctions law
Document collection	Legal obligation	Required for KYC

Optional Processing

Consent IS appropriate for optional activities:

Activity	Requires Consent
Marketing communications	Yes
Optional biometric features	Yes
Data sharing with third parties	Yes (if not required)
Analytics beyond compliance	Yes

Consent Types Reference

Type	Description	Required
terms_of_service	Agreement to terms	Yes
privacy_policy	Acknowledgment of privacy policy	Yes
biometric_verification	Face matching consent	Jurisdiction-dependent
data_sharing	Third-party data sharing	If applicable
marketing	Marketing communications	No
ongoing_monitoring	Continuous screening	Jurisdiction-dependent

Recording Consent

TrustGate provides a single endpoint for both granting and withdrawing consent. Consent is recorded at the applicant level.

API Endpoint

POST /api/v1/applicants/{applicant_id}/consent

Grant Consent

curl -X POST https://api.bytrustgate.com/api/v1/applicants/550e8400-e29b-41d4-a716-446655440000/consent \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "consent": true,
    "purpose": "Identity verification and KYC processing"
  }'

Withdraw Consent

Use the same endpoint with consent: false:

curl -X POST https://api.bytrustgate.com/api/v1/applicants/550e8400-e29b-41d4-a716-446655440000/consent \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "consent": false,
    "purpose": "User requested withdrawal"
  }'

Request Body

Field	Type	Required	Description
consent	boolean	Yes	true to grant consent, false to withdraw
purpose	string	No	Purpose of data processing (max 500 characters)

Response

{
  "status": "consent_recorded",
  "consent_given": true,
  "consent_given_at": "2026-01-20T14:30:00Z",
  "applicant_id": "550e8400-e29b-41d4-a716-446655440000"
}

Field	Type	Description
status	string	Always "consent_recorded"
consent_given	boolean	Current consent state
consent_given_at	datetime or null	When consent was last granted (null if withdrawn)
applicant_id	UUID	The applicant's ID

How Consent is Stored

Consent is tracked directly on the Applicant model with the following fields:

Field	Type	Description
consent_given	boolean	Whether consent is currently active (default: false)
consent_given_at	datetime or null	Timestamp when consent was last granted
consent_ip_address	string(45) or null	IP address of the client when consent was recorded (supports IPv4 and IPv6)
consent_withdrawn_at	datetime or null	Timestamp when consent was last withdrawn

Granting Consent

When consent: true is submitted:

• consent_given is set to true
• consent_given_at is set to the current timestamp
• consent_ip_address is captured from the request
• consent_withdrawn_at is cleared (set to null)

Withdrawing Consent

When consent: false is submitted:

• consent_given is set to false
• consent_withdrawn_at is set to the current timestamp
• consent_given_at is preserved for audit purposes

SDK Workflow Integration

The TrustGate SDK includes consent as the default first step in the verification workflow. When an applicant begins a verification session, they are presented with a consent step before any identity checks begin.

The default SDK workflow step:

{
  "name": "consent",
  "title": "Data Processing Consent",
  "description": "We need your consent to process your personal data for identity verification.",
  "required": true
}

When the consent step is completed through the SDK, the applicant's consent_given and consent_given_at fields are automatically updated.

Audit Trail

Every consent action is recorded in the audit log via the audit_consent_recorded() function. This creates an immutable record that references GDPR Articles 6 and 7.

Audit Log Actions

Action	When
gdpr.consent_given	Consent is granted
gdpr.consent_withdrawn	Consent is withdrawn

Audit Log Data

Each audit entry records:

• The consent state (true or false)
• The client IP address at the time of the action
• The user who performed the action
• GDPR article references (6 and 7)
• Resource type (applicant) and the applicant ID

Consent Requirements by Jurisdiction

Different jurisdictions have varying requirements for when explicit consent is needed:

Jurisdiction	Key Requirements
EU (GDPR)	Explicit consent for biometrics; must be freely given, specific, informed, and unambiguous
US - Illinois (BIPA)	Written consent required before collecting biometric identifiers
US - Default	Privacy policy acknowledgment typically sufficient for KYC
UK (UK GDPR)	Similar to EU GDPR; explicit consent for special category data
Canada (PIPEDA)	Meaningful consent; must understand what they are consenting to

For GDPR compliance, consent must meet four criteria as enforced by the API:

1. Freely given -- not bundled with other agreements
2. Specific -- the purpose field should clearly describe what processing will occur
3. Informed -- the applicant must understand what they are agreeing to
4. Unambiguous -- recorded via an explicit affirmative action

---

Next Steps

• Evidence Export - Export compliance evidence
• GDPR Compliance - Privacy requirements
• Audit Logging - Track all actions