Capabilities

A capability is a feature you can utilize on an account. "This account can be charged on a card." "This account can receive a bank account payout." "This account holder is identity-verified." Each is a capability with its own status and its own list of outstanding requirements.

You request a capability; Frame provisions its requirements, reports its status and what it still needs (currently_due), and bills for its use; you decide what your platform does with what Frame reports. Some capabilities act at transaction time — geo_compliance blocking a restricted charge is the feature doing its job. A capability's status reports what currently is — it does not carry the play-by-play of individual checks, which live on their own records.

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

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

The status field on a capability is one of three values — this matches the Capability schema:

• 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 — as of Frame's last evaluation, every requirement was satisfied and the capability is usable.
• disabled — the capability has been switched off deliberately, by you or by Frame acting on a policy decision — and nothing else. The disabled_reason field describes why. A failed check never lands here: verification outcomes live on their own records, and a capability whose check failed stays pending.

Two lifecycle notes that are not status values you should branch on: a capability type that has never been requested on an account simply isn't part of that account's capability list yet (conceptually "unrequested" — there is nothing to read); and a small number of legacy capabilities may still show an ineligible state from an older model — treat it as "off, not self-service fixable." It is being retired.

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.

Re-evaluation is triggered by those inputs landing, not run on a schedule, and some checks resolve in the background. So status holds the result of the most recent evaluation and can trail the account's live state for a short window after a change — while currently_due is computed when you read it and is always current. If the two disagree, trust currently_due. Rather than polling status after a write, listen for the capability webhooks.

What active means, per capability

One rule governs status everywhere: active means every requirement on the capability's checklist was satisfied as of Frame's last evaluation. What the checklist contains differs by capability, so active answers a different question depending on which one you're reading:

Read the row you care about with its own question in mind — kyc_prefill: active means the prefill accelerator is enabled for the account, not that a prefill succeeded; kyc: active means the person is verified.

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 the capability.activated webhook to know when it activates. A failed check does not fire a capability event: it is reported on the requirement's verification record (for KYC, on the identity verification and its account.identity_verification.* webhook family).

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.