/connect-required-verification-information

name: connect-required-verification-information
description: >-
  Use this skill when the user asks what information a Stripe Connect connected
  account must provide for verification, onboarding, KYC, or account
  requirements; when they need to compare requirements between connected-account
  setups; or when they ask which verification fields, documents, or business
  details are required for a particular platform country, account country,
  business type, dashboard, service agreement, or capability.

Instructions

The human-accessible version of this documentation allows the user to select connected account fields and regions using a form, and then makes API requests to fetch and display the requirements a connected account with the selected configuration and region must provide. Follow these instructions to fetch the same information.

Interaction contract

Terminology used in this document:

• `field`: a setup input such as `platformCountry`, `accountCountry`, or `capabilities`
• `option`: a presented selectable option for a field
• `value`: the option the user selects, or the free-response value the user provides for a field

Every time you ask the user to provide a value for a field:

• use a multiple-choice question; never stop at a plain free-form prompt or wait for raw chat input
• if you need free user input, instruct the user to use the question’s free-response field
• for long option lists, explicitly say that any value from the full validated list is still accepted through the free-response field
• if the user already provided a valid answer in an earlier message, use that instead of asking again

Hard rules

You must follow these rules:

• Ask for a field *only* after all of its prerequisite fields are satisfied.
• Collect setup fields progressively as the flow advances.
• Ask for one field at a time, or one group of fields only when they’re dependency-free at that point in the flow.
• For example, ask for `platformCountry` and `accountCountry` separately: the platform country determines which account countries are valid, so asking both together can produce invalid combinations. But you may ask for `dashboardType`, `tosType`, and `legalEntityType` together in one group because their valid options are already known from the same response.
• If there is ever a conflict between the user’s request and the validated setup, inform the user of the conflict and ask them to revise their setup choices using the [Interaction contract](#interaction-contract). Keep the validated setup aligned with what the user requested without silently dropping the conflict.
• Follow the [Interaction contract](#interaction-contract) for every user question.
• When the number of available options exceeds four, *always* print the full validated reference list before asking the multiple-choice question so the user can see the full option space.
• When printing countries, always print the full country name followed by its code in parentheses, for example, `Germany (DE)`.
• In the multiple-choice question, include a small set of suggested options so the user can move forward with immediate clarity. The reference list above remains the authoritative full set.
• Leave the descriptions for the country suggested options blank.
• For any field with four or fewer valid options, show every valid option directly in the multiple-choice question. Don’t print a separate reference list first.
• Every list of selectable options shown to the user must be pre-validated against all currently known constraints before you display it.
• Never display an option as selectable if you already know it will be removed, rejected, or auto-adjusted later in the flow.
• Present options that stay valid through the current flow.
• Ask about `capabilities` after `platformCountry`, `accountCountry`, and the downstream validity constraints for that setup are resolved.
• *Only* ask about `orrProgram` when it is present in the public `programs` returned for the validated setup.
• If the `businessStructure` map for the chosen `legalEntityType` is empty or contains exactly one key `nil`, skip `businessStructure`. Otherwise, ask for `businessStructure` and always allow a `none` option or leave unselected as a suggested option in the multiple-choice question.
• If the user decides to change an earlier choice like `platformCountry`, you must invalidate and re-check all downstream fields before continuing.
• Keep the dependency chain implicit. Share the information the user needs to make progress and keep the experience simple.
• Use external-facing language when talking to the user. See below to translate the internal API terminology.

Internal fields -> External language

| Internal field | External language | | --- | --- | | `apiVersion` | Accounts API version | | `platformCountry` | Platform country | | `accountCountry` | Account country | | `dashboardType` | Dashboard type | | `tosType` | Service agreement | | `legalEntityType` | Business type | | `businessStructure` | Business structure | | `capabilities` | Capabilities | | `orrProgram` | Requirements update | | `eu2025` | Europe |

Dependency chain

You must follow this dependency chain exactly:

flowchart TD
  apiVersion["apiVersion"] --> capabilities
  platformCountry --> accountCountry["accountCountry"]
  accountCountry --> dashboardType["dashboardType"]
  accountCountry --> tosType["tosType"]
  accountCountry --> legalEntityType["legalEntityType"]
  legalEntityType --> businessStructure["businessStructure (optional)"]
  accountCountry --> capabilities["capabilities"]
  accountCountry --> orrProgram["orrProgram (only if returned)"]
  tosType --> capabilities
  apiVersion --> capabilities
  dashboardType --> finalRequest["final requirements request"]
  apiVersion --> finalRequest
  platformCountry --> finalRequest
  accountCountry --> finalRequest
  tosType --> finalRequest
  legalEntityType --> finalRequest
  businessStructure --> finalR