# Two levels

Your Astrada **Account** is the tenant Astrada provisions for your organization, configured by Astrada based on your commercial contract. Every **Subaccount** you create (see [Core Resources](https://docs.astrada.co/docs/core-resources)) operates within it. The account level isn't something you call an endpoint to change yourself, but understanding what it controls explains behavior you'll otherwise see as unexplained defaults on your subaccounts.

Three settings live at both levels. Each has its own rule for how the levels interact. They are **not** all the same rule:

| Setting               | What it controls                                                                                          | How the levels interact                                                                                                                                  |
|-----------------------|----------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
| `configurations`      | Which card networks, countries, and card/funding types are eligible to enroll                            | Account sets the ceiling (`capabilities`): the countries you're contracted for, plus default blocked types. Subaccounts narrow within that ceiling, or inherit it wholesale with "*". |
| `verificationPolicy`  | Verification tier, sandbox routing                                                                        | Copied onto a subaccount **once, at creation**. After that, only the subaccount's own value is ever read. Changing the account-level policy later does not affect existing subaccounts. |
| `enrollmentPolicy`    | Whether the Spinwheel enrollment option is offered                                                        | The account-level `spinwheelEnabled` is a **live master switch**: off at the account level means off everywhere, checked on every read, regardless of what's stored on the subaccount. |

# Network, country, and card-type eligibility

Each subaccount's `configurations` (set via `POST /subaccounts` or `PATCH /subaccounts/{subaccountId}`) controls which cards are eligible to enroll, per network:

- **`countries`**: an explicit array of ISO 3166 alpha-3 codes, or "*" to inherit your account's full contracted list for that network. An explicit array must be a subset of the account's contracted countries, or the request 400s. "*" also stays in sync automatically if your account's contracted countries change later.
- **`single-enrollment`** and **`bulk-enrollment`**: each carries its own `countries` and blocked card/funding types, since a network can support different regions or restrictions for the two enrollment paths. Your account has sensible defaults for both; a subaccount only needs to set these if it wants something narrower.

See [Quick Start: Card Enrollment](https://docs.astrada.co/docs/quick-start-card-enrollment) for how this interacts with verification tiers, and [Getting Started](https://docs.astrada.co/docs/getting-started-1) for a working example.

# Verification policy

`verificationPolicy.stripeValidationLevel` picks the verification tier: `LOW`/`MEDIUM`/`HIGH`/`HIGHEST`, see [Verification Risk Tiers](https://docs.astrada.co/docs/verification-risk-tiers). This field is **subaccount-only at request time**. The resolver reads the subaccount's stored value and nothing else. There is no live fallback to the account level.

> 📘
>
> ### What "unset" actually means
>
> When a subaccount has no `stripeValidationLevel` set, verification does **not** default to `MEDIUM`. It routes through the legacy, non-Stripe path (TokenEx/IXOPAY for Visa, TNS for Mastercard) instead, which is a materially different flow. `MEDIUM`/`HIGH`/`HIGHEST` are tiers you opt into explicitly via `PATCH /subaccounts/{subaccountId}`. If you want Stripe-routed verification at all, set a tier. Don't rely on an assumed default.

The account level still matters once: when a subaccount is **created**, it copies whatever `verificationPolicy` its account had at that moment as a starting value. From then on, the subaccount's own stored value is authoritative. Changing the account's policy afterward has no effect on subaccounts that already exist. `verificationPolicy.sandbox` (see [Test Cards & Sandbox Testing](https://docs.astrada.co/docs/sandbox-testing)) follows the same subaccount-only rule.

`verificationPolicy.failedAttemptLockout` (see [Verification Attempt Lockout](https://docs.astrada.co/docs/verification-attempt-lockout)) is also set per subaccount; we don't have a confirmed account-level interaction for this one to document here.

# Enrollment policy

`enrollmentPolicy` gates a Spinwheel enrollment option and the card-program BINs used to match cards to it: an admin-managed setting configured during onboarding, not something you toggle via a public endpoint. The one behavior worth knowing: the account-level `spinwheelEnabled` is a live master switch. If it's off, it's off for every subaccount regardless of that subaccount's own stored value, and if the account is later re-enabled, subaccounts that already had it on come back automatically, with nothing to re-configure.