/embedded-banking/v1/external-bank-accounts — they aren’t nested under an internal bank account. They belong to the organization that connected them, and any internal bank account on that organization can use a VERIFIED external bank account as an ACH counterparty.
Why they exist
Assuming the business customer has a bank account with some financial institution somewhere, it needs a way to move money between that existing bank and the deposit account Tesouro just opened for them. External bank accounts give the ACH rail a verified, addressable target on the other end. The verification is the load-bearing part. Tesouro doesn’t take the user’s word that they own the outside account — micro-ACH deposits prove control of it before any real money moves. Trusted callers (typically platforms sitting higher in the hierarchy) can self-attest verification instead of going through the deposits, but that’s a scoped exception. See Linking an external bank account for both paths.What’s on the record
The response shape is deliberately thin. After connection you get:What you can’t do with them
- No balance. Tesouro has no read-access to the outside bank, so any “balance” you display has to come from elsewhere.
- No non-ACH rails. Internal-to-internal book transfers, RTP, and FedNow don’t accept an external bank account as a counterparty — only ACH does.
- No mutation of account or routing after connect. You can update the
nickname, but if the underlying account or routing number changes, connect a fresh external bank account.
Where to next
- Linking an external bank account — the three-call connect/link/validate flow and the verification statuses.
- Troubleshooting — what to do when micro-deposits don’t arrive or verification fails.
- ACH transfers — how a verified external bank account is used as a transfer counterparty.