KYC and onboarding

KYC requirements

DynamicMail may request tenant and administrator details when they are needed to protect account integrity, document workflows, integration access, software credit controls, and partner-dependent services. This is a product policy page. It does not mean DynamicMail is a bank, stored-value provider, or payment institution.

Why checks exist

  • to reduce identity fraud, unauthorized workspace access, and misuse of invite flows;
  • to protect documents, signing, data rooms, Gmail and accounting integrations, and agent execution;
  • to detect sanctions exposure, misleading entity details, and elevated risk in business model or geography;
  • to decide which services can be activated immediately and which need manual review first.

What we may ask for

  • the tenant’s legal name, registration number, tax or VAT identifiers, address, website, and business description;
  • public-source evidence showing real business activity, contact paths, and legal pages;
  • the administrator’s first name, last name, address, country, email, and country-specific identity value where required;
  • a Google-verified email session for invite-bound international onboarding;
  • extra explanation about ownership, roles, use case, or integration needs when risk requires it.

When verification usually happens

  1. You open an invite or onboarding link and DynamicMail loads the tenant profile that was prepared for that flow.
  2. You choose country, confirm administrator details, and provide country-specific identity information where it is required.
  3. For international onboarding, a Google-verified administrator session is linked to the invite before activation.
  4. The system decides whether the tenant can activate immediately or needs manual review before more services open.

Swedish flows may also use local identity, registry, or digital-mailbox checks when the selected service paths allow them.

Services that may need extra checks

  • accounting or Gmail synchronization;
  • higher-volume agent execution or automated document workflows;
  • credit allocation and usage controls during onboarding or upgrade;
  • signing, registered-letter, or data-room workflows involving sensitive counterparties;
  • unusual patterns in geography, traffic, document type, or identity evidence.

What changes after verification

  • DynamicMail can activate workspace access and bind the invite administrator to the tenant account;
  • some integrations or services may remain gated until risk review is complete;
  • support may use server-side verification records for corrections, traceability, and audit review;
  • a completed check does not guarantee approval by every future service, partner, or jurisdiction.

Unsupported and prohibited activity groups

DynamicMail may reject, pause, or restrict tenants that try to use the platform for activity that conflicts with product policy, partner requirements, or lawful use. Example groups we do not support:

  • gambling, betting, adult services, arms trade, or dual-use goods trade;
  • unlicensed lending, insurance intermediation, or other financial services that need regulatory permission;
  • fraud, phishing, impersonation, fake invoicing, VAT carousel schemes, or other tax-evasion structures;
  • shell entities that cannot show beneficial ownership transparency or business substance;
  • modern slavery indicators, predatory practices aimed at vulnerable groups, or property misrepresentation;
  • hate, threats, violence, extremist content, unauthorized mass spam, link-dump campaigns, or read-receipt and identity-switch abuse;
  • personal data misuse in metadata, reverse engineering, technical abuse, or persistent unpaid overuse;
  • sanctions exposure, prohibited financial-promotion activity, or any other material legal, operational, or reputational risk.

Data minimization

  • sensitive identity fields are not meant to live in browser local storage as part of onboarding;
  • server-side records are used for security, support, audit, policy review, and service eligibility;
  • public-source tenant research can be reviewed internally before activation;
  • you can contact support if data needs correction.

Software credits are not money

Any credits described in DynamicMail refer to software or service usage. They are not deposits, cash, e-money, stored value, or freely transferable payment instruments.

If a workflow depends on external payment rails or partner checks, separate terms and eligibility rules may apply.

Questions about identity requirements, service eligibility, or corrections can be sent to support@dynamicmail.ai. We use verification details to protect workspaces, integrations, and usage controls.