> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tesouro.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Internal bank accounts

> How an internal bank account gets provisioned at Tesouro's sponsor bank and what's usable on the first read.

An internal bank account is the deposit account Tesouro's sponsor bank holds on the business customer's behalf. It's the account `id` you pass into transfer requests, the account statements are generated from, and the account that emits `ACCOUNT_STATUS_CHANGED` webhooks when something about it shifts.

## Provisioning

Internal bank accounts aren't created by an explicit "open account" call. They appear as the terminal effect of a [bank account application](/embedded-banking/guides/bank-account-applications/overview) reaching `COMPLETE`. At that point KYB has finished, the bank has decisioned the application, and a deposit account has been opened against the verified business.

You discover the new bank account by reading the application — the response includes the `id` it produced — or by subscribing to the relevant `ACCOUNT_STATUS_CHANGED` event on your webhook subscription.

```http lines theme={null}
GET /embedded-banking/v1/bank-accounts/{id}
```

## What's on the read

```json title="Response (200 OK)" lines theme={null}
{
  "id": "ba_550e8400-e29b-41d4-a716-446655440001",
  "nickname": "Operating",
  "bankAccountReference": "northfield-op-001",
  "accountNumber": "***5678",
  "routingNumber": "021000089",
  "createdDateTime": "2026-05-21T16:52:00Z",
  "status": "ACTIVE"
}
```

| Field                  | Notes                                                                                                                                            |
| :--------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------- |
| `id`                   | The identifier for the bank account — passed into transfer endpoints, transaction listings, and the PATCH for closure.                           |
| `nickname`             | Display label, mutable via PATCH.                                                                                                                |
| `bankAccountReference` | Caller-supplied external reference (your own ID for this account), mutable via PATCH.                                                            |
| `accountNumber`        | Masked on read. The full number for inbound ACH and wire is delivered at provisioning.                                                           |
| `routingNumber`        | Sponsor bank's routing number — pair with the full `accountNumber` for inbound transfers.                                                        |
| `status`               | `ACTIVE` on the first read. The other state is `CLOSED` — see [Closing a bank account](/embedded-banking/guides/bank-accounts/closing-accounts). |
| `createdDateTime`      | When the sponsor bank opened the account.                                                                                                        |

Balance is returned by the with-balance variant of this endpoint, and transactions are listable separately:

```http lines theme={null}
GET /embedded-banking/v1/bank-accounts/{id}/transactions
```

The transactions endpoint accepts `startDate`, `endDate`, `limit` (1–100, default 25), and a `pagination_token`. Each row carries `description`, `direction` (`CREDIT` or `DEBIT`), `date`, `amount` (in minor units), and `runningBalance`.

Once the application is `COMPLETE`, the bank account is the sponsor bank's record of truth and behaves like any other deposit account. From this point on it's a transfer source or destination on every rail; see [Money movement](/embedded-banking/guides/money-movement/overview).

When the bank account eventually needs to come out of service, see [Closing a bank account](/embedded-banking/guides/bank-accounts/closing-accounts).