Global Compliance Overview

Table of Contents

• Overview
  • Who we are
  • At a glance
• How the ChainGuard OAuth Bridge Works
  • Our Approach
• What We Already Implement (Global, by Default)
• Compliance Implementation by Stack Component
  • Backend (chainfi-backend)
  • Database (chainfi-database)
  • Portal (chainguard.chain-fi.io)
  • Mobile App (ChainGuard 2FA)
• Cross-Jurisdiction Pattern: Crypto / Web3 Compliance Convergence
• What the OAuth Scopes/Claims Typically Expose to Relying Parties
• What We Are NOT
• How This Maps to the ChainFi Stack
  • How the Flow Works
• Flow Legend & Compliance Mapping
  • Flow Legend
  • Data Processing & Compliance by Step
  • Overall Compliance Status by Jurisdiction
• Governance
• Related Documentation
• Contact

---

Overview

Welcome to the ChainGuard Compliance Center. This area explains how ChainGuard's products fit within current regulatory frameworks and how we handle identity, data, and auditability across jurisdictions.

ChainGuard provides non-custodial Web3 security and identity infrastructure. We give regulated businesses the tools to bind wallets to verified users, enforce policy, and generate audit trails — but we never hold client assets or control user funds.

Who we are

ChainGuard is a product suite developed by Chain-Fi Labs and operated under Chain-Fi Limited, a company registered in England & Wales.

For contractual and regulatory purposes, references to "ChainGuard", "Chain-Fi", "we", or "our" in this Compliance Center mean Chain-Fi Limited (and its Chain-Fi Labs development team) unless stated otherwise.

At a glance

• Role: Technology / infrastructure provider, not an exchange, broker, or custodian.

• Architecture: Non-custodial by design – users keep control of their keys and assets at all times.

• Governance: Compliance is overseen by CEO & Founder Dennis Reckermann and the Board.

• Coverage: Jurisdiction-specific sections (EU, US, UK, UAE, Singapore, Hong Kong, etc.) explain how we align with local rules (GDPR, CCPA/CPRA, MiCA, AML/CTF, Travel Rule).

• Documentation: Linked policies cover governance, security, data protection, AML/CTF, sanctions, and record-keeping.

How the ChainGuard OAuth Bridge Works

Problem we solve: DApps need proof and attributes (KYC status, device risk, wallet binding, audit trail) — not custody of user assets.

Our Approach

• No direct connection between DApps and user assets. DApps never get keys or custody; they only receive permission-scoped claims (e.g., "KYC_verified=true", "wallet=0x… belongs to user X", "device=attested, exp=…") issued by our gateway. App permissions and allowed functions are explicitly registered per AppID.

• Device → wallet binding with optional KYC proof. We register device–wallet links and can attach KYC provider evidence (Sumsub) at the "identity folder."

• Cryptographic assurance on messages. Mobile responses can be guardian-signed; the server also attaches a second, signed copy. The web client receives both versions (unsigned + signed) and verifies.

• Signer + device attestation 2FA. Requests can require a second factor on an attested device; the gateway signs payloads using the app's guardian key (ECDSA) for verification.

• Immutable audit trail. Every session message is stored with session_id, device_id, wallet_address, app_id, function_name, and raw payload/response — giving exporters an end-to-end, queryable record.

• Compliance center & multilingual structure. All of this is surfaced per-jurisdiction in our Compliance Center, localized, and linked from GEO pages.

What We Already Implement (Global, by Default)

• Non-custodial architecture (no private keys, no transmission, no custody). VAT/AML doc explicitly positions us outside MSB/VASP/custody roles while still meeting AML-compatible controls.

• Identity, wallet, and device binding with optional KYC tiers; clear data-minimization and legal bases by feature.

• Audit logs & governance (roles, retention: AML 5y, tax 6–7y, immutable logs linked to identity+wallet+device).

• Sanctions & prohibited use enforcement (OFAC/EU/UK/UN alignment; wallet screening, geo/IP restrictions).

• VAT/GST compliant billing (crypto→fiat timestamped FX, invoice lines, OSS/UK VAT/JCT/KR VAT/SG GST coverage).

• Server-side cryptographic validation & audit chains (design pattern used across the stack).

Compliance Implementation by Stack Component

Backend (chainfi-backend)

Implemented:

• Audit logging infrastructure: Comprehensive logging of user activities, security events, connections, and session activity.
• OAuth 2.0 service: Full OAuth flow with authorization codes, access tokens, refresh tokens, scope management, and client registration.
• Device-wallet binding: Device ID to wallet address mapping with signature verification capability.
• Session management: Session tracking with session_id, device_id, wallet_address, app_id for audit trails.
• Security event tracking: Failed auth attempts, suspicious activity detection, rate limiting integration points.
• Database schema: Immutable audit trail structure with indexes for compliance queries (5-7 year retention capability).

Needs implementation:

• KYC provider integration (Sumsub/other) with evidence storage.
• Sanctions screening service (OFAC/EU/UK/UN wallet address checks).
• Device attestation verification (Apple/Google attestation API integration).
• VAT/GST invoice generation service.
• Jurisdiction-specific data retention policies and automated archival.

Database (chainfi-database)

Implemented:

• User identity tables: users, user_profiles with GDPR-compatible soft deletes.
• 2FA binding: user_2fa table linking users to wallet addresses for 2FA.
• OAuth tables: Full OAuth 2.0 schema with scopes, permissions, token lifecycle.
• Audit tables: connection_logs, session_activity, security_events, user_activity with JSONB for flexible compliance data.
• Indexes: Optimized for compliance queries (user_id, created_at, event_type, severity).

Needs implementation:

• KYC evidence table (provider_ref, tier, jurisdiction, expiry, verification_status).
• Device attestation table (device_id, platform, attestation_proof, expiry, risk_flags).
• Sanctions screening results table (wallet_address, screening_date, result, list_name).
• Invoice/billing tables (invoice_id, user_id, jurisdiction, VAT/GST amount, timestamped FX rates).

Portal (chainguard.chain-fi.io)

Implemented:

• OAuth consent screens: User-facing scope review and approval.
• 2FA setup/verification flows: Mobile QR code scanning for device-bound 2FA.
• Activity history dashboard: User-visible audit trail.
• App access management: Permission review and revocation UI.

Needs implementation:

• KYC verification flow UI (triggered by scope requests, provider integration).
• Jurisdiction-specific consent language and data rights notices (GDPR, PDPA, etc.).
• Device attestation status display.
• Invoice/billing history UI.

Mobile App (ChainGuard 2FA)

Implemented:

• QR code scanning: Device-bound signature verification for 2FA.
• Wallet management: Local wallet storage and signing capability.
• Privacy policy: User-facing compliance documentation.

Needs implementation:

• Device attestation API calls (Apple App Attest / Google Play Integrity).
• Guardian signature generation for compliance proofs.
• KYC verification prompts when required by scopes.
• Transaction-specific approval flows with audit trail generation.

Cross-Jurisdiction Pattern: Crypto / Web3 Compliance Convergence

Across all jurisdictions, authorities are converging on a similar pattern for virtual-asset compliance:

• Clear KYC of the user
• Strong authentication and device binding
• Wallet / account attribution (who controls which address)
• Travel Rule-style data sharing between VASPs
• Tamper-resistant audit trails

ChainGuard is purposely designed as the technical bridge between those regulatory expectations and the practical reality of wallets, smart contracts and dApps:

• Device attestation (Apple/Google) – Needs implementation
• Bound to KYC-verified identities (via providers like Sumsub) – Needs implementation
• Mapped to specific wallets / vaults – Implemented
• Governed by policies and logged cryptographically – Implemented

The story: Different jurisdictions, different rules – but the same primitives: identity, devices, wallets, and logs. ChainGuard doesn't try to be the regulator or the national ID – it gives regulated entities and dApps the building blocks to meet these rules in a consistent, verifiable way.

What the OAuth Scopes/Claims Typically Expose to Relying Parties

• Identity status: kyc_verified, jurisdiction, tier, provider_ref (no raw PII unless contractually required).
• Wallet ownership: address, binding_method=device_attestation, bound_device_id, attestation_exp.
• Device assurance: platform=ios/android, attested=true, signature=guardian, last_seen, risk_flags.
• Event/audit views: filtered message_history slices (session, operation, timestamp, result, tx refs) for regulated audits.

These are delivered permission-based, time-limited, and are verifiable via guardian signatures/server signatures as needed.

What We Are NOT

• We are not a custodian, MSB/VASP, exchange, payment processor, or qualified eID/QTSP. We integrate with those roles and provide the security, attribution, and audit layer they rely on.

How This Maps to the ChainFi Stack

See our Project Layout documentation for detailed architecture information.

📊 View Architecture Diagram▼

How the Flow Works

Initial Authentication (Steps 1-5)

When a user wants to connect their wallet to a dApp, here's what happens:

1. The user's browser (Client Frontend) redirects them to the ChainGuard Portal (chainguard.chain-fi.io). The browser never sees any tokens or secrets, which eliminates frontend security risks.

2. The ChainGuard Portal is where users log in, review what permissions the dApp is requesting, and complete their identity verification. This portal captures all consent decisions and stores AML/KYC acknowledgments with timestamps, creating a clear audit trail of what users agreed to.

3. For additional security, the portal connects to the ChainGuard 2FA App on the user's mobile device. This app provides device-bound authentication and generates cryptographic proofs that the device is legitimate and hasn't been tampered with. This satisfies regulatory requirements for strong authentication (like MAS TRM and NIST AAL standards).

4. The ChainFi Backend is the central system that issues authorization codes, access tokens, and refresh tokens. It tracks all API usage and maintains the official record of what scopes users consented to, what audit IDs were generated, and when everything happened. This backend operates under ISO 27001 controls, ensuring proper access management, encryption, and comprehensive logging.

5. Once authenticated, the backend sends permission-scoped tokens to the Client Backend (the dApp's server). Importantly, the dApp's server only receives tokens with specific permissions—never user secrets or private keys. This ensures ChainGuard maintains its non-custodial posture, as we never have custody of user assets.

Post-Authentication Requests (Steps 6-10)

After OAuth authentication is complete, the dApp can make specific requests for actions like transaction signing or approvals:

1. Request initiation: The Client Frontend can make requests directly to the ChainFi Backend, OR the Client Backend can make requests on behalf of the frontend. Both paths are supported depending on the client's architecture. These requests are for specific actions like transaction approvals, vault operations, or other wallet-bound operations.

2. Portal approval flow: When an action is requested, the ChainFi Backend routes the approval request to the ChainGuard Portal, where the user can review what action is being requested.

3. User signing: The user reviews the request in the portal and uses the ChainGuard 2FA App to sign or approve the specific transaction. This requires fresh 2FA/3FA authentication for each action, ensuring every operation is explicitly authorized.

4. Signature verification: Once the user signs the transaction in the mobile app, the signature is sent back to the ChainFi Backend for verification and execution.

5. Notification: After execution, the ChainFi Backend notifies either the Client Frontend (if the client uses direct frontend-to-backend communication) or the Client Backend (if the client uses a backend-mediated architecture). The notification includes transaction hashes, execution status, and proof of completion.

Data Storage & Compliance (Steps 11-12)

1. Public Database: All non-private, compliance-relevant data is stored in a Public Database. This includes:

   • Transaction hashes (on-chain, publicly verifiable)
   • Approved attestation logs (device verification records)
   • Connectivity logs (session activity, pseudonymized)
   • Pseudonymized audit trails (suitable for regulatory review without exposing PII)

2. Private Data Server: All sensitive user data is stored separately in a Private Data Server, including:

   • Personal Identifiable Information (PII)
   • User account details
   • Private keys (never stored - users maintain custody)
   • KYC verification data (if applicable)
   • Session tokens and authentication credentials

This separation ensures that compliance audits can access necessary transaction and attestation evidence without exposing private user data, while maintaining strict data protection for sensitive information.

Flow Legend & Compliance Mapping

Flow Legend

The following table maps each step in the architecture diagram to its corresponding route and description:

Data Processing & Compliance by Step

Step 1: Redirect

Data Processed: Redirect URL, client_id, state parameter, requested scopes

Data Protection: Minimal data collection (URL parameters only). No personal data processed at this stage.

Compliance Relevance: OAuth consent initiation, scope tracking for audit purposes.

Jurisdiction Requirements:

---

Step 2: OAuth Authorization

Data Processed: Authorization code, user session, consent decisions, scope approvals

Data Protection: User consent records, session identifiers. Consent must be explicit and revocable.

Compliance Relevance: OAuth 2.0 compliance, consent audit trail for regulatory review.

Jurisdiction Requirements:

---

Step 3: 2FA Request

Data Processed: Device identifier, QR code, session ID

Data Protection: Device binding data, authentication factors. Security measures required.

Compliance Relevance: Strong authentication requirements (AAL2/AAL3) for financial transactions.

Jurisdiction Requirements:

---

Step 4: Device Attestation

Data Processed: Device attestation proof, device integrity status, platform (iOS/Android)

Data Protection: Device security data, hardware attestation. Cryptographic security measures.

Compliance Relevance: Device integrity verification, tamper detection for regulatory compliance.

Jurisdiction Requirements:

---

Step 5: Token Delivery

Data Processed: Access token, refresh token, token scopes, expiration

Data Protection: Token storage (Client Backend only), scope limitations. Secure storage required.

Compliance Relevance: OAuth token lifecycle, scope enforcement for access control.

Jurisdiction Requirements:

---

Step 6a/6b: Action Request

Data Processed: Action type, transaction parameters, user ID, app ID, requested scopes

Data Protection: Action request metadata, user intent. Contract basis for processing.

Compliance Relevance: Transaction authorization, AML monitoring requirements.

Jurisdiction Requirements:

---

Step 7: Approval Routing

Data Processed: Transaction details, approval request, user session

Data Protection: User review data, approval interface. Explicit consent required.

Compliance Relevance: User consent for specific actions, audit trail for approvals.

Jurisdiction Requirements:

---

Step 8: Signing Request

Data Processed: Transaction payload, signing request, QR code

Data Protection: Transaction data for signing. Cryptographic security required.

Compliance Relevance: Transaction-specific authorization, regulatory approval requirements.

Jurisdiction Requirements:

---

Step 9: Signature Submission

Data Processed: Cryptographic signature, transaction hash, device proof

Data Protection: Signature data, cryptographic proof. Security measures required.

Compliance Relevance: Transaction execution authorization, regulatory proof requirements.

Jurisdiction Requirements:

---

Step 10a/10b: Notification

Data Processed: Transaction hash, execution status, block number, proof

Data Protection: Execution confirmation data. Contract fulfillment basis.

Compliance Relevance: Transaction completion notification, regulatory reporting.

Jurisdiction Requirements:

---

Step 11: Public Database

Data Processed: Transaction hashes, attestation logs (pseudonymized), connectivity logs, audit trails

Data Protection: Pseudonymized data, no PII. Research/statistics basis under GDPR.

Compliance Relevance: Regulatory audit access, compliance evidence without exposing PII.

Jurisdiction Requirements:

---

Step 12: Private Data Server

Data Processed: PII, user account details, KYC data (if applicable), session tokens, authentication credentials

Data Protection: Full PII protection required. Strict access controls and encryption mandatory.

Compliance Relevance: User data protection, privacy compliance across all jurisdictions.

Jurisdiction Requirements:

---

Overall Compliance Status by Jurisdiction

European Union (EU)

• GDPR: Compliant - All steps implement data minimization, consent management, and security measures
• MiCA: Partial - Non-custodial position clarified, CASP classification assessment ongoing
• eIDAS2: Partial - Device binding implemented, qualified eID status under evaluation
• Travel Rule: In Progress - Integration framework ready, KYC provider integration pending

United States (US)

• FinCEN MSB Rules: Compliant - Non-custodial architecture, transaction monitoring implemented
• CCPA/CPRA: Compliant - Privacy rights implemented, data minimization practiced
• State Regulations: Partial - NYDFS, DFPI requirements under review
• NIST AAL2/AAL3: Compliant - Strong authentication and device attestation implemented

United Kingdom (UK)

• FCA Crypto Asset Regime: Compliant - Non-custodial position, transaction records maintained
• UK GDPR: Compliant - Full GDPR-equivalent compliance
• HMRC VAT: Compliant - VAT-compliant invoicing implemented

United Arab Emirates (UAE)

• VARA Regulations: Partial - Service classification assessment ongoing
• UAE Federal DP Law: Compliant - Data protection measures implemented
• AML/CFT: Compliant - Customer due diligence and monitoring implemented

Singapore

• MAS PSA: Compliant - Non-payment service provider, exempt from licensing
• PDPA: Compliant - Privacy protection and data minimization implemented
• MAS TRM: Compliant - Strong authentication and device attestation implemented

Hong Kong

• SFC VASP Regime: Partial - VASP classification assessment ongoing
• PDPO: Compliant - Data protection measures implemented
• SFC Requirements: Compliant - Transaction records and audit trails maintained

Japan

• FSA PSA: Partial - Payment service classification under review
• APPI: Compliant - Privacy protection implemented
• FSA Requirements: Compliant - Security measures and transaction logging implemented

South Korea

• FIU AML Framework: Compliant - Transaction monitoring and reporting implemented
• PIPA: Compliant - Personal information protection implemented
• FIU Requirements: Compliant - VASP compliance measures implemented

Governance

ChainGuard maintains a formal governance structure with a dedicated security engineering function and executive oversight from CEO & Founder Dennis Reckermann and the Board. Regulatory and privacy considerations are embedded into product design, security, and operational processes.

For detailed governance information, see our Governance & Legal Structure page.

Related Documentation

• Project Architecture - Complete technical documentation
• Compliance by Jurisdiction - Region-specific compliance pages
• Governance & Legal Structure - High-level summary of our governance model
• Data Protection & Privacy - How we implement GDPR and privacy-by-design
• Security Framework - How security integrates with compliance
• VAT & AML - Tax and anti-money laundering

Contact

For compliance inquiries:

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

---

Next: Explore jurisdiction-specific compliance or review our compliance topics.