Move money between an Alpaca brokerage account and the EXTERNAL banking world via the Broker API — ACH relationships, wire recipient banks, classic transfers (deposits/withdrawals), the v1beta funding wallet (international/instant), transfer status lifecycles, and fees. Use when building deposit/withdrawal flows or connecting external bank accounts on Alpaca in any language. For moving cash/shares BETWEEN accounts inside your own omnibus, use journals instead.
npx skills add https://github.com/alpacahq/alpaca-skills --skill alpaca-broker-funding-transfers
Getting cash into and out of end-user accounts. There are three rails, and the model splits cleanly into *bank links* (persistent) and *transfers* (the actual money movement).
> Read alpaca-broker-integration first. Broker API + HTTP Basic auth. For moving cash *between* accounts in your omnibus (vs. to/from the outside world), see alpaca-broker-journals — that's a different mechanism.
https://docs.alpaca.markets/docs/funding-accountshttps://docs.alpaca.markets/reference/createtransferforaccountalpaca-docs MCP → get-endpoint title "Broker API" path /v1/accounts/{account_id}/transfersExternal bank ──(relationship: a persistent link)──┐
├──> Transfer (the money movement) ──> Account cash
ACH relationship (rail A: ACH, US domestic) │
Bank relationship (rail B: wire, domestic + intl) │
Funding wallet (rail C: v1beta, multi-currency) ┘
APPROVED before a transfer can progress.| Rail | transfer_type | Directions | Relationship | Notes |
|------|-----------------|-----------|--------------|-------|
| ACH | ach | INCOMING + OUTGOING | ACH relationship (relationship_id) | US domestic; set up via Plaid processor_token (recommended) |
| Wire | wire | OUTGOING only | Bank relationship (bank_id) | Domestic + international (SWIFT). Incoming wires are pushed by the sending bank and booked automatically |
| Funding wallet | (separate /v1beta API) | incoming / outgoing (lowercase) | Funding-wallet recipient bank | Multi-currency, swift_wire/local_rails |
| Method | Path | Purpose |
|--------|------|---------|
| POST/GET/DELETE | /v1/accounts/{id}/ach_relationships[/{rel_id}] | Manage ACH bank links |
| POST/GET/DELETE | /v1/accounts/{id}/recipient_banks[/{bank_id}] | Manage wire recipient banks |
| POST | /v1/accounts/{id}/transfers | Create transfer (ACH deposit/withdraw, or wire withdraw) |
| GET | /v1/accounts/{id}/transfers | List transfers |
| DELETE | /v1/accounts/{id}/transfers/{transfer_id} | Request cancel |
| POST/GET | /v1beta/accounts/{id}/funding_wallet | Create / get funding wallet |
| POST/GET/DELETE | /v1beta/accounts/{id}/funding_wallet/recipient_bank | Funding-wallet recipient bank |
| POST | /v1beta/accounts/{id}/funding_wallet/withdrawal | Funding-wallet withdrawal |
| GET | /v1beta/accounts/{id}/funding_wallet/transfers[/{transfer_id}] | List / get wallet transfers |
| GET | /v2/events/funding/status | SSE — unified funding status stream (see §6) |
> The current wire-bank endpoint is /recipient_banks (schema Bank/CreateBankRequest). The older /banks name is a legacy alias.
POST /v1/accounts/{id}/transfers)Required for all: transfer_type, amount (decimal string, > 0), direction.
// ACH deposit
{ "transfer_type": "ach", "relationship_id": "<uuid>", "amount": "100.00", "direction": "INCOMING" }
// Wire withdrawal
{ "transfer_type": "wire", "bank_id": "<uuid>", "amount": "500.00", "direction": "OUTGOING",
"fee_payment_method": "user", "additional_information": "..." }
relationship_id required iff ach; bank_id required iff wire (and must be the *other* one's empty).fee_payment_method (wire): user (fee deducted from amount; warn the user in UI) or invoice (firm billed monthly). Only outgoing wire fees auto-process.additional_information is wire-only — sending it on a non-wire request returns 422.Transfer response adds id, status, fee, requested_amount (original ask), reason, timestamps.POST /v1/accounts/{id}/recipient_banks)Required: name, bank_code, bank_code_type, account_number.
bank_code_type: ABA (9-digit routing, domestic) or BIC (SWIFT, international).BIC: country, city, state_province, postal_code, street_address become required.extra_fields carries intermediary/correspondent BICs (intermediary_bank1_bic…). Omitting them on international wires can cause auto-selection, delays, or extra fees — gather them up front for cross-border.QUEUED; it must reach APPROVED before a wire transfer against it progresses.Classic transfers (TransferStatus):
QUEUED → APPROVAL_PENDING → PENDING → SENT_TO_CLEARING → (APPROVED) → COMPLETE, with REJECTED / CANCELED / RETURNED as failure exits.
| Terminal | Meaning |
|----------|---------|
| COMPLETE | Settled |
| REJECTED | Rejected |
| CANCELED | Client-initiated cancel |
| RETURNED | Bank issued an ACH return |
(The SSE Transfer entity also reports EXPIRED, which is effectively terminal.)
Funding-wallet transfers (FundingWalletTransferStatus): PENDING, EXECUTED, COMPLETE, CANCELED, FAILED (last three terminal). Note lowercase incoming/outgoing directions here — different casing from classic transfers.
Classic transfers HAVE an SSE stream: GET /v2/events/funding/status. It is unified across four entity_type values — Transfer, BankRelationship, WireBank, FundingWallet — and is replayable via since/until (timestamps) or since_id/until_id (ULIDs). Use it instead of polling for classic ACH/wire status.
Funding-wallet *per-transfer* status appears NOT to be pushed — only wallet-level status (active/pending) is in the stream. Individual wallet transfer status (PENDING→EXECUTED→COMPLETE) must be polled via GET /v1beta/.../funding_wallet/transfers/{id}.
Lesson (hard-won): rails differ in event coverage. Decide per rail whether you consume SSE or poll, and build a status-reconciliation poller for anything not covered by events (and as a safety net even for those that are — SSE can drop). Map each Alpaca status to your own internal status with an explicit lookup table, and only poll transfers still in a non-terminal state. See alpaca-broker-reconciliation-idempotency.
> Legacy caveat: the older us/sse-events "Transfer Events" payload uses an integer event_id and lowercase statuses; the modern /v2/events/funding/status uses ULIDs. Migrate to v2.
requested_amount vs amount+fee in your UI.processor_token. There's an instant flag on the relationship. Account types limited to CHECKING/SAVINGS.timing: immediate is deprecated and silently ignored (sunset 2026-08-26) — stop sending it.403 if the account's depositable_status/withdrawable_status isn't allowed; 422 for incoming-wire attempts, missing/mismatched relationship vs bank IDs, or amounts under the (undocumented) minimums.Many production brokers don't fund each user account by a separate external transfer. Instead:
JNLC) — no external ACH/wire per user. See alpaca-broker-journals.This decouples your funding UX from Alpaca's transfer rails and enables "instant" deposits. It requires Alpaca review (and possibly a local money-transmitter license) — confirm with counsel. The classic transfer endpoints in this skill then handle only the *firm-account-to-outside-world* leg.
Related skills: internal cash movement → alpaca-broker-journals; missed-status recovery → alpaca-broker-reconciliation-idempotency; money formatting → alpaca-broker-money-precision; live status → alpaca-broker-sse-events.
Automatically organizes invoices and receipts for tax preparation by reading messy files, extracting key information, renaming them consistently, and sorting them into logical folders. Turns hours of manual bookkeeping into minutes of automated organization.
Expert guidance for systematic backtesting of trading strategies. Use when developing, testing, stress-testing, or validating quantitative trading strategies. Covers "beating ideas to death" methodology, parameter robustness testing, slippage modeling, bias prevention, and interpreting backtest results. Applicable when user asks about backtesting, strategy validation, robustness testing, avoiding overfitting, or systematic trading development.
This skill calculates key financial ratios and metrics from financial statement data for investment analysis
This skill provides an advanced financial modeling suite with DCF analysis, sensitivity testing, Monte Carlo simulations, and scenario planning for investment decisions
This skill retrieves upcoming earnings announcements for US stocks using the Financial Modeling Prep (FMP) API. Use this when the user requests earnings calendar data, wants to know which companies are reporting earnings in the upcoming week, or needs a weekly earnings review. The skill focuses on mid-cap and above companies (over $2B market cap) that have significant market impact, organizing the data by date and timing in a clean markdown table format. Supports multiple environments (CLI, Desktop, Web) with flexible API key management.
Crypto wallet operations via the awal CLI — sign in, check balances, send USDC/ETH/POL/SOL, trade tokens, fund the wallet, and use the x402 payment protocol to discover paid services, pay for API calls, monetize an API, or query onchain data. Use whenever the user mentions signing in, login, authentication, wallet status, balance, address, sending money, paying someone, transferring tokens, ENS names, swapping/trading/converting tokens, funding/topping up/onramp, USDC, ETH, POL, SOL, the x402 bazaar, paid APIs, monetizing an endpoint, or querying onchain data on Base.
Access real-time and historical stock market data, forex rates, cryptocurrency prices, commodities, economic indicators, and 50+ technical indicators via the Alpha Vantage API. Use when fetching stock prices (OHLCV), company fundamentals (income statement, balance sheet, cash flow), earnings, options data, market news/sentiment, insider transactions, GDP, CPI, treasury yields, gold/silver/oil prices, Bitcoin/crypto prices, forex exchange rates, or calculating technical indicators (SMA, EMA, MACD, RSI, Bollinger Bands). Requires a free API key from alphavantage.co.
Braintree Automation: manage payment processing via Stripe-compatible tools for customers, subscriptions, payment methods, and transactions
Take alpacahq/alpaca-broker-funding-transfers from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.