Skip to main content
Transactional Accounts are a managed-account configuration. For the account-model comparison and platform-to-customer relationship, see Managed Accounts.

​
What transactional accounts are

A transactional account is a verified business (KYB) or individual (KYC) account that your platform creates and operates through the API. Each one has its own account_id. This guide applies to both business and individual managed accounts. The account-creation payload and verification requirements differ by entity type; see Accounts and Individual Accounts for those details. Transactional accounts are non-custodial. They receive no internal wallet addresses and hold no Brale-custodied balance. A transactional account is not a wallet or a stored-value account. It is a verified identity with one or more registered external destination addresses.

​
When to use them

Use a transactional account when:
  • Your end customer needs a verified identity and an external, self-custody destination.
  • Your platform does not need the end customer to hold a Brale-custodied balance.
If your customer needs Brale-managed wallet addresses and a stablecoin balance, use Custodial Accounts instead.

​
Key limitations

  • No internal or custodial addresses. A transactional account has no automatic custodial wallet at creation and cannot hold internal (type=internal) addresses.
  • External addresses are destination-only. An external address on a transactional account can receive value but cannot be the source of a transfer.
  • The account cannot originate an on-chain transfer. An attempt returns 422 with type compatible_address_not_found.
  • Automations from a transactional account may only target external destinations. A Brale-custodied destination is rejected.
Branded Automations: Verified business and individual transactional accounts can be used as brand.account_id, subject to applicable program eligibility. Funding instructions show the business’s verified name and address or the individual’s legal name and address. This does not change the external-destination restrictions above. See Branded Automations.

​
How it works

  1. Create the account.
    Call POST /accounts with entity_type set to business or individual and account_type: "transactional". See Accounts for the request fields for each entity type.
  2. Wait for verification.
    Brale runs verification asynchronously. When it succeeds, status becomes complete and account.verification.completed fires. See Accounts for how to handle document requests.
  3. Register an external destination address.
    Add the customer’s self-custody wallet with POST /accounts/{account_id}/addresses/external. See Addresses.
  4. Deliver value to the destination.
    Use the external address as the destination in a transfer that originates elsewhere. A transactional account itself cannot be the source of an on-chain transfer. See Transfers and Automations for supported funding and delivery flows.
  5. Attribute activity.
    Inbound events carry data.account_id. A webhook subscription on your managing account receives events for every account it manages, so you can attribute activity to the correct managed customer account. See Webhook Events.

​
Off-ramp to a bank account

A transactional account cannot be the source of an off-ramp. To pay a transactional account holder out to their own bank account, route the payout through your managing account:
  1. The holder sends stablecoins from their self-custody wallet to an internal address on your managing account. This can be an omnibus address or a dedicated address per user.
  2. You register the holder’s bank account as an external address, under either the managing account or the holder’s transactional account.
  3. You submit a stablecoin-to-USD transfer from the managing account’s internal address to that bank address.
See Off-ramp for transactional accounts for the full walkthrough, branding guidance, and request examples.

​
Business and individual accounts

Both business and individual entities can use the transactional model, subject to your configured program, eligibility, and availability. The request shape and geographic rules differ by entity type:
  • Accounts covers the request fields for business and individual accounts.
  • Account types explains the entity_type, account_type, and verification_mode combinations.
  • Account availability lists the U.S. states and approved countries where each account type can be created.
  • Individual accounts walks through the end-to-end individual flow.