How it is built
The objects are explained under Account structure.
Status
Accounts use the model shared by every Augustus account:pending, active, frozen, closed. See Account status.
If you have permission to manage the accounts in a program, you can freeze, unfreeze and close them through the API. That is the case for your FBO program; operating accounts are managed by Augustus.
A new account opens in pending and is activated by Augustus once verification clears, usually within minutes. If additional information is required (enhanced due diligence, a sanctions hit, or an identity mismatch), the account stays pending and Augustus contacts you with next steps.
Money in
Each account has its own account number, so funds arriving over US rails settle into the right account without any routing on your side.
When a credit arrives, Augustus matches the destination account number to the account, performs sanctions and AML screening, credits the account’s balance and fires
deposit.settled. If a credit cannot be matched (wrong account number, sanctions hit, frozen account), Augustus returns it over the originating rail and notifies you with the reason. See Deposits.
Money out
You initiate payouts from the customer’s account: pass its ID asaccount_id. The customer’s name appears as the originator on the rail, which is payment on behalf of (PoBo). Funds are debited from the account when the payout is initiated. The request and response shapes are the same as for any other payout.
When the counterparty’s address belongs to an Augustus account, the payout settles on Augustus’s books instead of going out on a rail. It reaches sent within seconds, the receiving account gets a deposit.settled event, and both records carry rail: "internal". Statuses and webhooks are the same as for any other payout, and no configuration is needed.
Integration
Account, account holder and account program endpoints sit under/v1/accounts, /v1/account_holders and /v1/account_programs. They follow the same auth, error, and pagination conventions as the rest of the 2026-05-01 API.
Sandbox. Create a test program with POST
/v1/simulations/account_programs, then run the steps below against it. The Simulations walkthrough covers the full flow including deposits and payouts.1
Register the account holder
Pass the program ID, the holder type and the identity data for that type. The fields per type are listed under Account structure.The holder is screened asynchronously and starts in POST
pending. Subscribe to account_holder.active to know when it clears.holder_type accepts natural_person or business. individual is not a valid value. Open at most one account per customer under each program./v1/account_holders in the API Reference →2
Create the account
account_program_id or account_holder_id. Store the account ID against your customer record; to list a program’s accounts later, filter by account_program_id.POST /v1/accounts in the API Reference →3
Give the customer their payment details
The routing and account number under
financial_addresses, together with the customer’s name, are what a sender needs to pay in over ACH or Fedwire. For SWIFT, add Augustus’s BIC; see Receive USD internationally.4
List the accounts in the program
/v1/accounts in the API Reference →5
Read balances
Each account has its own balance. The program balance is the sum across every account in the program.Note the two shapes: the account balance keys on
Program balance
account_id, the program balance on id.GET /v1/account_programs/{id}/balance in the API Reference →