Capabilities

A capability is a named permission scoped to an account. "This account can be charged on a card." "This account can receive a bank account payout." "This account has completed KYC." Each is a capability with its own status and its own list of outstanding requirements.

Capabilities are the lever you pull to scope what an account is allowed to do. Request only what the relationship needs — a buyer paying you on a hosted checkout only needs card_send; a seller getting a payout needs card_receive or bank_account_receive plus the verifications those depend on.

The capability set

Capability	What it enables	Account requirements
`card_send`	The account's card can be charged (the everyday "accept a payment" case).	Individual or business account; an attached card payment method.
`card_receive`	Frame can push a payout to the account's debit card.	Individual account with completed KYC and a card payment method.
`bank_account_send`	The account's bank account can be debited via ACH.	Individual or business account; an attached bank account.
`bank_account_receive`	Frame can push a payout to the account's bank account.	Individual account with completed KYC and a verified bank account.
`kyc`	The account holder has completed identity verification.	Individual account with name, phone, address, date of birth, last 4 of SSN.
`kyc_prefill`	KYC data is pre-filled from a verified identity source instead of being re-collected.	Individual account with a phone number.
`phone_verification`	The phone number on file is verified via SMS or voice.	Individual account with a phone number.
`age_verification`	The account holder's age has been confirmed against the date of birth.	Individual account with verified KYC and DOB.
`address_verification`	A physical address has been validated.	Payment method with a billing address; ACH additionally requires verified KYC.
`bank_account_verification`	Bank account ownership has been verified.	Individual account; must use a hosted onboarding session.
`card_verification`	A card has been verified without being charged.	Individual account with a card payment method.
`geo_compliance`	Location-based rules have been applied to the account.	Account with Frame.js or a mobile SDK initialized.
`creator_shield`	Creator-focused fraud protection signals are running on the account.	Individual account with verified KYC.

A few terms to keep oriented:

_send means funds are pulled from the account (you charge the buyer's card). _receive means funds are pushed to the account (you pay out to the seller's bank).
The "minimal" capability for a buyer account is card_send. It doesn't require KYC, and it's what hosted checkout requests automatically.
KYC, age, address, phone, bank account, and card verifications are independent capabilities — request the ones you need rather than running them all by default.

Lifecycle

Each capability has its own status:

unrequested — the initial state. Frame knows about the capability type but you haven't asked for it on this account yet.
pending — the capability has been requested but at least one requirement is unmet. Frame is waiting on additional information or on a check to resolve.
active — every requirement is satisfied and the capability is usable.
disabled — the capability has been suspended (by Frame, by an explicit disable, or by a failed verification). The disabled_reason field describes why.
ineligible — the capability fundamentally cannot be granted to this account shape (for example, requesting card_receive on an account type that doesn't support it, or running against a sanctioned-jurisdiction profile). ineligible is terminal in the sense that the capability won't activate without a structural change to the account, not just more data.

A capability moves between states automatically as data lands. Attach a card → card_send becomes active. Complete KYC through an onboarding session → kyc becomes active. There is no explicit "activate" call; you supply the inputs, Frame re-evaluates.

currently_due

When a capability is pending, the currently_due array on the capability lists the actionable outstanding requirements — fields the account holder still has to supply.

{
  "name": "kyc",
  "status": "pending",
  "currently_due": ["profile.individual.address", "profile.individual.birthdate"]
}

currently_due is what you'd hand to an onboarding session to collect, or what you'd surface in your own UI. A pending capability with a populated currently_due is waiting on the account holder; an empty currently_due on a pending capability means Frame is waiting on a back-channel check (a verification still resolving, a document under review) — listen for capability.activated and capability.disabled webhooks to know when it transitions.

Capabilities and account status

An account's status rolls up from its capability statuses:

All requested capabilities active → account active.
One or more capabilities pending → account pending.
All capabilities disabled or the account explicitly disabled → account disabled.

A pending account can still transact through any of its active capabilities — the rollup is informational, not a gate. See accounts for the full state model.

Adding capabilities later

Capabilities are not locked at account creation. As an account holder unlocks new features on your platform — graduating from buyer to seller, opting into payouts — request additional capabilities by passing them on an update or by creating a new onboarding session configured for the additions. Each fresh session collects only the deltas, not what's already on file.

Reference

For the full capability set on a live account, see GET/v1/accounts/{account_id}/capabilities.