Overview
An HTTP API for institutions that hold money for their own clients: accounts and IBANs, fiat and crypto in, payouts out, and a yield-bearing position in a curated vault.
The TCB API is an HTTP API for institutions that hold money for their own clients — fintechs, wallets, brokers and neobanks. It has two halves: banking as a service, which opens accounts and IBANs and moves fiat in, across and out; and yield as a service, which places fiat into a TCB curated vault and holds it as a position you can read and redeem. Every call is made from your own backend with an API key. There is no browser, no dashboard, no user session and no redirect in any flow, and you instruct TCB on your clients' behalf.
Banking as a service
Accounts and IBANs for you and for your end customers, crypto and fiat in, money moved inside your tree, payouts out.
Yield as a service
Fiat you already hold, placed into a TCB curated vault and held as a position you can partition, read and redeem.
Choose where to start
Quickstart
I want to make my first call. Five calls, from checking your key to receiving your first webhook.
How it works
I want to understand the model first. A five-minute read on sub-clients, accounts, vault sub-accounts and positions.
What you can do
I am evaluating the API. The capability summary below, then the full API reference.
The API reference lists every operation in v1 with its request and response schema: API reference.
What you can do
Banking as a service
| You want to | Start here |
|---|---|
| Register an end customer and hold money attributable to them | Sub-clients |
| Open accounts and issue IBANs under an owner | Accounts |
| Receive crypto at a deposit address TCB issues you, then convert it and deposit the fiat | Crypto deposits |
| Turn one currency you hold into another | Conversions |
| Move money between accounts inside your own tree | Accounts |
| Pay another TCB customer instantly, addressed by IBAN or handle | Settlements |
| Register a payout destination ahead of paying it | Destinations |
| Pay a registered destination from your own account | Payouts |
Yield as a service
| You want to | Start here |
|---|---|
| Put fiat into a vault and take it back out | Vault deposits and withdrawals |
| Run the same chain one step at a time — fiat to tcbUSD, tcbUSD into the vault and back, including the vault's queue | Tokenised deposits, step by step |
| Read what you hold and what it has earned | Positions |
Across both
| You want to | Start here |
|---|---|
| Be told when something settles, without polling | Webhooks |
Core concepts
Seven ideas carry the API. Read them before you write against it.
| Pillar | Concept | What it is | Read |
|---|---|---|---|
| Banking | Sub-clients and verification level | Your end customers, registered with TCB under your root. Each sub-client holds its own account with TCB, in its own name. You collect the identity information and TCB accepts it. You instruct on the sub-client's behalf. The level TCB granted you decides what a sub-client may do once it is verified. | The objects |
| Banking | Accounts and IBANs | Accounts in one currency each, fiat or a crypto asset such as USDC, owned by you or by a sub-client, and the payment coordinate on the ones that need one — carrying the owner's own legal name as the payee name. | The object model |
| Banking | Transfers and conversions | A transfer moves fiat between any two accounts inside your tree and is terminal on the response. A conversion turns one currency you hold into another, priced by a venue that quotes independently of TCB. | Where the money can go |
| Banking | Destinations and payouts | You register where a payment is going ahead of sending it. A destination clears screening, TCB approval and a holding period before any payout can name it. | Destinations |
| Yield | Vault positions and sub-accounts | Named partitions of your own vault position, attributing it to your funds, strategies or products, and the settled, reserved and available shares in each. | Shares, position and accrual |
| Both | Intents and idempotency | Every money call is one intent, one state ladder and one idempotency key. The key claims that intent forever, and the intent stays readable at any time. | Intents |
| Both | Webhooks and scopes | Every terminal money outcome is announced to an endpoint you register, and every route checks your key for exactly one scope. | Webhooks |
If you have seen TCB describe client-money accounts, that is the sub-client and the accounts under it; the API calls them sub-clients throughout.
Every state a deposit, withdrawal, conversion or payout passes through is in The money lifecycle. Every term these pages use is defined once in the Glossary.
What follows the pilot, and in what order, is on the Roadmap.
Get access
TCB issues your API keys during onboarding. There is no self-serve signup and no key management UI. Contact partners@threecomma.group to ask for a key, a change of scopes, a rotation or a revocation. See Environments and API keys for what you receive and how to store it.
The specification
openapi.partner.v1.json is the machine-readable API specification, for code generators and API tooling. It describes the same contract these pages do. Where a page and the specification disagree, the specification is authoritative.