Identities and accounts

Bastion uses a two-tier hierarchy to manage customers and their financial operations: Identities at the top level and Accounts beneath them. This separation provides flexibility for compliance, multi-wallet scenarios, and organizational structures.

Identity

An Identity represents a verified individual or business entity in the Bastion system. It serves as the compliance and regulatory anchor for all financial activity.

Aspect	Description
Purpose	Acts as the subject of KYC (Know Your Customer) or KYB (Know Your Business) verification
Compliance	Stores verification status, jurisdiction information, and regulatory checks
Ownership	Can own multiple Accounts for different purposes
Types	`INDIVIDUAL` for personal customers, `BUSINESS` for corporate entities

Key properties of an Identity:

Property	Description
`identity_id`	Unique identifier assigned by Bastion
`type`	Either `INDIVIDUAL` or `BUSINESS`
`status`	Current compliance status (`ACTIVE`, `PENDING_ONBOARDING`, `REJECTED`, `SUSPENDED`, `TERMINATED`)
`sub_status`	Finer-grained detail within a `status`. Populated during `PENDING_ONBOARDING` (compliance running, IDV steps, RFI), and can also carry `RFI_REQUIRED` on an `ACTIVE` or `SUSPENDED` identity when Compliance raises a post-onboarding request for information. Empty/unspecified otherwise.
`fiat_operations_enabled`	Whether the identity has passed compliance and can perform fiat operations (on/off-ramp conversions)
`allowed_to_transact_fungibles`	Whether the identity can use crypto transfers. Automatically set to `true` once sanctions and jurisdiction checks pass.

Each identity must have a unique email address. Bastion does not allow the same email address to be used across multiple identities for stablecoin conversions.

`identity.status` values

Value	Meaning
`PENDING_ONBOARDING`	Identity created; onboarding workflow in progress. See `sub_status` for the precise step.
`ACTIVE`	KYC/KYB approved, identity is able to transact.
`SUSPENDED`	Previously active; temporarily suspended by Bastion Compliance.
`REJECTED`	KYC/KYB denied during onboarding. Identity is not able to transact or proceed with account opening.
`TERMINATED`	Identity and all associated accounts are permanently closed.

`identity.sub_status` values

Value	Meaning
`CREATED`	Identity exists; no compliance work has started yet.
`COMPLIANCE_CHECKS_IN_PROGRESS`	KYC/KYB checks running.
`IDV_REQUIRED`	Identity-document verification needs to be initiated. IDV will only be required for KYC / individual identities.
`IDV_REQUESTED`	IDV link sent to the user; awaiting completion. IDV will only be required for KYC / individual identities.
`IDV_IN_PROGRESS`	User has started but not finished IDV. IDV will only be required for KYC / individual identities.
`IDV_EXPIRED`	IDV session expired before completion; needs to be re-requested. IDV will only be required for KYC / individual identities.
`RFI_REQUIRED`	Request-for-information initiated by Bastion (additional documents/data). Bastion can raise it at any step of `PENDING_ONBOARDING`, and on an `ACTIVE` or `SUSPENDED` identity.

Every sub-status except RFI_REQUIRED only appears while status is PENDING_ONBOARDING. RFI_REQUIRED can also be set on an ACTIVE or SUSPENDED identity when Compliance requests additional information after onboarding. An ACTIVE identity keeps transacting while the RFI is open, and sub_status clears once it is fulfilled.

How an RFI interacts with other changes

During onboarding, Bastion can raise an RFI at any step. When it is fulfilled, sub_status returns to the step the identity was at, or to the step it has reached since, for example IDV_REQUIRED.
Bastion accepts resubmitted KYC/KYB data while an RFI is open. sub_status stays RFI_REQUIRED until the RFI is fulfilled, and no identity_status_update webhook fires for the resubmission.
Any change of status (approval, rejection, suspension, reinstatement or termination) closes an open RFI and clears RFI_REQUIRED. The exception is a reinstatement that Bastion makes with sub_status RFI_REQUIRED: it keeps an open RFI open, or opens a new one.

Account

An Account belongs to an Identity and is the operational unit for financial activity. This is where balances live, transactions originate, and wallet addresses are managed.

Aspect	Description
Purpose	Holds balances and initiates transactions
Wallets	Each account receives wallet addresses for supported blockchains
Flexibility	An Identity can have multiple Accounts (e.g., for different currencies, use cases, or sub-entities)
Isolation	Balances and transaction history are isolated per Account

Key properties of an Account:

Property	Description
`account_id`	Unique identifier for the account
`identity_id`	The parent Identity this account belongs to
`account_type`	Either `SEGREGATED` or `OMNIBUS`. See Account types.
`addresses`	Wallet addresses mapped to supported chains
`account_status`	Current account status (`ACTIVE`, `FROZEN`, `CLOSED`)

`account.status` values

Value	Meaning
`ACTIVE`	Account is cleared to transact and usable.
`FROZEN`	Account is blocked (derived from a SUSPENDED parent identity).
`CLOSED`	Account is permanently closed (derived from a TERMINATED parent identity).

How identities and accounts relate

An Identity owns one or more Accounts. Each Account has its own balances, wallet addresses, and transaction history, isolated from other Accounts under the same Identity.

An identity record owns one or more accounts, each with its own balances, wallets, and transactions

Account types

Every account is one of two types. SEGREGATED accounts hold their own on-chain wallet addresses with chain-specific balances. OMNIBUS accounts pool funds in a custody vault, and Bastion tracks each account’s balance on an internal ledger. Both are fully custodial under Bastion’s US regulated licensing, and your platform uses the same APIs either way. See Custody for how each model holds assets and how balances are returned.

Common patterns for multiple accounts

Pattern	Description
Multi-currency	Separate accounts for different fiat currency settlements
Segregated funds	Isolate customer funds from operational funds
Sub-entities	A business Identity with accounts for each department or subsidiary
Testing	Maintain separate accounts for sandbox and production

Compliance

An Identity must pass compliance verification (KYC for individuals, KYB for businesses) before accounts can be created or financial operations can begin.

Identity status must be ACTIVE before creating an account.
allowed_to_transact_fungibles must be true before submitting crypto transfers.
fiat_operations_enabled must be true before initiating on/off-ramp conversions.
Compliance requirements vary by jurisdiction and identity type. Business identities typically require more documentation (articles of incorporation, beneficial owner information).
Some operations may require additional verification even after initial approval.

For step-by-step onboarding instructions, see Onboard an individual customer or Onboard a business customer.

Concepts
Getting started
- Onboard an individual customer
- Onboard a business customer
API reference
- Accounts
- Identities

Getting Started

Concepts

Quickstarts

Compliance

Security

Bastion Dashboard

LLMs and MCP Server

Identities and accounts

Identity

`identity.status` values

`identity.sub_status` values

How an RFI interacts with other changes

Account

`account.status` values

How identities and accounts relate

Account types

Common patterns for multiple accounts

Compliance

​Identity

​identity.status values

​identity.sub_status values

​How an RFI interacts with other changes

​Account

​account.status values

​How identities and accounts relate

​Account types

​Common patterns for multiple accounts

​Compliance

​Related documentation

Identity

`identity.status` values

`identity.sub_status` values

How an RFI interacts with other changes

Account

`account.status` values

How identities and accounts relate

Account types

Common patterns for multiple accounts

Compliance

Related documentation