KYC and admin identity

Identity guide

Use this guide to understand how tenant invite onboarding confirms the administrator: Google email match, country-specific identity fields, email fallback, and Swedish add-on checks.

Admin identity Google verification Country rules

Identity requirements depend on admin country, tenant risk, requested services, and KYC review.

Step 1 Start with the invite and Google session International activation uses an invite-bound Google session before the admin identity is confirmed.

The public identity check does not start from a standalone form. It is tied to the invite flow and the Google session that matches the invite recipient.

  • open the invite start link and continue with the Google account that received the invite;
  • if the Google address does not match the invite recipient, activation is blocked or moved to review;
  • contact support if the invite address, Google session, or admin profile does not match.
Step 2 When admin identity is optional or required The backend catalog decides whether the country needs a national identifier before activation or whether the verified email is enough for now.

The rule follows the tenant admin country selection, not just the tenant company country.

  • Sweden requires a personnummer before activation;
  • the United Kingdom requires a National Insurance number before activation;
  • the United States requires the last four digits of SSN before activation;
  • for other countries, the verified invite email can remain the fallback until a KYC-gated service needs more.
Step 3 Country-specific identifier capture comes from the backend The form shows the label, placeholder, and validation loaded from the shared country catalog.

When you choose the admin country, the onboarding view loads the matching country row from the backend catalog.

  • the field name and example change with the country, such as Personnummer, NINO, or SSN4;
  • validation is normalized server-side before the identity is stored or linked to the Google session;
  • unknown or less strict countries fall back to a sanitized national identifier field instead of a fabricated hard rule.
Step 4 Google-verified email as fallback When the country does not require a strict identifier at activation, the verified invite email can remain the active admin identity for now.

The fallback stays limited to the verified session and does not claim that every later service unlocks without more evidence.

  • the fallback applies only when the backend rule for that country allows it;
  • later services involving accounting, credits, partner chains, or other higher-risk workflows can still require a national identifier;
  • sensitive identity values should be handled server-side rather than stored in browser local storage.
Step 5 Swedish add-ons that already exist Swedish legacy support stays in place as a separate add-on layer when those service paths are used.

This international article does not expand the Swedish deep path, but it does not hide that some Swedish service chains already use more checks.

  • Swedish flows may use BankID, Bolagsverket lookups, or Kivra-related checks;
  • those steps are additive and contextual, not a rule for every international tenant;
  • Swedish legacy support remains available on its existing Swedish guidance path instead of being duplicated here.