KYC & Account Lifecycle

Version 1.0 — Last Updated: 18-11-2025

This document describes ChainGuard's identity verification (KYC/KYB), AML screening, and account lifecycle management. It explains how we onboard users, handle flagged cases, manage account restrictions, and cooperate with authorities.

Table of Contents

• 1. KYC / KYB Configuration
  • 1.1 Baseline KYC (All Jurisdictions)
  • 1.2 Data Storage & Minimization
  • 1.3 KYB (Business Verification)
  • 1.4 User → Vault → Wallet Mapping
• 2. Initial AML Screening
  • 2.1 One-Time Screening at Onboarding
  • 2.2 User Consent & Account Creation Requirements
  • 2.3 Handling Flagged Results
  • 2.4 Additional Client Screening (Post-Account Creation)
• 3. Ongoing AML Monitoring (Optional Service)
  • 3.1 Default: Disabled
  • 3.2 Optional Add-On for Enterprise Clients
• 4. Transaction & Wallet Logging
  • 4.1 What We Log
  • 4.2 Restrictions & Rules
• 5. Account Creation, Blocking & Reporting Policy
  • 5.1 Account Creation Requirements
  • 5.2 Post-Onboarding Reviews and Wallet-Related Screening
  • 5.3 Cooperation with Authorities
• 6. Relationship to Client Policies
  • 6.1 ChainGuard's Platform Requirements vs. Client Policies
  • 6.2 Travel Rule Position
• 7. Jurisdiction-Specific Configuration
• 8. Summary: Capabilities vs Our Choices
• Related Documentation
• Contact

---

1. KYC / KYB Configuration

1.1 Baseline KYC (All Jurisdictions)

For all supported jurisdictions (EU, US, UK, UAE, Singapore, Hong Kong, Japan, South Korea), ChainGuard enables the following Sumsub verification steps:

Enabled by default:

• APPLICANT_DATA – Personal details (name, date of birth, nationality, address fields)
• IDENTITY – Document verification (passport, national ID, driver's license, etc.)
• SELFIE / Liveness – Biometric liveness check and face-match verification

Optional per client / risk policy:

• PROOF_OF_RESIDENCE – Proof of address where required by client policy, jurisdiction, or risk classification

1.2 Data Storage & Minimization

After Sumsub completes KYC verification, ChainGuard follows a data-minimization approach:

What we store in our private database:

• Sumsub applicantId (reference identifier)
• Normalized identity fields (name, date of birth, country, address)
• Verification status and decision result (approved/declined/needs review)
• Risk tier / labels (where available)
• Timestamps and jurisdiction mapping

What we do NOT store:

• Raw document images
• Selfie photos or biometric templates
• Full document numbers (unless required by law)

Raw document images, selfies, and biometric templates remain hosted by Sumsub and are only referenced via IDs when absolutely necessary (e.g., for audits or legal requests). This aligns with data-minimization principles and reduces our data protection obligations.

1.3 KYB (Business Verification)

Where enterprise clients require KYB (Know Your Business):

• Sumsub performs KYB on the organisation (registry checks, UBO mapping, corporate documents)
• We store:
  • Organisation identifiers (name, registration number, jurisdiction)
  • UBO mapping (references to individual applicants in Sumsub)
  • KYB status & risk classification
• All raw corporate documents stay at Sumsub unless a client explicitly instructs otherwise

1.4 User → Vault → Wallet Mapping

Once a user has passed KYC and is mapped to a jurisdiction, we maintain internal mappings:

• userId ↔ Sumsub applicantId
• userId ↔ one or more vaults
• userId ↔ one or more wallets / on-chain addresses
• userId ↔ jurisdiction/region

This mapping is stored in our own database, based on data pulled from Sumsub and our own product logic.

2. Initial AML Screening

2.1 One-Time Screening at Onboarding

At the moment a user passes KYC:

• Sumsub runs one baseline AML/sanctions screening on the person, not on any wallet or on-chain activity
• We ingest:
  • Pass/fail outcome
  • Flags/labels (e.g., PEP, sanctions hit, adverse media present)
  • Screening timestamp and screening ID
• We log this in our internal audit trail linked to the user identity and jurisdiction

2.2 User Consent & Account Creation Requirements

ChainGuard acts as a controller for initial onboarding and account creation.

Before any account can be created, ChainGuard requires:

• User consent to undergo KYC and AML screening
• Successful KYC verification (identity + liveness + document verification)
• Passing initial AML/sanctions screening with no flags or hits

This requirement applies to all users regardless of whether they are direct ChainGuard users or users of enterprise clients. ChainGuard maintains this standard as part of our platform security and compliance obligations.

2.3 Handling Flagged Results

If the initial AML screening returns a hit, inconclusive result, or other material risk indicator:

• ChainGuard will not finalize account creation until:
  • The result has been reviewed, and
  • A reasonable explanation and supporting evidence have been obtained where appropriate, or
  • The risk has been mitigated to an acceptable level
• The account may remain in a pending, restricted, or rejected state depending on the final risk decision

ChainGuard's role as controller for account creation:

• For initial account creation, ChainGuard always acts as a controller and requires users to pass KYC and initial AML screening before account activation
• This requirement is non-negotiable and applies to all users with their explicit consent
• Enterprise clients cannot bypass this requirement, as it is a core platform security standard

2.4 Additional Client Screening (Post-Account Creation)

Once a user has successfully passed ChainGuard's initial KYC and AML screening and their account is created (unflagged state), enterprise clients may require additional screening based on their own risk policies or regulatory obligations.

Important: Additional client screening:

• Does not change the user's permissions or account status if they remain in an unflagged state with ChainGuard
• Is separate from ChainGuard's initial onboarding requirements
• May be implemented through our APIs or optional continuous monitoring services
• Remains the responsibility of the client for their own compliance purposes

3. Ongoing AML Monitoring (Optional Service)

3.1 Default: Disabled

By default, ChainGuard does not run continuous AML monitoring for every user.

3.2 Optional Add-On for Enterprise Clients

For clients who require additional screening beyond ChainGuard's initial onboarding requirements, we can configure:

• Periodic re-screening of users against sanctions/PEP/adverse media lists, on a configured schedule (e.g., nightly or monthly)
• Escalation webhooks into the client's compliance system and internal ChainGuard logs

Scope of optional service:

• Scheduled re-screening of their user base (e.g., daily/weekly/monthly), using Sumsub's AML tools or another agreed provider
• Alerts surfaced via:
  • Webhooks to the client's case management system
  • Dashboards inside the client's ChainGuard admin panel

Data handling:

• We keep only the screening status, reason codes, and timestamps, linked to users and wallets
• The raw screening data remains with the AML vendor

Important: User permissions and unflagged state

• Additional client screening does not change a user's account permissions or status if they remain in an unflagged state with ChainGuard
• Users who have passed ChainGuard's initial KYC and AML screening maintain their account access and permissions regardless of additional client screening
• Client screening is for the client's own compliance purposes and does not affect ChainGuard's platform-level account status

Responsibility split:

• ChainGuard: Run the technical process and deliver structured alerts/logs for client screening
• Client: Own the AML program, investigation, SAR/STR filing, and final decisions for their own compliance purposes

In all scenarios:

• ChainGuard maintains the initial onboarding standard (KYC + AML pass required for account creation)
• Clients remain responsible for defining risk appetite, thresholds, and case-handling playbooks for their additional screening requirements

4. Transaction & Wallet Logging

4.1 What We Log

We log movements, not restrict them:

• Vault ↔ Vault: Transfers between vaults for user A and user B
• Wallet ↔ Wallet: Transfers between on-chain addresses A and B
• Vault ↔ Wallet: Deposits/withdrawals between ChainGuard vaults and external wallets

For every movement we log:

• Source and destination identifiers (vault ID, address, internal user refs)
• Amount, asset type, chain/network
• Timestamps, initiating device/session, approval path
• Jurisdiction tags of the participating users (where mapped)

These logs support:

• Client-side AML/monitoring rules
• Forensic analysis & incident response
• Compliance audits and regulator requests

4.2 Restrictions & Rules

• ChainGuard itself does not impose transaction restrictions by default
• Our role is to supply accurate data and logging
• Enterprise clients can implement their own restriction policies (e.g., block sanctioned addresses, set velocity limits) via:
  • Our APIs
  • Their own rules engine consuming our logs and events
  • Optional integrations we may build for them

5. Account Creation, Blocking & Reporting Policy

5.1 Account Creation Requirements

ChainGuard acts as controller for initial account creation

ChainGuard requires all users to pass initial KYC and AML screening before account creation. This is a platform-level requirement that applies to all users, regardless of whether they are direct ChainGuard users or users of enterprise clients.

Pre-conditions for account creation:

1. User consent - Users must explicitly consent to undergo KYC and AML screening before any account creation process begins
2. Successful KYC - Identity + liveness + document verification must be completed and approved
3. Passing initial AML check - Initial sanctions/AML screening must return no flags or hits

A user account is only fully activated after all three conditions are met. This requirement is non-negotiable and applies universally across the ChainGuard platform.

Flagged or inconclusive results

If the initial AML screening returns a hit, inconclusive result, or other material risk indicator:

• ChainGuard will not finalize account creation until:
  • The result has been reviewed, and
  • A reasonable explanation and supporting evidence have been obtained where appropriate, or
  • The risk has been mitigated to an acceptable level
• The account may remain in a pending, restricted, or rejected state depending on the final risk decision

Enterprise clients cannot bypass this requirement - all users must pass ChainGuard's initial KYC and AML screening before account creation, regardless of any additional screening the client may require.

5.2 Post-Onboarding Reviews and Wallet-Related Screening

Subsequent screening events

After a user account is active, additional reviews can be triggered by:

• Wallet or transaction screening performed on behalf of a vendor/client
• Internal risk signals (e.g., abnormal patterns in vault ↔ vault or wallet ↔ wallet movements)
• External reports or official notifications

Right to restrict during investigation

Where there is a reasonable suspicion of:

• Money laundering or terrorist financing
• Fraud, abuse, or unauthorised use of the platform
• Breach of contractual terms or applicable law

ChainGuard may, acting reasonably and in line with applicable law:

• Temporarily block or restrict the relevant account(s) and/or vaults
• Request an explanation and, where appropriate, supporting documentation from the user and/or the client
• Defer or decline certain transactions until the review is complete

Outcome of a review

Possible outcomes of such a review include, without limitation:

• No further action (activity explained and considered acceptable)
• Continued monitoring and risk re-classification
• Temporary restrictions being lifted or modified
• Account or vault closure and termination of access
• Escalation to the relevant client's compliance function, or to competent authorities where required by law

5.3 Cooperation with Authorities

Legal basis

ChainGuard will cooperate with law-enforcement agencies, regulators, tax authorities, and other competent bodies where we are legally obliged to do so (e.g., under AML/CTF, sanctions, fraud, or other applicable laws), or where we have a strong legitimate interest in protecting other users, the platform, or third parties.

Types of data that may be disclosed

Subject to applicable data protection laws and only to the extent necessary, the categories of data that may be disclosed include:

• Verified identity data (e.g., name, date of birth, contact details)
• Account identifiers and internal IDs
• Vault and wallet associations
• On-platform and on-chain transaction history
• Device, network, and access metadata (e.g., IP addresses, user agent, login timestamps)
• Relevant logs and audit-trail records

Conditions for disclosure

As a rule, ChainGuard will only disclose such data:

• In response to a valid legal request (e.g., court order, warrant, subpoena, or equivalent official notice), or
• Where immediate disclosure is justified to prevent serious harm or comply with urgent legal obligations, and where permitted by law

No guarantee of non-reporting

Users should not assume that a lack of prior criminal or AML history guarantees anonymity or non-reporting. Where a user's behaviour, in our reasonable opinion, falls outside what can be expected of a user who has agreed to our Terms, Policies, and Acceptable Use rules, we may report such behaviour together with relevant identifiers to competent authorities in accordance with applicable law.

For more information on data sharing with authorities, see our Data Protection & Privacy page.

6. Relationship to Client Policies

6.1 ChainGuard's Platform Requirements vs. Client Policies

ChainGuard's platform-level requirements (controller role):

• All users must pass initial KYC and AML screening before account creation
• This requirement applies universally and cannot be bypassed by clients
• Users must provide explicit consent before undergoing screening
• ChainGuard acts as controller for this initial onboarding process

Client-specific requirements (processor role):

Many enterprise clients will operate their own AML/CTF and sanctions policies, which may require additional screening beyond ChainGuard's initial requirements.

Where we act as a processor for additional client screening:

• We implement the technical restrictions and alerting requested by the client
• We provide the logs and data necessary for them to comply with their obligations
• Important: Additional client screening does not affect a user's account permissions or status if they remain in an unflagged state with ChainGuard

Clear separation:

• Initial onboarding (ChainGuard as controller): Required for all users, cannot be bypassed
• Additional client screening (ChainGuard as processor): Optional, based on client requirements, does not change unflagged user permissions

Nothing in this document limits a client's right or obligation to impose additional controls, block or close accounts, or file reports with authorities under their own regulatory perimeter. However, clients cannot bypass ChainGuard's initial KYC and AML requirements for account creation.

6.2 Travel Rule Position

Even though Sumsub offers extensive Travel Rule tooling, our current operating model is:

Travel Rule: NOT APPLIED by ChainGuard

• ChainGuard does not act as the sending or receiving VASP/CASP
• We do not originate or receive crypto transfers on behalf of customers; we provide signing, vault, and logging infrastructure
• Therefore, regulators' Travel Rule obligations normally fall on the regulated institutions using ChainGuard, not on ChainGuard itself

Implications:

• Travel Rule features described in vendor assessments are available in the ecosystem but out of scope for our own system at this time
• If a client is a VASP/CASP and needs Travel Rule compliance:
  • They must implement a Travel Rule solution (Sumsub or another provider) in their own stack
  • ChainGuard can expose necessary transaction and identity references (IDs & logs) to support their obligations

We will revisit this assumption if:

• ChainGuard's role expands into direct transaction processing, or
• A regulator explicitly interprets our role as falling within a Travel Rule perimeter

7. Jurisdiction-Specific Configuration

ChainGuard uses jurisdiction profiles to:

• Tag users by country of residence / regulatory region at the time of KYC
• Configure KYC level variants where a client's policy requires stricter controls (e.g., PoA for certain regions)
• Drive reporting and dashboards (e.g., user distribution by region, risk tier per region)
• Inform future, optional services (e.g., region-specific continuous AML packages)

We do not currently:

• Apply region-specific hard blocks or differentiated restrictions at protocol level ourselves
• Localise storage beyond the EU default for KYC data (unless a client contractually asks for a specific Sumsub Local Data Processing region)

For jurisdiction-specific compliance requirements, see our jurisdiction pages.

8. Summary: Capabilities vs Our Choices

Related Documentation

• Data Protection & Privacy - How we handle personal data and user rights
• VAT & AML - AML framework and compliance obligations
• Sanctions & Restrictions - Sanctions screening and prohibited jurisdictions
• Global Compliance - Overall compliance framework
• Project Architecture - Technical documentation

Contact

For questions about KYC, account lifecycle, or screening policies:

• Data Protection Officer (DPO): privacy@chain-fi.io

---

Next: Review jurisdiction-specific compliance or explore other compliance topics.