> ## 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.

# Bank account applications

> How a bank account application moves through DRAFT, SUBMITTED, and COMPLETE — and the auth required at each step.

A bank account application is a first-class object in the Embedded Banking API. Your backend creates it, applicant and business details get filled in, the bank decisions it. Each application moves through three states, and which credential you use to act on it depends on whether a browser is involved.

## Integration shapes

How you drive an application depends on whether a browser sits between you and the API.

* **Server-to-server only.** Your backend holds a bearer token and drives the entire lifecycle — create, edit, verify, submit — from server code. The client secret is never issued. Pick this when you've already collected applicant and business details out of band, or when KYC/KYB happens outside Tesouro and the application is essentially a system-of-record entry for the bank.
* **Server creates, browser finishes.** Your backend creates the application and receives a short-lived [application client secret](/embedded-banking/guides/authentication/application-client-secret) in the create response. You hand the secret to a browser surface — your own UI, the [white-label hosted app](/embedded-banking/guides/white-label), or the [onboarding widget](/embedded-banking/guides/widgets/onboarding-widget) — and the browser drives the rest without holding a backend bearer token. Pick this when end users need a UI.

The scoped client secret is a browser credential, not a server-side one. Backend integrators have no reason to issue one, and never need to think about the resume flow.

## States

<CardGroup cols={3}>
  <Card title="DRAFT" icon="pen-to-square">
    Editable. The applicant can update applicant, business, and beneficial-owner details and request the verification codes that precede submission.
  </Card>

  <Card title="SUBMITTED" icon="paper-plane">
    Read-only. The applicant has called the submission endpoint; the bank's KYC/KYB pipeline is running. Your backend can read the application but no one can edit it.
  </Card>

  <Card title="COMPLETE" icon="circle-check">
    Terminal. The bank has finished processing and the underlying bank account exists. The application is read-only and the client secret is invalidated.
  </Card>
</CardGroup>

Transitions only ever move forward: `DRAFT → SUBMITTED → COMPLETE`. There is no edit-after-submit and no return to `DRAFT` from a later state. If a submitted application is rejected by the bank, that outcome is reported through the bank account status — not by transitioning the application backward.

## Auth at each step

Per-application calls accept either a backend bearer token (from the [client credentials](/embedded-banking/guides/authentication/client-credentials) flow) or the [application client secret](/embedded-banking/guides/authentication/application-client-secret) — whichever credential the caller actually has. Backend-only integrations use bearer for every row. Hybrid integrations use bearer to create and resume, and the browser uses the client secret for the per-application rows in the middle.

| Step                               | State after         | Auth options                                     |
| :--------------------------------- | :------------------ | :----------------------------------------------- |
| Create application                 | `DRAFT`             | Bearer                                           |
| Read application                   | unchanged           | Bearer; client secret (PII masked, browser only) |
| Edit applicant / business / owners | `DRAFT`             | Bearer or client secret                          |
| Request a verification code        | `DRAFT`             | Bearer or client secret                          |
| Submit applicant verification      | `DRAFT`             | Bearer or client secret                          |
| Submit application                 | `SUBMITTED`         | Bearer or client secret                          |
| Re-issue a client secret to resume | unchanged (`DRAFT`) | Bearer                                           |

The client secret accepts only those per-application rows — it cannot create a new application, resume another one, or reach non-application endpoints. It is invalidated when the application reaches `COMPLETE`. After that, the application is reachable only with a backend bearer token. See [Application client secret](/embedded-banking/guides/authentication/application-client-secret) for token shape, header, and PII-masking rules.

## Where to next

<CardGroup cols={3}>
  <Card title="Creating an application" icon="plus" href="/embedded-banking/guides/bank-account-applications/creating">
    Create the application server-to-server, receive the client secret, and act on behalf of a child organization with `X-Organization-ID`.
  </Card>

  <Card title="Editing and submitting" icon="pen-to-square" href="/embedded-banking/guides/bank-account-applications/submitting">
    Patch in remaining details, verify the applicant, and submit the application to the bank.
  </Card>

  <Card title="Resuming" icon="rotate" href="/embedded-banking/guides/bank-account-applications/resuming">
    Re-issue a client secret for a stale `DRAFT` application and deliver it to the applicant by email.
  </Card>
</CardGroup>