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

# Bank account addresses

> How a bank account becomes an on-chain address, and what happens when funds arrive.

The address you get back from
[registration](/api-reference/register-bank-account) is the whole product
surface. Understanding what it is makes the rest of the API obvious.

## It is derived, not allocated

The address is a Solana program-derived address computed from the account's own
identity — its account number, its bank code, and its region. Nothing random is
involved, and no pool of pre-generated addresses is drawn from.

Two consequences follow, and both simplify your integration:

<CardGroup cols={2}>
  <Card title="Stable" icon="anchor">
    The same bank account always maps to the same address. Store it once; it
    will not rotate or expire, and you never have to refresh it.
  </Card>

  <Card title="Shared" icon="users">
    The address belongs to the bank account, not to your business. If another
    Paj integration registered the same account first, you get the address it
    already has.
  </Card>
</CardGroup>

<Warning>
  Because the address is derived from the bank account, it is only as safe as
  the account number your user gave you. Always show the `accountName` returned
  by registration and have the user confirm it — a typo produces a valid address
  that pays a stranger's bank account.
</Warning>

## What happens after a deposit

Nothing is required from your API integration once you have shown the address.
Paying it *is* the instruction:

<Steps>
  <Step title="Funds land">
    A deposit arrives in the address's token account — a real, separate on-chain
    balance. Paj's listener picks it up within seconds.
  </Step>

  <Step title="Swept into the pool">
    The balance is moved on-chain into Paj's treasury and an offramp transaction
    is opened against the bank account it belongs to.
  </Step>

  <Step title="Value check">
    USDC/USDT pays out directly. Non stable token is priced for its USD value,
    so senders are not restricted to a single mint.
  </Step>

  <Step title="Paid out">
    Naira is disbursed to the bank account through the banking rail at the
    prevailing offramp rate. The on-chain legs take seconds; the fiat leg
    dominates the end-to-end time.
  </Step>
</Steps>

## Amounts and rates

The rate applied is the offramp rate in effect **when the deposit is observed**,
not when you last called
[`GET /pub/v2/rate`](/api-reference/get-rates). If you quote a figure to a user
before they send, treat it as indicative — see [Rates](/concepts/rates).

There is no per-deposit registration step, so there is also no amount to commit
to in advance. A user can send any amount, any number of times, to the same
address.

## Reversing the lookup

When you see a deposit on-chain and want to know whose it is, pass the address
to [`GET /pub/v2/bank-account`](/api-reference/search-bank-account). This is the
same mapping in the other direction, and it is the intended way to attribute an
on-chain event back to one of your users.