Age Verification

Age verification confirms that an account holder meets a minimum age threshold for your platform. It's a derived check — Frame uses the date of birth on the account's individual profile, compares it against your platform's threshold, and surfaces the result on the age_verification capability. There's no separate document upload, no additional UX for the account holder beyond supplying DOB.

age_verification is technically independent of KYC at the capability dependency level — you can request age_verification on its own. In practice, you almost always pair it with kyc, because KYC is what verifies the DOB. An unverified DOB the account holder typed into a form is a much weaker signal than a DOB Frame matched against a government-issued ID during KYC. If you skip KYC, age verification runs against unverified data and your platform inherits the risk.

Use age verification when a regulatory or platform policy requires gating activity behind an age (alcohol delivery, cannabis platforms, age-restricted retail, gambling, adult content).

Thresholds

Frame evaluates two thresholds out of the box. Your platform's age_verification request tells Frame which one applies:

If your platform needs a different threshold, talk to Frame support — the capability surface assumes one of these two by default and custom thresholds are a configuration concern, not an API parameter.

How it works

Age verification runs the moment profile.individual.birthdate is set on the account. In the recommended flow:

1. Request age_verification alongside kyc when creating the account. Both capabilities go on the same account; KYC handles all the data collection through the hosted onboarding flow.
2. The account holder completes onboarding. They upload an ID, take a selfie, supply the remaining identity fields. Date of birth lands on profile.individual.birthdate — verified by Frame against the document.
3. Frame evaluates the threshold. With a DOB now on file, the age check runs and the capability transitions to active or disabled based on the comparison.

If you set birthdate directly via API without running KYC, age verification still evaluates — it just trusts the input. The capability surface is the same; the signal underneath is weaker. The account holder never sees an "age verification" step in either case; it's an internal evaluation, not a screen they interact with.

Required fields

The minimum for age verification itself is date of birth on the account's individual profile. If you've requested KYC alongside (recommended), the full KYC field set is also required for KYC to activate:

• Legal first name + last name
• Phone number
• Date of birth
• Last 4 of SSN
• Residential address

Without DOB, age_verification stays pending. With DOB but no KYC running, it evaluates against the unverified DOB — accept the trade-off only if your platform's policy doesn't need a verified-identity guarantee on the age claim.

Outcomes

The age_verification capability has the same terminal states as any other capability:

• active — the account holder meets the threshold. Downstream capabilities or platform features that gate on age verification can proceed.
• disabled — the account holder does not meet the threshold. disabled_reason indicates the failure was age-related. Your application should gracefully decline the age-restricted activity per your platform's policy — typically by surfacing a message rather than retrying, since age isn't a remediable field.
• pending — KYC hasn't resolved yet, or DOB is still missing.

Age is not retriable. Unlike a KYC document-quality failure, a disabled age verification reflects a hard fact — there's nothing the account holder can do to satisfy it. Build the UX accordingly.

Relationship to other capabilities

Age verification on its own is just a math check against DOB. Its value compounds when paired:

• Pair with KYC so the DOB being evaluated is one Frame matched against a government-issued ID, not one the account holder self-reported. KYC isn't a prerequisite at the capability dependency level, but it's the strong-signal pairing.
• creator_shield depends on age_verification — when you request creator_shield, Frame automatically expands the request to include age_verification (and kyc).
• Your platform may layer additional business rules on top of age_verification (for example, only enabling alcohol-delivery checkout for accounts where age_verification is active AND the destination address is in a licensed jurisdiction). Those higher-level checks are application-side; Frame surfaces the binary age signal.

Gotchas

Symptom: age_verification is stuck pending even though the account holder finished onboarding. Why: most commonly, DOB isn't on the profile yet. If KYC is in flight, DOB lands when kyc settles; if you're not running KYC, you need to set profile.individual.birthdate directly. Fix: check whether DOB is set on the profile; if KYC is running, check its status — DOB arrives with KYC's data collection.

Symptom: an account holder you know is over 21 comes back disabled on age_verification. Why: the threshold was set to 21 in your platform's configuration, but the DOB Frame verified during KYC indicates under 21. The check ran against verified data, not the field the account holder entered — they may have lied on a self-service form earlier. Fix: trust the KYC-verified DOB; the discrepancy points at the account holder's input, not at Frame's check.

Symptom: you want to verify age without running full KYC. Why: in V1, Frame doesn't expose a standalone age-without-identity flow — DOB alone is not a verifiable claim without an identity attached. Fix: if your use case truly doesn't need identity verification (rare for age-gated commerce), talk to Frame support; otherwise plan for the KYC dependency.

Reference

For the full API surface, see POST/v1/accounts.